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

Vittorio Bertocci <Vittorio@auth0.com> Tue, 14 April 2020 07:00 UTC

Return-Path: <vittorio.bertocci@auth0.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5272C3A0E37 for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 00:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLUx2A1ty3Eu for <oauth@ietfa.amsl.com>; Mon, 13 Apr 2020 23:59:57 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8632D3A0E1C for <oauth@ietf.org>; Mon, 13 Apr 2020 23:59:57 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id u5so3966597ilb.5 for <oauth@ietf.org>; Mon, 13 Apr 2020 23:59:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nRJJjgmL/HP4uludemOh06Q/ZlIKVC4lm8N/1LcVen8=; b=M5AHorjv4+QY125VSVuGJ0LJ5NYqa+UUKlNIROQsQN1f0kXkNl4c/q+5pbZ0d2om5V QLHZJUX+/QefEXKybBeAA8KW16COzjWUiUSMc12wWDfcjtuKXdbsZRPegROTv4NJYlFz bXew2LnUmSbEg52yJDzBiKtdUeAu7pNaJ+ozMlhH5jJ+8P+y/X37KrET9VjHsnfYkBQO NB4KGsNs3wfnZmWspc5qNwa5b3LowbSn6mekhu1Ui8QN+SUiVO/Vw6AdGWfrFWnM8NqN SyoOva4f1nBkwALbct+0/iuaDYiIg04inj45UM98SAqDYO4QyndLeVbI/n3rjCB8Ut7h 9PaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nRJJjgmL/HP4uludemOh06Q/ZlIKVC4lm8N/1LcVen8=; b=DCmn+/pzXKcsElcnSB0Y0E+jkipnWM0muzBmIOQSE+NiE33uldBB4ZHxVApe/3F0z7 HOSSqjasA9zqL32jR8VgQXW3MzakFg0LHChVo+BVAdi8LDbNINS6oCgTuJqABdTj6sPS uyqlD5sLPkBLUGPqmmlwENCa7suZnWsxGtE/JP90ECk/DfTClR9VIfOrEY3F6iIJ9l8A c+RH9KX7RBNBTHTW1Zr7MxnFHg6047Q/gapWqhVTdz/Etm8oyWKIQeAs1thTL53Ryn8L 90plK2mhl6bJ6SBVaJwIzIPz/PUB217gR3Ye9mKq0IJwecvWh9TZZ7rfhpbIy2Bs6Tfe Vn4w==
X-Gm-Message-State: AGi0Pua8BuUBZlehNVvjCqKRujPFyXhb4mLrxO4NKe20Jf24o66CXxOx N8lpbDq67OAdSeERbCIgEGXqB2E0wI23HGCE5QmgHS4w
X-Google-Smtp-Source: APiQypIRX1ryyNpb31APTf9CVNCUUbtwnfeVL93lZgjcUCgFIYbQ3392HGhdUt6uNGRRLdroDd6ujyKuvOO3HpHplkE=
X-Received: by 2002:a92:5d5b:: with SMTP id r88mr18565437ilb.206.1586847596417; Mon, 13 Apr 2020 23:59:56 -0700 (PDT)
MIME-Version: 1.0
References: <158628195716.9275.10690808358259357603@ietfa.amsl.com> <CAGL6epJ6W6AKptXw72cw2eaO+582_iYhKSK5h6BGBWeDJW9zNg@mail.gmail.com> <CAGL6epJc4CGDy9DwL3-BJh6MrELY3C-RUmcH716WN4k3Un11FA@mail.gmail.com> <361d7891-01be-8e22-7765-613e727b2bc1@free.fr> <CAD9ie-u4xaoRmNG3Sgj+cNWG4M8BzaM1YFF4Oy4Q2A6gdFWDhw@mail.gmail.com> <CAGBSGjpV=QNHPJfXXLcxHwYwHZrKXEQVjf3eJg+b8z=qpRAJcA@mail.gmail.com> <CAO_FVe67Ta_c1stGAH2b6mC_9FcfcZ_Vs6OdD4S4--vOac_y-g@mail.gmail.com> <CAO_FVe7hZH+83=OzU3b-c_b1XkCKbbKe+EVQ5vs++HO31orWkg@mail.gmail.com> <CAD9ie-ucnSnE=yW6PM6BFke7aS+Hs6z5DrE3zg0YLiikeK=9Ww@mail.gmail.com>
In-Reply-To: <CAD9ie-ucnSnE=yW6PM6BFke7aS+Hs6z5DrE3zg0YLiikeK=9Ww@mail.gmail.com>
From: Vittorio Bertocci <Vittorio@auth0.com>
Date: Mon, 13 Apr 2020 23:40:27 -0700
Message-ID: <CAO_FVe7Ki=9+GGGRQUb3+shEiNkn4Dvpa9S6ukCZvkPOOKBHhQ@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Aaron Parecki <aaron@parecki.com>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004c2a5505a33abf04"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gUlES3JHS1_upczNJvlQPgAlBkA>
Subject: Re: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2020-04-13
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2020 07:00:03 -0000

> An SDK is going to support "sub" wether it is required or optional.
When I think about support for sub in this case, I am not thinking about
just parsing the sub value if it’s present or not surfacing it in an object
model if it’s not- i think about reliably offering the higher level jobs to
be done that are made possible by the sub presence (such as the correlation
with the calling subject and local information, exactly as in your example
all the movies a user watched thru that particular API).

> the resource is learning that the same user is doing different
transactions
Thanks for the clarification, I didn’t realize that you were not just
considering correlation across resources, but across calls to the same API.
And you are right that in that case, an API would be able to correlate the
user across subsequent API calls.
Per the above, I think that the ability of performing that correlation
inter-API is a goal on most systems. More below.

> But NOT every token. So there were use cases where it was not required.
Not that it proves anything conclusively given that I only sampled 7
system, but sub was actually used by all of them- with one of them omitting
it only in a particular circumstance, for tokens issued via client
credentials grant, and leveraging its absence as a way of deducing the
nature of the token (user or app identity). During earlier drafts we
debated at length the issue of providing mechanics to perform that
distinction and the outcome was that there was no interest in providing it;
and in the same debate it was established that sub applies to the
authenticated entity, hence it can describe the app principal as well.
Again, the fact that the main analyzed systems don’t make a strong case for
the absence of sub doesn’t imply that no such case exist; but I believe it
is a strong indicator of sub usefulness in real world scenarios. In fact,
together with iss and aud, sub is the only claim appearing in every
provider JWT AT examined (Tho both sub and aud have each one exception due
to special circumstances).

I am fine with explicitly calling out that the presence of a mandatory sub
makes it possible for an API to correlate subsequent calls on the same
entity. I am ready to bet it won’t be a surprise for people using
proprietary JWT ATs, also thanks to the widespread practice of using
slightly modified ID token validation SDKs (when ID token themselves aren’t
directly used in lieu of ATs for API calls, as done by the likes of
Kubernetes and other mainstream products, which hopefully will eventually
consider this profile instead).

As a last resort, nothing forces the AS to stop at varying sub values only
per resource; it could go farther and supply a different sub value at every
token issuance for the same authenticating principal if it so chooses, and
still adhere to the letter of this profile while preventing cross operation
correlation. That would adhere to the letter of this interop spec if not
the the spirit, given that layout would be respected and one can creatively
define principals in its own system. If Apple can assign anti correlation
emails, nothing prevents an AS doing the same with sub at different
granularity.
That would break the job to be done that sub is meant to enable, but would
prevent correlation in practice AND it would allow for us to include a
piece of info that proved to be useful for a large portion of known cases.
But to reiterate, even if this workaround would not be possible, I would
still be OK with admitting cross operation correlation within the same
resource as by design.


On Mon, Apr 13, 2020 at 18:05 Dick Hardt <dick.hardt@gmail.com> wrote:

>
>
>
> An SDK is going to support "sub" wether it is required or optional.
>
>
>
> On Mon, Apr 13, 2020 at 1:40 PM Vittorio Bertocci <Vittorio@auth0.com>
> wrote:
>
>> “Ide rockers” is iPhone autocorrect jargon for “identifiers”, of course :P
>>
>> On Mon, Apr 13, 2020 at 13:13 Vittorio Bertocci <Vittorio@auth0.com>
>> wrote:
>>
>>> 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 privacy correlation I described is not solved by a per resource
> directed identifier as the resource is learning that the same user is doing
> different transactions -- or per my example, the resource is learning all
> the movies the user is seeing.
>
>
>>
>>> The sub is mandatory here because it was present in nearly every token
>>> among the ones observed,
>>>
>>
> But NOT every token. So there were use cases where it was not required.
>
>
>> 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.
>>>
>>
> NOT correlating all the different actions by the user may be the desired
> privacy goal by a deployment.
>
>
>> 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
>>>
>>
> Per Aaron's comment, if this profile is NOT intended to support use cases
> where the RS should not be able to correlate a user between resource
> accesses, then it is fine for "sub" to be required. If so, then the
> document should strongly point that out.
>
>
>>
>>> On Mon, Apr 13, 2020 at 10:16 Aaron Parecki <aaron@parecki.com> 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 <dick.hardt@gmail.com>
>>>> 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 <denis..ietf@free.fr
>>>>> <denis.ietf@free.fr>> 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.
>>>>>>
>>>>>> https://datatracker.ietf.org/meeting/interim-2020-oauth-04/session/oauth
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>  Rifaat
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>> --
>>>> ----
>>>> Aaron Parecki
>>>> aaronparecki.com
>>>> @aaronpk <http://twitter.com/aaronpk>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>