Hi Hannes,
I do not deny the fact that it is necessary to provide some information
to the authorization server
to indicate the resource server where the access token shall only be used.
Let us illustrate the concept with a simple scenario.
A user first connects to a resource server and announces some actions he
would like to perform.
In its response, the resource server indicates "demonstrate that you are
older than 18 and incorporate
in your access token the random value (some kind of challenge) I have
just generated for you only".
The client forwards that random value to the authorization server which
is blindly copied and pasted
into the access token. If the resource server does not recognize this
value, the access will be denied.
In this way, the authorization server has no way to know where the
access token will be used.
On the contrary, an absolute URI would allow the authorization server to
know which resources the user is accessing.
The use of an absolute URI should be deprecated because of this privacy
concern.
Denis
Hi Denis
draft-campbell-oauth-resource-indicators gives the authorization server
information about the resource server the access token will be used with.
Without this information there is the risk that the access token is
replayed at other resource servers and with the proof-of-possession /
token binding work there obviously has to be an indication of where the
token is used.
The reason for using an absolute URI is that the resource server needs
to take the information from the incoming access token and to compare it
with its own information in order to determine whether the token is
indeed intended for itself.
If the authorization server does not know to whom it gives rights to
access protected information then this is also a privacy risk (namely
unauthorized access).
Ciao
Hannes
On 11/15/2016 12:50 PM, Denis 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
