Specifications should be somewhat complete and not open ended/not thought out, you should think about the issues, requirements and use cases first before you try to force this into the working group process and confuse people , we had too many of these specifications lately.
We are now up to 15+ specifications that someone has to read and understand how these all may or may not fit together and all the interactions that may occur. So much for the simple Oauth. From: Justin Richer [mailto:[email protected]] Sent: Tuesday, April 12, 2016 5:46 AM To: Torsten Lodderstadt <[email protected]> Cc: Anthony Nadalin <[email protected]>; <[email protected]> <[email protected]> Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0 +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]<mailto:[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]] 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%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%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d>
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
