I think you are correct - there should be only one scheme per header. However, there is an issue that a particular token type may be used outside of OAuth and then it may also be used within OAuth at the same time. So you do have to list protocols twice. I believe Eran had mentioned an approach of sub-categorization that could also work...
WWW-Authenticate: BEARER ... WWW-Authenticate: OAUTH2_MAC ... WWW-Authenticate: OAUTH2_BEARER ... This may have some advantages. E.g. different parameters for each OAuth sub category. The big difference would be that this sub-category approach would end up requiring more registrations. I'm neutral on the approach here, but I think the key is that tokens need to be usable both inside and outside of OAuth and that servers may need both at the same time. Phil phil.h...@oracle.com On 2011-02-05, at 10:21 AM, Torsten Lodderstedt wrote: > that's not the way WWW-Authenticate headers are used today. Instead the > resource server should return a single WWW-Authenticate header _per_ > supported authentication scheme, such as > > WWW-Authenticate: MAC realm="somerealm" > WWW-Authenticate: BEARER realm="somerealm" > > furthermore, I think interdependencies among WWW-Authenticate headers as > suggested by Phil > > WWW-Authenticate: OAuth > token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyy > > could be rather fragile. > > I would expect the WWW-Authenticate header to return all the data required to > obtain the credentials/tokens, such as > > WWW-Authenticate: MAC realm="somerealm", tokenUrl="yyyyy&token_secret=yes" > WWW-Authenticate: BEARER realm="somerealm", tokenUrl=""yyyyy" > > Which raises the question whether the coupling between authentication schemes > and the OAuth2 core protocol is stronger than assumed. > > please als see > http://www.ietf.org/mail-archive/web/oauth/current/msg04988.html > > regards, > Torsten. > > Am 04.02.2011 22:39, schrieb William Mills: > >> I was thinking along the lines of simply returning the HTTP Authorization >> header schemes that are supported. In the OAuth 2 context that would be >> >> WWW-Authenticate: 401 error="blah blah blah" auth_types="Bearer MAC >> Basic" >> >> The client has to be aware of the authentication scheme names. >> >> -bill >> >>> -----Original Message----- >>> From: Phil Hunt [mailto:phil.h...@oracle.com] >>> Sent: Friday, February 04, 2011 1:14 PM >>> To: William Mills >>> Cc: Marius Scurtescu; OAuth WG >>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >>> 2/10) >>> >>> I agree, that is still to be defined. There seems to be some push back >>> on discovery, but this is likely warranted. If only because web sites >>> may have both browser clients and app clients. >>> >>> In a previous message, I did suggest the web site return HTTP 401 as >>> below... >>>>> 401 Unauthorized >>>>> WWW-Authenticate: Basic realm="tokenSvc" >>>>> WWW-Authenticate: Digest realm="tokenSvc" >>>>> WWW-Authenticate: Form >>> url="/clientAuthenticate.jsp",realm="tokenSvc" >>> >>> It could also include other items for "MAC", etc. >>> >>> The only other issue would be determining whether the token is obtained >>> via an OAuth profile or via some default profile. That could be >>> handled with something like: >>> >>> WWW-Authenticate: Basic realm="somerealm" >>> WWW-Authenticate: MAC realm="somerealm" >>> WWW-Authenticate: OAuth >>> token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyyy" >>> >>> The above would suggest that MAC tokens could be used alone as >>> described in some specification for "MAC". However, the presence of >>> the OAuth header indicates that MAC and BEARER tokens can be used in >>> the OAuth pattern. >>> >>> I think this allows both de-coupling of tokens from OAuth but also >>> informs clients what tokens can be used with OAuth. >>> >>> There may be other ways to do this. But it does help with the >>> decoupling. >>> >>> Phil >>> phil.h...@oracle.com >>> >>> >>> >>> >>> On 2011-02-04, at 11:44 AM, William Mills wrote: >>> >>>> I was thinking more about how the client knows what to use. The >>> ubiquitous "service documentation" may come in to play here. Some form >>> of serv ice discovery/webfinger thing could also be used. >>>>> -----Original Message----- >>>>> From: Phil Hunt [mailto:phil.h...@oracle.com] >>>>> Sent: Friday, February 04, 2011 11:37 AM >>>>> To: William Mills >>>>> Cc: Marius Scurtescu; OAuth WG >>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >>>>> 2/10) >>>>> >>>>> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
