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

Dick Hardt <dick.hardt@gmail.com> Tue, 14 April 2020 01:05 UTC

Return-Path: <dick.hardt@gmail.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 58DC13A226A for <oauth@ietfa.amsl.com>; Mon, 13 Apr 2020 18:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LMx9tCinu6W6 for <oauth@ietfa.amsl.com>; Mon, 13 Apr 2020 18:05:15 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 BFBD73A2268 for <oauth@ietf.org>; Mon, 13 Apr 2020 18:05:14 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id l11so8027449lfc.5 for <oauth@ietf.org>; Mon, 13 Apr 2020 18:05:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YJWcF0PISBlOLvN7ctF1U5alTc3PO1S5o5zawVJAsT0=; b=TPISeYBQUDcRNmZgkO3etNzi/3b2YSTi/CUvrA2jriF5saCxnM5fqZRrL/4BQCqnx4 aqv5kqjVkmd60aqubq5Qz7tPnylsJE0ByeI6zY4cN2ER0wcUpEyJFL1/ZfIpg2K1j29B cbmaRRgWTfOzQ6yt7GkEz5c2pgc1T0BeBEehzWsK6rY542X2XYQaCVx4HD/yuZQdmy4q nHrUTHmYMUWwqqncIwyY1SecZ54U6jYopKvHSvGHsIU7k96BKGDc9ApfNKh+W/7zbTpG DBM6CuqvnIO2hetv0su0nZ3yq93H1lFDVWtYwJjWRW4iLHmdf37hQrUDlGrgCrOpaU9Q Kl6w==
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=YJWcF0PISBlOLvN7ctF1U5alTc3PO1S5o5zawVJAsT0=; b=C6w7/Pe6GYYK3D5WcBmdUQpNTs+XTbGSzsnKjnCI2eLcZ0kjVef0K4UT24JxoERovf SuZZFMn+tcXpsGtvm2H3OOQ9o1jfLIGiD1okEuhiAPEknONPtj9k8e/B6/MoZF0deUbF /aPjJnzkLDeevwJN8tv+qqTd2Jxx2J1vT+LM+zvsI9uhCPM5jFaaBuMt8Hry8NSR/WXW Jr3bEMllTUOO7vLwGFCEC2FT2T+Qtdx1KiasmJhXKjxP4Qs1Zq2O6WZOWR7N6kRXxoUl beYuMnX/ADfkNWPjAGCOroKXfNhyL7NYYYodUI0BdwGnFlJ55jSHsdzrI1GcZAUUFMCT JlqA==
X-Gm-Message-State: AGi0Pub3GamxLY4vY4wWPcxNtD79Cdz2CX2UygKeWdxA0lrphYNiDneK hBaSR37xcuBbp0cu5QbN2rblM+tUxNRJe6etZfcDKyS6ZaA=
X-Google-Smtp-Source: APiQypJIZCmVVsBgUrxPiRIzY/4cZxc0u0ML+YkTCdO/Fy9YgtD8EbzCnpcZlLzBmUWEIKYY6Pp9qmzOm5H0PPlX8sk=
X-Received: by 2002:a19:9109:: with SMTP id t9mr12025703lfd.10.1586826312861; Mon, 13 Apr 2020 18:05:12 -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>
In-Reply-To: <CAO_FVe7hZH+83=OzU3b-c_b1XkCKbbKe+EVQ5vs++HO31orWkg@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 13 Apr 2020 18:04:46 -0700
Message-ID: <CAD9ie-ucnSnE=yW6PM6BFke7aS+Hs6z5DrE3zg0YLiikeK=9Ww@mail.gmail.com>
To: Vittorio Bertocci <Vittorio@auth0.com>
Cc: Aaron Parecki <aaron@parecki.com>, oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b2ceff05a335ca17"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/54nn6oguUF8RfQyqkqVWV_j01z0>
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 01:05:17 -0000

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