+1 to Torsten’s point. And a reminder to Tony that call for adoption is the *start* of the document editing process, not the end. We’re not saying this is a complete solution with everything thought out when we adopt the document, we’re saying it’s a problem we want to work on and a direction that we want to move in. Stop trying to confuse people.
— Justin > On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt <[email protected]> > wrote: > > Indicating the resource server to the AS allows the AS to automatically > select token type, encryption scheme and user data to be put into the access > token based on a RS-specific policy. So there is no need to explicitely ask > the AS for a certain token format or encryption scheme. > > Am 11.04.2016 um 22:35 schrieb Anthony Nadalin <[email protected] > <mailto:[email protected]>>: > >> So it’s an incomplete solution then ? >> <> >> From: Brian Campbell [mailto:[email protected] >> <mailto:[email protected]>] >> Sent: Monday, April 11, 2016 1:34 PM >> To: Anthony Nadalin <[email protected] <mailto:[email protected]>> >> Cc: Nat Sakimura <[email protected] <mailto:[email protected]>>; >> <[email protected] <mailto:[email protected]>> <[email protected] >> <mailto:[email protected]>> >> Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 >> >> No, I'm not adding requirements for encryption. I was pointing out some of >> the ways that an access token might be different for different RSs. >> >> >> >> On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin <[email protected] >> <mailto:[email protected]>> wrote: >> So now you are adding more requirements for encryption ? The more this >> thread goes on shows how unstable and not fully thought out this draft is to >> go through WG adoption. >> <> >> From: OAuth [mailto:[email protected] <mailto:[email protected]>] >> On Behalf Of Brian Campbell >> Sent: Monday, April 11, 2016 12:30 PM >> To: Nat Sakimura <[email protected] <mailto:[email protected]>> >> Cc: <[email protected] <mailto:[email protected]>> <[email protected] >> <mailto:[email protected]>> >> Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 >> >> Sending a token type is not sufficient. There's more involved than the >> format. Many cases need to know if to encrypt and whom to encrypt to. What >> claims to put in the token (or reference by the token). What algorithms and >> keys to use for signing/encryption. >> >> The statement that the "Current proposal does not support the implicit flow" >> is incorrect. Among other things, sec 2 has, "When an access token will be >> returned from the authorization endpoint, the "resource" parameter is used >> in the authorization request to the authorization endpoint as defined in >> Section 4.2.1 of OAuth 2.0 [RFC6749]." >> >> On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura <[email protected] >> <mailto:[email protected]>> wrote: >> So, my understanding on the rationale/requirements for having this spec >> right now is: >> >> R1. Authz server wants toprevent the replay by the server that received it. >> R2. Authz server needs to mint the access token in a variety of format >> depending on the resource server and to do that, you need to know which RS >> is gong to be receiving it. >> >> To achieve R1, there are couple of methods. The proposed method here is to >> audience restrict the token, but the same can be achieved by sender >> constraining the token, e.g., by token binding. As far as I can see, the >> sentiment of the WG seems to be to use the sender constraint through Token >> Binding, so from this respect, this spec is not the one to do R1. Besides, >> the current proposal only takes care of the code flow. The same requirement >> should be there for implicit flow as well, so the current proposal is not >> covering the R1 anyways. >> >> I can sort of understand R2, but I have two critique on the current >> proposal: >> >> C1. Current proposal does not support the implicit flow. To support it, the >> resource URI has to be sent to the Authz endpoint instead of the Token >> endpoint. >> C2. It is much more direct to send the required token format rather than the >> RS uri and probably better as: >> 1) There are use cases where the AS does not maintain the list of RSs that >> it supports, e.g., AOL. >> In such a case, even if the RS uri were sent to the AS, the AS cannot >> mint the tokens in the appropriate format. >> 2) When it is sent in the Authz request, it is leaking the information >> about the resource that the client is going to the browser. >> 3) There are use cases where it is desirable not to let the AS knows where >> the Client is going from the privacy point of view. >> >> So, my suggestion is to drop R1 and concentrate on R2. And to solve R2, send >> token type instead of the resource indicator in the request. >> This also necessitates the Client to be able to find out what token type the >> resource requires, perhaps in the unauthorized response web link header at >> the resource in the manner of oauth-meta. >> >> Cheers, >> >> Nat >> >> >> >> 2016年4月8日(金) 8:23 Prateek Mishra <[email protected] >> <mailto:[email protected]>>: >> While this work addresses a gap in the existing OAuth specification set, I >> am very concerned that this >> incremental extension will lead to even more confusion around the areas of >> “scope”, “audience” and “resource server”. >> >> I think we should try to solve this problem via a framework that provides >> better guidance and implementation >> models for OAuth use-cases. In other words, I feel that a broader discussion >> is needed here. >> >> >> > On Apr 7, 2016, at 4:11 PM, Justin Richer <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > I support adoption of this document as a starting point for working group >> > work. >> > >> > — Justin >> > >> > >> >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig <[email protected] >> >> <mailto:[email protected]>> wrote: >> >> >> >> Hi all, >> >> >> >> this is the call for adoption of 'Resource Indicators for OAuth 2.0', see >> >> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/ >> >> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=y869Fk9987ff09hvHIN%2bVGl%2fqxwWDmkvOwzcQcWqXZw%3d> >> >> >> >> Please let us know by April 20th whether you accept / object to the >> >> adoption of this document as a starting point for work in the OAuth >> >> working group. >> >> >> >> Note: If you already stated your opinion at the IETF meeting in Buenos >> >> Aires then you don't need to re-state your opinion, if you want. >> >> >> >> The feedback at the BA IETF meeting was the following: ~10 persons >> >> for accepting the document and 0 persons against. >> >> >> >> Ciao >> >> Hannes & Derek >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> [email protected] <mailto:[email protected]> >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d> >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/oauth >> > <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
