This document states that the "scope" parameter used to specify the
requested scope of an access token
is only "sufficient to implement static scenarios and coarse-grained
authorization requests".
The intent of this draft is to specify "fine-grained authorization
requirements", such as "please let me make
a payment with the amount of 45 Euros" or "please give me read access to
folder A and write access to file X".
The proposed draft presents some similarities with a capability model
where the holder of an access token is given
the right by an AS to perform some operation(s) on an object through the
content of the access token.
Such an approach has privacy issues which are currently not documented
in the Privacy Considerations section.
The AS would be in a position to know, not only which resources servers
are going to be accessed, but also
what kind of operations are going to be performed by its clients on the
resource servers. With such an approach,
ASs will have the knowledge of every operation that is likely to be
performed by a user on every RS.
As a consequence, the AS would also be in a position to trace the
actions performed by its users on the resources servers
with which it has a relationship.
Other approaches allowingto specify "fine-grained authorization
requirements", that are more "privacy friendly"
should be considered to address the initial problem.
ADDITIONAL ARCHITECTURAL COMMENT
OAuth initially assumed a static relationship between clients,
authorization servers and resource servers.
The original model for OAuth was making the assumption that the AS and
the RS had a strong bilateral relationship.
A key question is whether such strong relationship will be maintained
for ever or whether it will be allowed to perform
some evolutions of this relationship.
In order to respect the privacy of the users, there is the need to
encompass other scenarios. One of these scenarios is
that the AS and the RS do not need any longer to have such a strong
relationship. In terms of trust relationships, a RS
simply needs to trust the access tokens issued by an AS. The AS does
have any more a "need to know" of all the RSs
that are accepting its access tokens. This would be a major
simplification of the current global architecture.
oauth-security-topics states:
The privileges associated with an access token SHOULD be
restricted to the minimum required for the particular
application or use case.
This means that the client should be able to select by itself the claims
it would like to be placed into an access token
with respect to the operations it is willing to perform on a RS.
As long as only the scope request parameter will be usable in an access
token request to select the claims to be placed
into an access token, it will not be possible to remove this strong
relationship.
Denis
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
