Hi Benjamin and Aaron,
Note: This is also a reply to Aaron who wrote:
Typically in OAuth it's the authorization server's job to inform
users and protect access to their resources.
Obviously in order to do that the AS must know about the details of
the request.
Can you please clarify the scenario in which you would want the AS
to have no information about the request that it's authorizing?
The start of the answer comes from the text that was inserted in my
first email of this thread, which is copied again below:
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.
*1° About d**raft-ietf-oauth-rar-01*
In draft-ietf-oauth-rar-01, it is acknowledged that the parameter
"scope" that allows OAuth clients to specify the requested scope
is not sufficient to specify fine-grained authorization requirements.
If the OAuth WG believes that the AS and the RS relationship are not
necessarily any more *bilateral *but may also be***unilateral*,
i.e. an AS may be trusted by several RS, but the ASs do not need to know
/in advance/ the RSs, then some evolutions are possible
as explained below.
A RS must know which attributes from a client are necessary in order to
accomplish a given operation.After being informed by the RS
of which attributes are necessary in order to accomplish a given
operation, a client may request these attributes to any AS that is trusted
by the RS for these types of attributes. If the client also has a trust
relationship with one or more of these AS, then it may proceed.
For example, a RS may request three attributes to an AS: a "sub" claim
which is a value locally unique in the context of the AS
or that is globally unique, a home address and an indicator stating
whether the user is over 21 years old. If the client finds these three
attributes
as being acceptable for the kind of operation it is willing to perform
on the RS, then it may request these three attributes to one or more
appropriate ASs.
In this way, the AS does not know which operation(s) will be performed
on an AS. Hence, there is no need to define JSON objects
with "type" fields such as "account_information" and
"payment_initiation" as given as examples in draft-ietf-oauth-rar-01.
However, JSON objects able to indicate e.g. a pseudonym, a home address,
a family name, a first name, etc ... should be defined.
To respond to Aaron, the AS does not need to know the details of the
operations that will be performed by a client on a RS but only needs to
provide
the attributes that are being requested by the client. The job of the
RSs is to inform its clients about which attributes are necessary in
order to perform
a given operation and to indicate which ASs are trusted to provide these
attributes.
This does not mean that all this information shall necessarily be made
publicly available: it may only be available to authenticated clients
at the time they are willing to perform a given operation.
ASs do not needto know (and hence to control) which attributes are
necessary to perform _every_ operation on_every_ RS.
Unilateral relationships would make the whole architecture more scalable.
*2° About draft-ietf-oauth-jwsreq-22 *
draft-ietf-oauth-jwsreq-22 introduces the ability to send request
parameters in a JSON Web Token (JWT) which allows the request to be signed
with JSON Web Signature (JWS) (...) so that the integrity [and] source
authentication (...) property of the Authorization Request is attained.
It should be realized that a simpler mechanism could be used in some
cases: integrity "protection" of a message is in fact the "detection" of
the integrity
of a message by a receiver. It is possible to *detect *that the /request
/has been modified by observing the /response/, i.e. the content of the
JWT. Let us assume
that no cryptographic mechanism is used in the request, then when a
client receives a JWT, *if it may verify its content*, it may then know
whether or not
the request parameters have been modified while in transit. For example,
if a client requested a pseudonym claim, a home address claim, a family
name
claim and a first name claim to be present in the JWT, unless an error
is reported, it can verify that these claims are indeed present in the JWT.
This is another reason why a client should be able to inspect the
content of the access token.
Denis
On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote:
As indicated in the abstract:
"This document introduces the ability to send request parameters in
a JSON Web Token (JWT) instead,
which allows the request to be signed with JSON Web Signature (JWS)".
This approach has a major consequence which is not indicated in the
"Privacy Considerations section:
the AS will have the knowledge of these request parameters 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".
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 a deep knowledge of every
operation that can 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.
Other approaches that are more "privacy friendly" should be considered
to address the initial problem.
Do you have the start of a list of such other approaches to seed the
discussion? There seemms to be some inherent tension between the
authorization server knowing what it is authorizing and the privacy
properties you are advocating...
Thanks,
Ben
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
