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
