So it’s an incomplete solution then ? From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, April 11, 2016 1:34 PM To: Anthony Nadalin <tony...@microsoft.com> Cc: Nat Sakimura <sakim...@gmail.com>; <oauth@ietf.org> <oauth@ietf.org> 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 <tony...@microsoft.com<mailto:tony...@microsoft.com>> 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:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of Brian Campbell Sent: Monday, April 11, 2016 12:30 PM To: Nat Sakimura <sakim...@gmail.com<mailto:sakim...@gmail.com>> Cc: <oauth@ietf.org<mailto:oauth@ietf.org>> <oauth@ietf.org<mailto:oauth@ietf.org>> 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 <sakim...@gmail.com<mailto:sakim...@gmail.com>> 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 <prateek.mis...@oracle.com<mailto:prateek.mis...@oracle.com>>: 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 > <jric...@mit.edu<mailto:jric...@mit.edu>> 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 >> <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> 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 >> OAuth@ietf.org<mailto:OAuth@ietf.org> >> 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 > OAuth@ietf.org<mailto:OAuth@ietf.org> > 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 OAuth@ietf.org<mailto:OAuth@ietf.org> 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 OAuth@ietf.org<mailto:OAuth@ietf.org> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
