+1 We should distill the use cases to get a set of requirements before jumping onto a solution.
On Tue, Apr 12, 2016 at 14:04 Anthony Nadalin <tony...@microsoft.com> wrote: > 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:jric...@mit.edu] > *Sent:* Tuesday, April 12, 2016 5:46 AM > *To:* Torsten Lodderstadt <tors...@lodderstedt.net> > *Cc:* Anthony Nadalin <tony...@microsoft.com>; <oauth@ietf.org> < > oauth@ietf.org> > > > *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 <tors...@lodderstedt.net> > 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 <tony...@microsoft.com>: > > So it’s an incomplete solution then ? > > > > *From:* Brian Campbell [mailto:bcampb...@pingidentity.com > <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> > 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] *On Behalf Of *Brian > Campbell > *Sent:* Monday, April 11, 2016 12:30 PM > *To:* Nat Sakimura <sakim...@gmail.com> > *Cc:* <oauth@ietf.org> <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> 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>: > > 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> 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> 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 > >> 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 > <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 > <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 > <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 > <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 > 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%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d> > > > _______________________________________________ > 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
