I'm a strong advocate of the Link approach, given that authorization information does not belong on the authentication headers.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of William Mills > Sent: Monday, February 07, 2011 2:50 PM > To: Torsten Lodderstedt > Cc: OAuth WG > Subject: [OAUTH-WG] Discovery RE: Bearer token type and scheme name > (deadline: 2/10) > > OK. > > So then the question is the right way to communicate token endpoints. Is it > cleaner/preferred to have everything in the WWW-Authenticate header, or > to break things out so we're not stuffing a lot into those headers and > repeating outselves? So, all in one would be: > > WWW-Authenticate: MAC realm="somerealm" > token_url="http://login.example.com/token"; > auth_url="http://login.example.com/webauth"; > > Broken out might be: > > WWW-Authenticate: MAC realm="OAuth2" > Link: <http://login.example.com/token?grant_type=MAC> rel="oath2- > token" > Link: > <http://login.example.com/auth?.done=http://foo.service.come/blahblahbl > ah> rel="oath2-auth" > > -bill > > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > > Sent: Saturday, February 05, 2011 10:21 AM > > To: William Mills > > Cc: Phil Hunt; OAuth WG > > Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: > > 2/10) > > > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
