Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))

[Denis <[e-mail]>]

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