Realm is really only useful when MAC is used outside of OAuth like Basic or Digest and informs the client when it should try and reuse the same credentials. But with OAuth, presumably, the server will tell the client (using a parameter or documentation) where to use the token, making realm pointless.
EHL > -----Original Message----- > From: William Mills [mailto:wmi...@yahoo-inc.com] > Sent: Tuesday, February 08, 2011 2:40 PM > To: Eran Hammer-Lahav; Torsten Lodderstedt > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Discovery RE: Bearer token type and scheme > name (deadline: 2/10) > > 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/blahblahb > > l > > > 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
