+1 Eran
On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > OAuth has been successful because of its simple architecture and because it > is based on actual deployment experience. Offering multi-token responses > would be premature standardization. I am not convinced that adding it later > would entail any real technical difficulty. > > EHL > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] >> Sent: Friday, June 17, 2011 12:41 AM >> To: Eran Hammer-Lahav >> Cc: Manger, James H; OAuth WG >> Subject: Re: [OAUTH-WG] issuing multiple tokens >> >> this is kind of a self-fulfilling prophecy. If we do not encourage >> implementors >> to use service-specific tokens by supporting it in OAuth most people will not >> consider it. >> >> As James pointed out, there are good reasons to use service-specific tokens >> in multi-service environments. That's why Deutsche Telekom employs a strict >> security policy to use different tokens for different services. And as a >> multi- >> service provider an increasing percentage of our apps need to access >> multiple services. That's why we have implemented support for issuing >> multiple tokens in a single authorization flow. We will have this feature in >> production before IETF-81. >> >> regards, >> Torsten. >> >> Zitat von Eran Hammer-Lahav <e...@hueniverse.com>: >> >> > I'm standing behind my 99.99% projection for the next 5 years. >> > >> > EHL >> > >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> > Of Manger, James H >> > Sent: Thursday, June 16, 2011 9:04 PM >> > To: OAuth WG >> > Subject: Re: [OAUTH-WG] issuing multiple tokens >> > >> >> [Issuing multiple tokens] is not an important enough feature. >> >> Parsing an array response when >> >> 99.99% will be a single object array is annoying. >> > >> > I would agree... if I believed the 99.99%, but not if it will be 80% >> > and falling in a year or two. >> > >> > A major benefit of OAuth2 is that resource servers only handle >> > limited-lifetime, limited-capability access tokens so there is limited >> > damage and easier recovery if one resource service is compromised. If >> > the same access token works at all the resource servers that a client >> > app uses, then an attacker that compromises one resource server can >> > re-use the access tokens elsewhere. The bigger your portfolio of >> > services, the worse the risk. >> > >> >> Also, what would you return in case of error? A single object? >> > >> > Yes. It is not that hard to test if JSON.parse(...) returns an array >> > or a single object with an error field, or to notice the 4xx status >> > code. >> > >> >> What is the client supposed to do if it gets an empty array? >> > >> > The delegation succeeded, but you don't need to use temporary >> > credentials (perhaps client auth is sufficient, perhaps a [MAC] cookie >> > was issued, perhaps the service is using URIs-as-capabilities...). >> > Continue on to use the API. >> > >> >> Array with more than one token? >> > >> > If the client app hasn't bothered to write the extra code to handle >> > multiple tokens then it just uses the first token. If separate tokens >> > are now needed for servers that previously shared the same token, then >> > the service has made a deliberate decision to increase security in a >> > way that wasn't backwardly compatible. >> > >> >> *This* would be the hack... If this is something people want to >> >> deploy, a full proposal end-to-end is required. And not now. >> > I few proposals have been made in the past. Some try hard to leave the >> > single token case alone, but always at a cost to complexity: eg the >> > first token needs to be handled differently to the other tokens. >> > >> > >> > Responding to William Mills' comments: >> >>> Probably defining a token type of "multiple_tokens" would be my >> preference, >> >>> and if you get that back then you have to parse an array of {type, >> token}*. >> >>> What that array looks like could be JSON in the payload, or >> >>> something else. >> >>> That leaves the single token use case alone. >> > >> > This is a good example of how it is awkward to add multiple token >> > support later. >> > With this suggestion a service that starts issuing multiple tokens >> > (eg for clients to access an enhanced version of an API) can't just >> > add an extra token for the enhanced API that old clients will >> > ignore. Instead, it has to change the top-level token_type, which >> > will fail in all old clients. It also leaves other top-level >> > mandatory fields such as access_token with confusing semantics. >> > >> > >> > -- >> > James Manger >> > >> >> >> > > _______________________________________________ > 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
