So, if we go with the Link approach and we are thinking in the context of the MAC token draft, how is realm used in some sane way? Am I right that a server might know of multiple ways to obtain a MAC token? Should we define the realm "oauth2" and then have that imply the link relationship names? This would mean we can support:
WWW-Authenticate: MAC realm="oauth2" WWW-Authenticate: MAC realm="x-newspec" Link: <http://login.example.com/token?grant_type=MAC> rel="oath2-token" Link: <http://login.example.com/auth> rel="oath2-auth" Link: <http://login.example.com/newauth/MAC> rel="x-newspec" If we do define the realm this way, should this go into the core spec? -bill > -----Original Message----- > From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > Sent: Monday, February 07, 2011 3:07 PM > To: William Mills; Torsten Lodderstedt > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Discovery RE: Bearer token type and scheme name > (deadline: 2/10) > > 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
