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
