[OAUTH-WG] About draft-ietf-oauth-access-token-jwt-10

[Denis <[e-mail]>]

Hello Vittorio,

I have three comments numbered 1, 2 and 3.

*Comment 1:**
*

Section 3 states:

    3.  Requesting a JWT Access Token

        An authorization server can issue a JWT access token in response
    to any authorization grant defined by [RFC6749] and subsequent
        extensions meant to result in an access token.

        If the request includes a "resource" parameter (as defined in
    [RFC8707]), the resulting JWT access token "aud" claim SHOULD have
        the same value as the "resource" parameter in the request.

I had a discussion I had on the mailing list with Hannes on September 10:

    [Denis] I believe, it would be worthwhile to add a sentence, just
    after this sentence, with the following text:

      When an authorization server decides to issue a JWT access token
    compliant to this profile, then the following requirements apply.
        (...)

    [Hannes] That’s fine for me because this is what the intended effect
    of the spec is.

This portion of text from section 3 should be changed into:

    3.  Requesting a JWT Access Token

        An authorization server can issue a JWT access token in response
    to    any authorization grant defined by [RFC6749] and subsequent
        extensions meant to result in an access token.

    *When an authorization server decides to issue a JWT access token
    compliant to this profile, then the following requirements apply. *

        If the request includes a "resource" parameter (as defined in
    [RFC8707]), the resulting JWT access token "aud" claim SHOULD have
        the same value as the "resource" parameter in the request.

*Comment 2:**
*

Section 6 states:

6.  Privacy Considerations

        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.

RFC 2119 defines the meaning of MUST NOT or SHOULD NOT:

    2. *MUST NOT*   This phrase, or the phrase "SHALL NOT", mean that
    the definition is an absolute prohibition of the specification.

    (...)

    4. *SHOULD NOT*   This phrase, or the phrase "NOT RECOMMENDED" mean
    that  there may exist valid reasons in particular circumstances when the
        particular behavior is acceptable or even useful, but the full 
    implications should be understood and the case carefully weighed 
    before implementing
        any behavior described with this label.

The first sentence of section 6 recognizes that it is technically 
possible for clients and potentially even end users to directly peek 
inside the token claims collection.
There may exist valid reasons in particular circumstances when the 
particular behavior is acceptable or even useful, but there is no 
assurance that this can be done
since the authorization server and the resource server might decide to 
change the token format at any time.

The sentence :

    The client *MUST NOT* inspect the content of the access token:

should be changed into:

    The client *SHOULD **NOT* inspect the content of the access token:

*Comment 3:**
*

Section 6 also state:

   This profile mandates the presence of the "sub" claim in every JWT 
access token, making it possible for resource servers to rely on that
    information for correlating incoming requests with data stored 
locally for the authenticated principal.  Although the ability to
    correlate requests might be required by design in many scenarios, 
there are scenarios where the authorization server might want to
    prevent correlation.  The "sub" claim should be populated by the 
authorization servers according to a privacy impact assessment.  For
    instance, if a solution requires preventing 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.  Similarly, if a solution 
requires preventing 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.

As already mentioned on this mailing list, the above sentences would 
modify the semantics of the "sub" claim.

      While reading RFC 7519, no reader may be able to figure out that 
there are more than two flavours of the "sub" claim.
      This draft would be introducing two new other favours of the 
semantics of the "sub" claim which are not present in RFC 7519.
      When an element has been defined, its semantics cannot be changed 
... unless making an Errata to RFC 7519  which would be
      a clean way to proceed.

RFC 7519 defines the sub claim in the following way:

    4.1.2.  "sub" (Subject) Claim

        The "sub" (subject) claim identifies the principal that is the
    subject of the JWT.  The claims in a JWT are normally statements
        about the subject. *The subject value MUST either be scoped to
    be locally unique in the context of the issuer or be globally unique.*
        The processing of this claim is generally application specific. 
    The "sub" value is a case-sensitive string containing a StringOrURI
        value.  Use of this claim is OPTIONAL.

Change into:

    This profile mandates the presence of the "sub" claim in every JWT 
access token, making it possible for resource servers to rely on
    that information for correlating incoming requests with data stored  
locally for the authenticated principal. The "sub" claim is scoped
    to be either locally unique in the context of the issuer or be 
globally unique (see section 4.1.2 from RFC 7519).

    When the "sub" claim is scoped to be locally unique in the context 
of the issuer,  in the event of resource servers collusion, it can be 
used to correlate principals.

   When the "sub" claim is scoped to be globally unique, in the event of 
resource servers collusion, it can be used to correlate principals not 
only between resource servers
   but it can also be used to correlate principals between resource 
servers and other servers that do not implement this protocol but are 
using the same globally unique identifiers.

Denis

> Thanks Brian, Logan.
>
> On clarity. I tweaked that section and produced a new draft (-10).
> Details:
>
>   * Formally, the fact that we are referring to the User entity should
>     be unambiguous. 4.1.2 is a subsection of 4.1, which is titled
>     "User Resource Schema”.
>     However as a frequent critic of the excessive cyclomatic
>     complexity of the specs, I am making myself guilty of precisely
>     the same sin 😊 your suggestion can save the reader the need to
>     follow and parse the reference to understand the situation, hence
>     it’s a good improvement to clarity.
>   * For what concerns the actual format of the claims. The groups
>     entity actually appears as non-normative example in
>     https://tools.ietf.org/html/rfc7643#section-8.2; I can make an
>     explicit reference to that and make things a bit more discoverable.
>   * For roles and entitlements, things are murkier.
>     Before embarking in this endeavor I too had the expectation that
>     this would be a flat list of strings, but digging a bit in
>     existing implementations it turns out that’s not necessarily the
>     case. For example, Slack SCIM represents individual roles as two
>     possible forms { “value”:<name>, “primary”; <bool>}|  {
>     “value”:<name>}, whereas databricks uses{ “value”:<name>}; WSO2
>     uses{ “value”:<name>, “type”; <enum>}.
>     So for those two I don’t think we can do better than the current
>     statement about SCIM not supplying a vocabulary for them.
>   * I had some issues w the references where the section links were
>     turned into local links, as it happened in the past. That should
>     be fixed too.
>   * I applied the “” notation to the attributes, given that we are
>     turning them into claims it seems clearer to sue the same
>     typographic concention.
>
>   * side note… <nonexistent section reference>
>
> Excellent point, fixed.
>