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.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to