-1 on the reason not to discuss the issue now. The current limited deployment case experience of OAuth does not necessarily indicate the expected use in the future. We already know it to be MUCH broader as the password anti-pattern is very large indeed.
I will also point out that this is a V. 2 specification. Thus now is not necessarily the time to artificially limit scope as it might be for a version 1 specification which may with good reason want to limit the use cases. That said, *I do agree the idea is late in the V2 process*. If we can't develop a solid answer cleanly, and if it is too disruptive...we simply cannot pursue. Because of this, I want to have more discussion before dismissing the idea. I am looking at potentially similar issues as previously raised by Torsten. My thoughts are: The single-token schema may be fine for single-property cloud sites to go with the current single-token spec, but I'm sure multi-property sites will have these issues very quickly. It also occurs to me that MAC tokens should have limited sharing of keys (e.g. to single client-server pairs), so that will tend to drive token services to want to issue more tokens then say with bearer tokens which could more easily be used in multi-property scenarios. Of course, I haven't thought this through yet...this is just a top-of-the-head, what are the ramification thoughts. I would like to see more discussion. Thanks, Phil @independentid www.independentid.com [email protected] On 2011-06-17, at 12:13 PM, David Recordon wrote: > +1 Eran > > On Fri, Jun 17, 2011 at 12:46 AM, Eran Hammer-Lahav <[email protected]> > 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:[email protected]] >>> 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 <[email protected]>: >>> >>>> I'm standing behind my 99.99% projection for the next 5 years. >>>> >>>> EHL >>>> >>>> From: [email protected] [mailto:[email protected]] 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
