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). > > - 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. > > - 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. > 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. > > - 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. Should I record your vote for #2? EHL [1] http://tools.ietf.org/html/draft-hammer-http-token-auth-01 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
