Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-access-token-jwt-11.txt> (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens) to Proposed Standard

[Denis <[e-mail]>]

I have one comment on the Security Considerations section and several 
comments on the Privacy Considerations section.

*Security Considerations section(Section 5)
*
The intent of this comment is to add information, but not to change the 
meaning.

Current text:

    The JWT access token data layout described here is very similar to
    the one of the id_token as defined by [OpenID.Core].
    The explicit typing required in this profile, in line with the
    recommendations in [RFC8725] helps the resource server to distinguish
    between JWT access tokens and OpenID Connect ID Tokens.

Proposed text:

    The JWT access token data layout described here is very similar to
    the one of the id_token as defined by [OpenID.Core].
    The explicit typing required in this profile (i.e. "at+jwt", see
    section 2.1), in line with the recommendations in [RFC8725] helps
    the resource server to distinguish between JWT access tokens (i.e. "
    jwt") and OpenID Connect ID Tokens (i.e. either "jwt" or "json").


*Privacy Considerations section(Section 6)
*
Current text:

    As JWT access tokens carry information by value, it now becomes
    possible for clients and potentially even end users to directly peek
    inside the token claims collection.

    The client MUST NOT inspect the content of the access token: the
    authorization server and the resource server might decide to change
    token format at any time
    (for example by switching from this profile to opaque tokens) hence
    any logic in the client relying on the ability to read the access
    token content would break without recourse.

    The OAuth 2.0 framework assumes that access tokens are treated as
    opaque by clients.Administrators of authorization servers should
    also take into account
    that the content of an access token is visible to the
    client.Whenever client access to the access token content presents
    privacy issues for a given scenario,
    the authorization server should take explicit steps to prevent it.

Rational for a change:

The following sentence at the beginning of the second paragraph is correct:

    "The OAuth 2.0 framework assumes that access tokens are treated as
    opaque by clients".

The current first sentence says that it is possible to directly peek 
inside the token claims collection. This is indeed possible /in the 
context of this RFC/
(/i.e. not in general/) since that client is able to test if a "typ" 
header parameter exists and if it contains the value " at+jwt".
It is sufficient to warn the reader that such peeking is not possible in 
general, but is possible when/if the previous two conditions are satisfied.

Before proposing a text replacement, if we were using sub-paragraphs for 
addressing the different topics, the text would be more readable:

    6.1. Peeking inside the token claims collection
    6.2. End-user identifier correlation
    6.3. AS tracking

Let us start with the last one (6.3). An email sent by Vittorio Bertocci 
on 2020-04-29 states in its last sentence:

    " I’ll try to come up with concise language that clarifies to the
    reader that the current mechanism does allow AS tracking".

See: 
https://mailarchive.ietf.org/arch/msg/oauth/x2Xvd14hREBoYKEZ1h0bDsPRGKM/

However, no sentence has been added to address this warning. This 
explains why I propose the following text :

    6.3. AS tracking

    Since an "aud" claim parameter is included by the AS inside every
    access token, the AS is in a position to know
    and trace where each access token is likely to be used. In addition,
    if token introspection is used by the RS,
    this allows the AS to know and trace exactly where and when each
    access token has been used.This may be
    a privacy concern for some end-users.

Let us come back to the three previously quoted paragraphs.

Proposed text replacement:

    6. Privacy Considerations

    6.1. Peeking inside the token claims collection

    JWT access tokens issued under this profile include in the "typ"
    header parameter of an access token the value "at+jwt"
    to explicitly declare that the JWT represents an access token
    compliant to this profile. This information allow RSs to know
    if they receive an access token compliant to this profile.

    The OAuth 2.0 framework assumes that access tokens are treated as
    opaque by clients.

    Nevertheless, when a client gets back an access token from an AS, if
    the value "at+jwt" is present in the "typ" header parameter
    of that access token, as such access tokens carry information by
    value, it is possible for clients and potentially even end users
    to directly peek inside the token claims collection.

    However, the AS and the RS might decide to change the token format
    at any time (for example by switching from this profile to opaque
    tokens)
    hence any logic in the client relying on the ability to read the
    access token content would break without recourse.As a consequence,
    clients
    should not expect to be always able to inspect the content of access
    tokens.

    Furthermore, this profile does not allow a client to request an
    access token format conformant to this profile.

    Administrators of authorization servers should take into account
    that the content of an access token is visible to the client.
    If this is a concern for the AS, it should take explicit steps to
    prevent it.

The three paragraphs that come after can remain unchanged. To be 
explicit, here they are:

    In scenarios in which JWT access tokens are accessible to the end
    user, it should be evaluated whether the information can be accessed
    without privacy violations (for example, if an end user would simply
    access his or her own personal information) or if steps must be taken
    to enforce confidentiality.

    Possible measures to prevent leakage of information to clients and
    end users include: encrypting the access token, encrypting the
    sensitive claims, omitting the sensitive claims or not using this
    profile, falling back on opaque access tokens.

    In every scenario, the content of the JWT access token will
    eventually be accessible to the resource server.It’s important to
    evaluate whether the resource server gained the proper entitlement to
    have access to any content received in form of claims, for example
    through user consent in some form, policies and agreements with the
    organization running the authorization servers, and so on.

The next and last original paragraph is addressing another topic. It 
starts with the following sentence:

    "This profile mandates the presence of the "sub" claim in every JWT
    (...) ".

A key sentence is the following: " The "sub" claim should be populated 
by the authorization servers according to a privacy impact assessment ".
This sentence does not provide a sufficient guidance. It is important to 
mention that there exists three options for the "sub" claim:

  * a globally unique identifier,
  * a resource server specific identifier, or
  * an access token specific identifier.

and then, although no specific parameter has been defined to allow the 
client to choose between these three options,
it is possible for an AS to allow such a choice using the "scope" parameter.

Proposed text replacement for the last original paragraph:

    6.2. End-user identifier correlation

    This profile mandates the presence of the "sub" claim in every JWT
    access token. The "sub" claim is defined in RFC 7519 (section 4.1.2)
    in the following way:

    "The subject value MUST either be scoped to be locally unique in the
    context of the issuer or be globally unique."

    When the subject value is scoped to be globally unique, it is
    possible for every RS to use that information for correlating
    incoming requests
    with data stored locally for the authenticated principal with
    different RSs. It is also possible for servers that are not resource
    servers (RSs)
    but which use the same globally unique identifiers for correlating
    stored data.

    Although the ability to correlate requests and stored data might be
    required by design in some scenarios, there are scenarios where such
    correlation is not desirable.

    In such scenarios, the AS may use an identifier that is locally
    unique in the context of the issuer: it may be unique either for
    every RS or for every access token :

    - In order to prevent tracking principal activities across multiple
    resource servers, the authorization server should ensure that JWT
    access tokens meant
             for different resource servers have distinct "sub" values
    that cannot be correlated in the event of resource servers collusion.

    - In order to prevent a resource server from correlating the
    principal’s activity within the resource itself, the authorization
    server should assign different "sub" values
             for every JWT access token issued.In turn, the client
    should obtain a new JWT access token for every call to the resource
    server, to ensure that the resource server
             receives different "sub" and "jti" values at every call,
    thus preventing correlation between distinct requests.

    This profile does not define a specific parameter that allows a
    client or an end-user to choose between these three options for the
    "sub" claim parameter:

      * a globally unique identifier (that allows correlations between
        RSs and beyond),
      * a resource server specific identifier (to prevent correlations
        between RSs and beyond), or
      * an access token specific identifier (for anonymous accesses to
        one or more RSs).

    The choice between these three options for the "sub" claim parameter
    is managed by the AS.

    However, if the AS supports a "scope" parameter in the access token
    request, it is possible for the AS to define different scopes that
    support one or more of these options.
    Alternatively, an AS may use one of these options for all its
    end-users or some of them on a per-user basis. In addition, such a
    choice may depend on the RS being accessed.

Denis

> The IESG has received a request from the Web Authorization Protocol WG
> (oauth) to consider the following document: - 'JSON Web Token (JWT) Profile
> for OAuth 2.0 Access Tokens'
>    <draft-ietf-oauth-access-token-jwt-11.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2021-02-09. Exceptionally, comments may
> be sent to [e-mail] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This specification defines a profile for issuing OAuth 2.0 access
>     tokens in JSON web token (JWT) format.  Authorization servers and
>     resource servers from different vendors can leverage this profile to
>     issue and consume access tokens in interoperable manner.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth