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

Vittorio Bertocci <> Mon, 13 April 2020 20:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B47D03A1D71 for <>; Mon, 13 Apr 2020 13:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WNSbV2WRMnw7 for <>; Mon, 13 Apr 2020 13:14:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E0733A1D6F for <>; Mon, 13 Apr 2020 13:14:06 -0700 (PDT)
Received: by with SMTP id w20so10784921iob.2 for <>; Mon, 13 Apr 2020 13:14:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lpu37cRON/21RPGWIWYg3TV1QhqPL3HCtSzDvy8d93g=; b=ltdw9S3NjfG4jxOpVk7oeh6LhqIBalsxwEpLDgR0plICzY6dytzc6gjIQChnN85nBI eynzUYKJFp5CFADXxQHi4rfSM7GnreWcmY2C5Bu8iEMuP0vJiuDZHAvuTOgNfP91d99A Sh85LVTA0MNSkGVF/HpoQQEX8k6zV1HhUrlWPO2gwhJlJ0ZQf8UFHr0/eGe4Nk/ilP1U zRwPVknI4XFRt7HqS0G9yHaLA/3F/k4nOgQsHd48vveX5UtMGQoMC9KaFTaSnFK/MEo+ Cr1uAwESxR8sE2jy6EAHy17v7tqL314stK5XXSj459Xk8FcnAx9rN9V5H7K8ApDj0D2d F2Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lpu37cRON/21RPGWIWYg3TV1QhqPL3HCtSzDvy8d93g=; b=Zi0lN30tCYY4Lz2RnA5ZlQ3ID9kpo/cvpNirZZXGU0mxQ9c0K01qb62wNxSUxetbbI DaqUh5GRtc4SAQApStWK1IdZjqwJ9Ue4vhgKPpG6DuEw1uat7BpNpsNyApb4f0lFEILT AFK/mQZBCGzGEvTa1CvNSBZFh7lGDbHKDVY3uCL1lPGfr4j7KTTcN0WjnnXfosJEiU38 2m8wpZsA+6LB7/twsx42AkPGKGRIUoKUJhDbnPEdRlft5rcpisNx2t0vDKr7dt3TCbde 4076ZbqMGdgPMR75f0c6rxnCOyupQvkJr6CnnVCsM1kAF9YygdRaSb2AiLtF6pfXx2oG drJA==
X-Gm-Message-State: AGi0PuZEMKbrpI5jNE0skps5SWaf48jTTswacs+yamldE8rtokoRVqD/ YfaT6Xyz6rS+wI4cPR90BcMdQ9PdiNCkRBwOuFf6Aw==
X-Google-Smtp-Source: APiQypK3YqYOgnadESK3BGjx/dOqA64NDUt4eavLMypqmbDFBWNQNgD2QPujl/ISGiVuYzHvdunU1gh5B+kJe0/SaHA=
X-Received: by 2002:a6b:4109:: with SMTP id n9mr17770848ioa.141.1586808845442; Mon, 13 Apr 2020 13:14:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Vittorio Bertocci <>
Date: Mon, 13 Apr 2020 13:13:54 -0700
Message-ID: <>
To: Aaron Parecki <>
Cc: Dick Hardt <>,
Content-Type: multipart/alternative; boundary="0000000000008f365c05a331b92c"
Archived-At: <>
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Apr 2020 20:14:09 -0000

It’s certainly possible to conceive ATs without subs, but I think the
profile would be way less useful for SDK developers.
On the objections:
The sub doesn’t have to be a user, if you look at the earlier discussions
the case in which the token has been issued for an application via client
creds (hence non user) has been debated at length.
Knowing the subject does not necessarily lead to API being able to collide
and track users, given that the sub can be a PPID that is different for
every resource even if the authenticated subject was the same.

The sub is mandatory here because it was present in nearly every token
among the ones observed, and although one should not overindex on those
scenarios, I took that as strong indication that it is a frequently used
field and guaranteeing its presence facilitates embedding in SDKs lots of
downstream features, such as correlating with locally stored attributes,
which would otherwise left as exercise to the reader. Per the points above,
there are no obvious downsides in requiring the presence of the sub and
significant upsides. Again, the AS is in full control of the sub content
hence none of the privacy concerns mentioned here are mandated by the sheer
presence of the sub claim. If you feel the privacy section should be
stronger in warning an AS against the possibility of collusion if global
ide rockers are used, I am happy to reword accordingly

On Mon, Apr 13, 2020 at 10:16 Aaron Parecki <> wrote:

> This is a good point, I often use the hotel key analogy as well. The room
> door is the RS, the key is the access token, the door does not need to know
> who the user is in order to know if it’s okay to unlock given a particular
> key.
> If sub is required, then this profile is limited in use to cases where
> user identifiers are part of the system, and there will be situations in
> which it’s not appropriate to use this profile for access tokens. If that’s
> okay, this should be clarified in the overview section to describe when
> this profile should be used.
> Aaron
> On Mon, Apr 13, 2020 at 10:08 AM Dick Hardt <> wrote:
>> Why does the "sub" need to be required?
>> An access token is to prove authorization. The RS may not need "sub" to
>> constrain fulfilling the client request.
>> For example, it the access token has the same properties as a movie
>> ticket, the RS does not need to have any identifier for who purchased the
>> movie ticket.
>> The privacy implication is the RS can correlate across API calls to know
>> it is the same subject.
>> On Mon, Apr 13, 2020 at 8:16 AM Denis <
>> <>> wrote:
>>> 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.
>>> Regards,
>>>  Rifaat
>>> _______________________________________________
>>> OAuth mailing list
>> _______________________________________________
>> OAuth mailing list
> --
> ----
> Aaron Parecki
> @aaronpk <>
> _______________________________________________
> OAuth mailing list