Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00

George Fletcher <gffletch@aol.com> Mon, 06 May 2019 20:48 UTC

Return-Path: <gffletch@aol.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 4F225120073 for <oauth@ietfa.amsl.com>; Mon, 6 May 2019 13:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=aol.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 8zfBS-1g7ySz for <oauth@ietfa.amsl.com>; Mon, 6 May 2019 13:48:06 -0700 (PDT)
Received: from sonic316-12.consmr.mail.bf2.yahoo.com (sonic316-12.consmr.mail.bf2.yahoo.com [74.6.130.122]) (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 D4B461200EA for <oauth@ietf.org>; Mon, 6 May 2019 13:48:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557175684; bh=zvwyTCN/lagHlD9K/mXLuu8cGIR+DTjpXe2aO6A0CIw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=reVzHaXBso97Abuhyuh1UBBzrkG+HCDpIOqMkpYCPi5oN66nhVF/WXCygFMaOqaX6XDQuyMygjI58UgAnvlowWPSsp42idi7D+sEh801/r1Byx6etTR3OqxHf3gL25/1bsx2o5Gm/BEXmgnnS8EOUefPljVHn6fYzbzaA9iXtP8X9p3Cs04ODY4IhWdjO8H2GJS/StQMeNPp8dudH6FGwvowmKbiNb1B53sjM5Nf20fM12VboJNVJzkE0P64jDp+NJrVtkGfajPWLucBe/zassZ/ii4axKLEifInFrj8q5PabvRnzFFyE0aQoDwQeJjMMBkipFvqGqqIqYZwvGnJXA==
X-YMail-OSG: OOS4R08VM1nUbOs4kuZ_4GU.hBsHyHuCIMXcrYvxG5pVCHVqlRU3l6bc4.YXpgX RiiYce4hP4Dw.44r3RSVs.pfDowsAfh1l_QX1H4u9BpBM_CognfnI8HkqO5Fqj5VNEI8WOMGMYUu MrGW6FXdPIIRBh3R2yrNrKr4QaJHmCMGTbXPBlxA6z6xi0hhGtikBoc.SBKCA8CaGyIp5zNruGBf B_lkbIdKrD4d__bTCtmh0UH8A06UAgcJtB0Cerb8WP2z.JX1beB9zNfvwiDnAsayh.QjVW2f9Up6 78m0y1fIWjTJ2x2APrebx9A40jo3A2DpSmambnNhV2AzrDfXuN0h7SzhgghPcR_oVWoiPGvrUUYn d_2d3FbCvLX_aUGgz68MBz8UjYf3pwrwnlph4GG8rdnLMnzRoBmZc1fGGIRiUvH32YXgPb1aU9v. ovhbJJf6YngXrC8c8_JijWrHinGyGYqxpLwa3lQWfQtJi4lStPM_hqb.4tAkGYyTOk9oXApANsl1 GqynRNMj7M2mx188EY5Es6FBIb.w.qzpYFgmCtNz29MCfe9EVOK9vQyIvlFW8ONbghfqIVHj2IEF jDCNFLH5WMDdPbCjGb5.lfqnlK7IKQNC_QDCTNbg_INWmBmGgRRZ7ZRmkhnWFvqW6hkAswJp31Ji rrShEwNc94TljJHIaDDWV1WfpPBstJzERHmTtVWM.VRat4Z4RQPpn3zwIp8GMENP_9hfoBrs95nd wXnCa2HWhzvBm3vERuuJUcRjpW8JHcfLR_bpi_iFjRVXB3uOFQHWQgbLn7jKdFxCWfDcRAWQDXVv VdUS59wiW6_5M0gqQ6iin2884NEBzF7Le4Ov2nSTzqBf_dF78maijnInpcdjHqWw2bieIf7UyGLI uLdboUJHf_BJiE_ubwVpIb1XFMw25CqzH78sFYY.4wYcldzTZzvILdgltrdfhnkajcd09BZriOMu lou5YEbJrcX.kmWjrkD_M6NNQ0SYy4cJZ.FL55t286mxdfUITTDB5TldlJ1oR8po0IeqRW6uhjcB C9PH5f1bS5SNrGJS2rUP7EjZgYFNuJH.hgXEtINB9ajwS3FoYLrlTi0jSb9F5izLAbqPgrN5qKah zcEtYK4NTjlZYIDZrpejoTcqRrj7Bm4p6obVKuVlKPmhAcrnILkEDpurw87NFOWKGa8bz1FdEfMI -
Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 6 May 2019 20:48:04 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp404.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9fb7e5a1fbce34104e0d4f6648536fac; Mon, 06 May 2019 20:48:01 +0000 (UTC)
To: Vladimir Dzhuvinov <vladimir@connect2id.com>, Vittorio Bertocci <Vittorio@auth0.com>
Cc: IETF oauth WG <oauth@ietf.org>
References: <CAO_FVe6eWy3zppQAij7qxD+ycYL8ebqGJKG0y-A7GhN+0=kb4g@mail.gmail.com> <CAHsNOKewL9xCFt6SsP4dz+W0CN_NUZaGMJahF7mSgos_Xbnhhw@mail.gmail.com> <CAO_FVe7c6jLRJ8mD7gw=a6NY3oZcgCh_b5dR8uRXa6Q2c2gmGg@mail.gmail.com> <CA+iA6uje229zrAos3c1TCuJEM+2vmVifNQ2FnKDuj2T4ET2SYA@mail.gmail.com> <a34edf0e-012a-ecc9-e547-3cdc61dca5a4@aol.com> <CA+iA6uh6Q901wEaqGSK7An0z0_iJTjCfvPVN44Qwpb=M_rDONg@mail.gmail.com> <239f40ab-da4d-03fe-4524-0b21a0bcc63e@aol.com> <SN6PR00MB0304BC3C7D438F8A5715B36DF5500@SN6PR00MB0304.namprd00.prod.outlook.com> <CA+iA6ugr+xPfeTFXK2gGBFX8Yw+zGArGfav=Ci5A3qNYUqB7rw@mail.gmail.com> <SN6PR00MB030459810B40D98370728BBAF5500@SN6PR00MB0304.namprd00.prod.outlook.com> <CA+iA6ug1NOpMcPsSr8o24CM3xWy-3z_pxiZhiyPeKxvScMACmg@mail.gmail.com> <CAO_FVe4AP5aWgXAAGj1QxPDFPjyfeaZGWd-b5azrz=ajuHuJdQ@mail.gmail.com> <229496c5-5953-be5d-0456-06ec6ee4caf9@connect2id.com> <CAO_FVe4XhWROvPwx4g1spaUrx1vOSCMyiMwP_1DAU-=mMRpc5A@mail.gmail.com> <88c03aa7-ba61-d0fe-97a1-b43f55d11b2d@connect2id.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <0eac74d2-1f0c-a567-c7ff-ce64a4c1c232@aol.com>
Date: Mon, 06 May 2019 16:48:00 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <88c03aa7-ba61-d0fe-97a1-b43f55d11b2d@connect2id.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/swmbWAea_1KudeFDT0IllxTrOO8>
Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
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: Mon, 06 May 2019 20:48:09 -0000

In OpenID Connect, aggregated and distributed claims are ways for the 
OpenID Provider to reference claims issued by other entities (e.g. 
attribute provider or "Issuer" in the SSI sense). There is no 
requirement from a spec perspective that the /userinfo endpoint be 
co-located with the AS. It seems to me that whether a /userinfo endpoint 
uses opaque or structured tokens is orthogonal to the need for access 
token claim definition.

It may be useful reference the claims specifications in OpenID Connect 
as a reference for user claim values in addition to the claims defined 
in the JWT spec.

Thanks,
George

On 5/6/19 3:49 PM, Vladimir Dzhuvinov wrote:
> On 06/05/2019 22:26, Vittorio Bertocci wrote:
>> I am not following, Vladimir. What do you mean? Can you make some examples
>> to clarify?
>> The userinfo is always colocated with the AS, hence I would expect most
>> vendors not to use JWT for the ATs issued for userinfo access
> That's what I was curious about, if there are any deployments with the
> UserInfo not being co-located.
>
> OpenID Connect also has this exotic use case, called distributed claims:
>
> https://openid.net/specs/openid-connect-core-1_0.html#DistributedExample
>
> If co-location is the common case, then there's really no need to spec a
> JWT claim for that.
>
> Vladimir
>
>
>> On Mon, May 6, 2019 at 12:21 PM Vladimir Dzhuvinov <vladimir@connect2id.com>
>> wrote:
>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-00#section-2.2.2
>>>
>>> In OpenID Connect the access token is consumed by the UserInfo endpoint.
>>>
>>> Were there any suggestions to also spec parameter(s) for the claims
>>> names (with optional locales) for release at the UserInfo endpoint?
>>>
>>> Vladimir
>>>
>>> _______________________________________________
>>> 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
>