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
