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]>: > > 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]> > Cc: Nat Sakimura <[email protected]>; <[email protected]> <[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]> > 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]] On Behalf Of Brian Campbell > Sent: Monday, April 11, 2016 12:30 PM > To: Nat Sakimura <[email protected]> > Cc: <[email protected]> <[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]> 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]>: > 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]> 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]> > >> 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/ > >> > >> 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] > >> 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 > > _______________________________________________ > 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
