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
