Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13

[Denis <[e-mail]>]

Hello,

More on privacy about "JWT Profile for Access Tokens".

The current document REQUIRES the claim names *sub* and *client_id*.

  * sub  REQUIRED - as defined in section 4.1.2 of [RFC7519].
  * client_id  REQUIRED - as defined in section 4.3 of [RFC8693]

*1) **sub  REQUIRED*

RFC 7519 states:

    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.*

If *sub *is *REQUIRED *for this profile, then this allows all resource 
servers to link accesses made by the same client on different servers.

*2) client_id  REQUIRED*

RFC 8693 states:

    4.3. "client_id" (Client Identifier) Claim
    The client_id claim carries the client identifier of the OAuth 2.0
    [RFC 6749] client that requested the token.

RFC 6749 states:

    2.2.  Client Identifier
        The authorization server issues the registered client a client
        identifier -- a unique string representing the registration
        information provided by the client.  The client identifier is not a
        secret; it is exposed to the resource owner and MUST NOT be used
        alone for client authentication. *The client identifier is
    unique to**
    **   the authorization server.*

If *client_id* is REQUIRED for this profile, this also allows all 
resource servers to link accesses made by the same client on different 
servers.

*Both claim names should be OPTIONAL *to allow to support the privacy 
principle of unlinkability.

Would both names remain *REQUIRED*, the Privacy considerations section 
should mention that such a linkage by different resource servers
will always be possible when using this profile.

Denis

> I have uploaded the second presentation for today's session, the JWT 
> Profile for Access Tokens.
> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
>
> Regards,
>  Rifaat
>