I was thinking more about how the client knows what to use. The ubiquitous "service documentation" may come in to play here. Some form of serv ice discovery/webfinger thing could also be used.
> -----Original Message----- > From: Phil Hunt [mailto:phil.h...@oracle.com] > Sent: Friday, February 04, 2011 11:37 AM > To: William Mills > Cc: Marius Scurtescu; OAuth WG > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > 2/10) > > Yes. This should be defined in each token type specification. > > Phil > phil.h...@oracle.com > > > > > On 2011-02-04, at 11:29 AM, William Mills wrote: > > > The only challenge is to know what scheme to use and what the nuances > are of how to present the credential. > > > >> -----Original Message----- > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > Behalf > >> Of Phil Hunt > >> Sent: Friday, February 04, 2011 9:42 AM > >> To: Marius Scurtescu > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > >> 2/10) > >> > >> OAuth should be able to support other token schemes. > >> > >> Or conversely you don't have to have OAuth to use MAC, JWT, or > >> whatever. > >> > >> Phil > >> phil.h...@oracle.com > >> > >> > >> > >> > >> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: > >> > >>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav > >> <e...@hueniverse.com> wrote: > >>>> Hey Marius, > >>>> > >>>>> -----Original Message----- > >>>>> From: Marius Scurtescu [mailto:mscurte...@google.com] > >>>>> Sent: Thursday, February 03, 2011 10:36 AM > >>>>> To: Eran Hammer-Lahav > >>>>> Cc: OAuth WG > >>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name > >> (deadline: > >>>>> 2/10) > >>>>> > >>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav > >>>>> <e...@hueniverse.com> wrote: > >>>>> > >>>>>> 2. Single OAuth2 scheme with sub-schemes > >>>>>> > >>>>>> Define a single authentication scheme for all token types with > >> some > >>>>>> attribute used to detect which scheme is actually being used. > >>>>>> > >>>>>> Benefits: > >>>>>> > >>>>>> - single scheme, reuse of the 1.0 pattern. > >>>>>> > >>>>>> Downsides: > >>>>>> > >>>>>> - requires a new registry for authentication header parameters. > >>>>> > >>>>> How is this different from option 1? Wouldn't that need some > >> registry? > >>>> > >>>> #1 relies on the existing practice of creating HTTP scheme names > (no > >> current registry but httpbis might be creating one), as well as the > -12 > >> token type registry. Using a sub-scheme means you also need a > registry > >> for the header attributes that each token type will need (unless you > >> just don't care about using the same attribute name for different > >> needs). > >>> > >>> Sure, there is no registry for schemes yet, but we would still need > >>> some coordination. The fact that a sub-scheme needs a registry that > >> we > >>> control is a benefit not a downside IMO. > >>> > >>> > >>>>>> - schemes are not easily reusable outside OAuth. > >>>>> > >>>>> Sure. But I really don't see this group trying to create generic > >> authentication > >>>>> schemes. > >>>> > >>>> MAC is exactly that. > >>> > >>> May or may not be. My point is that this group is not focused on > >>> creating generic authentication schemes. Are you aware of any other > >>> protocols that might use MAC or BEARER? Are we willing to put in > the > >>> effort to create generic schemes? Is it our charter? > >>> > >>> > >>>>>> - existing frameworks usually switch on scheme name, not on sub > >>>>>> scheme, which will cause difficulty in some deployments. > >>>>> > >>>>> I can see this as a potential problem. But considering that there > >> wasn't much > >>>>> objection to use "OAuth" as a scheme name before (total overlap > >> with > >>>>> OAuth 1, and the suggested solution was to look for the signature > >>>>> parameter) I don't see how this is suddenly an issue. > >>>> > >>>> There was pretty strong objection to reusing OAuth. > >>> > >>> Yes, because there was no sub-scheme nor version (and the grammar > was > >>> totally broken). Even so, lots of implementations went ahead and > did > >>> it. Were there any scheme switching issues we are aware of? > >>> > >>> > >>>>> Do we have a concrete problem here or this is just theoretical? > >>>> > >>>> This came up during the review of draft-hammer-http-token-auth > [1]. > >> There was a long thread about it where people posted actual > framework > >> issues. > >>>> > >>>>>> - potential to produce a very complicated scheme once many sub > >> schemes > >>>>>> are added. > >>>>> > >>>>> Why? I would argue that this option actually produces more > uniform > >>>>> schemes because it forces all of them to be name/value pairs. > >> Beyond > >>>>> token_type everything is scheme specific. I really don't see what > >> is very > >>>>> complicate here. > >>>> > >>>> It is still a single scheme with many different sub-schemes, each > >> with different key-value pairs that may have conflicting meaning. > The > >> way I look at it is that if I try to fully implement this mega > scheme > >> (which means all its sub-schemes), it will likely be a complicated > >> task. On the other hand, if you split it across scheme name, we > already > >> have a well-established system in place to pick and choose HTTP > >> authentication schemes. > >>> > >>> No one has to implement a mega scheme. All schemes must use > >> name/value > >>> pairs and that's where the common part stops. > >>> > >>> > >>>>>> - requires its own discovery method for which schemes are > >> supported. > >>>>> > >>>>> Why is this a downside only for this option? > >>>> > >>>> Because the other options get this for free by using the WWW- > >> Authenticate header (since each scheme has a unique name). You can > list > >> multiple headers in the 401 response. > >>> > >>> I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate > >>> work for sub-schemes as well? > >>> > >>> > >>>> Should I record your vote for #2? > >>> > >>> #2 or #3 > >>> > >>> > >>> Thanks, > >>> Marius > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
