In this document the information is very much intended for the authorization server so that it can make appropriate policy choices about the token to be issued.
On Tue, Nov 15, 2016 at 4:50 AM, Denis <denis.i...@free.fr> wrote: > Hello everybody, > > Since I am not present at the meeting, I read the minutes from the first > session, in particular: > > Brian Campbell and John did a draft allowing the client to tell the AS > where it plans to use the token > draft-campbell-oauth-resource-indicators > > This enables the AS to audience restrict the access token to > the resource > Phil Hunt: We should keep the audience restriction idea on > the table > > The introduction contains the following sentences: > > Several years of deployment and implementation experience with OAuth 2.0 > [RFC6749] has uncovered a need, in some circumstances, > for the client to explicitly signal to the authorization sever where it > intends to use the access token it is requesting. > > A means for the client to signal to the authorization sever where it > intends to use the access token it's requesting is important and useful. > > The document contains a "security considerations" section but > unfortunately no "privacy considerations" section. > > Clause 2 states: > > The client may indicate the resource server(s) for which it is requesting > an access token by including the > following parameter in the request. > > resource > > OPTIONAL. The value of the resource parameter indicates a resource server > where the requested > access token will be used.* It MUST be an absolute URI*, as specified by > Section 4.3 of[RFC3986], > > With such an approach, the authorization server would have the ability to *act > as a Big Brother *and hence to know exactly > where the user will be performing activities. > > However, some users might be concerned with their privacy, and would like > to restrict the use of the access token > to some resource servers without the authorization server knowing which > are these resource servers. > > The key point is whether the information is primarily intended to the > authorization server or to the resource server(s). > > I believe that it is primarily intended to the resource server(s) rather > than to the authorization server in order to be included > in an access token. Obviously, the information needs to transit through > the authorization sever, that should simply be copied > and pasted into the access token. Its semantics, if any, does not > necessarily needs to be interpreted by the authorization sever. > > I believe that a "privacy considerations" section should be added. > > The sentence "*It MUST be an absolute URI*, as specified by Section 4.3 > of [RFC3986]" should be removed or > replaced by : "*It MAY be an absolute URI*, as specified by Section 4.3 > of [RFC3986]". > > Obviously, other changes would be necessary too. > > Denis > > _______________________________________________ > 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
