Re: [Txauth] Claims [was: - Dictionary]

Dick Hardt <dick.hardt@gmail.com> Fri, 24 July 2020 18:27 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F9C3A118D for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 11:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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=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 A4C_7iZii8ST for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 11:27:51 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 6F9A33A1184 for <txauth@ietf.org>; Fri, 24 Jul 2020 11:27:51 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id 140so5696040lfi.5 for <txauth@ietf.org>; Fri, 24 Jul 2020 11:27:51 -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=vpoUyOJbyQpMhcBpL9QDpwwOejgnHm0Okvx/PZolRZk=; b=UO1MeIAfP1EDEuXt75oOc/mylr83qO+prv/l+ok07gq7MPvx97qk5gpk8FxU5Z63Is XeQtb05A/s5FoPSx8shOxVbwoCuPGvyBHnA33uVI6Gl5Szh/8PXq+474sgVBeHTNogoM VTGD+nYtY1a9EHJu6wI6FP3Vq5sJOEcDRuSGCCQBTn90W0fJ89MrmaDQD9S+H4aHedRw tv/jL208zm7Ese1F2PWmE0QVnLd9KbugliZWvoMSvjntGZBjlrWDqxvDwlXl1le7T3Nh mQ0ykDmXaxpAS0GO1aB5+yWNCHpMt7XmQiAZsnUlbrBNaTtZ6d+Lf7nO1WNXSUE8Vdve szqg==
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=vpoUyOJbyQpMhcBpL9QDpwwOejgnHm0Okvx/PZolRZk=; b=NFDT0zCE33KscD/yjkgsUhltQGR5dB1q5tdvOGpcFNsYRfFUaPau6X7yFYOYtVniOM J4hHGgiLjvBSr7eD+XXr8ZObkk1t3fWWCHzt7g5k4IyKQ2QDxXf8KLnpYuZYHGgBtl5d uNDvMyydwvmfPZahEQvwFRmUayFUpW2rMH9dFQghEUJdTvzPLw1f24JH7/l6TM2jbmbt svluGObuEuCheryQ3SzvmQdBR57/YjH9iqgDTtU9Wnxm5lx29c1Y8G11JtayUAKYRKB7 COQXxD6YYf5biQwH5rCwZjl1q+J6KYIsaGNd4DtR6erbX06inuHfDpNre0E1CDNbo15w ASMw==
X-Gm-Message-State: AOAM532NUBGl3bm+VMLtwKEvNq41RJSV/sJ9TA4S3sfqG+ZYAPsoiKW6 nL9t3r7frpqdrUBhPbDcyI28JUTREJcM6rzO7wI=
X-Google-Smtp-Source: ABdhPJw0Rswlf2GPYG+XTBMsxKdQJ/csErxMVH765rAWrwNWGLzOOpM7tlex05aYQBtcm25T7jeW1I6Vgt2Vr6E9Odc=
X-Received: by 2002:a19:70c:: with SMTP id 12mr5713542lfh.207.1595615269385; Fri, 24 Jul 2020 11:27:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyO2C1E3Sg58CrSVT81t0T3iCTY87tdAx+a8d2A+cNa3nA@mail.gmail.com> <CAD9ie-vMzepgmaP-jUunKSo-chWrGpB230TWgJq7u8Yt-afDxA@mail.gmail.com> <CAOW4vyObyZC7USUqsW_qdDV9Hcpvg9OHKmM1yMEjSUvmjx0UZQ@mail.gmail.com> <CAD9ie-sWn41XDiwyFMcTgV3a8MMESXqf36fNJcTaSYDKwU+LPg@mail.gmail.com> <CAOW4vyNzGG95eNf6RRLf_jgHoQDMJHz8kPF10EENeaAq9vkrVQ@mail.gmail.com> <CAD9ie-vPDMPM8CRid169WsssD0r3dWNqoNCDJcgrxEs+MfvtjQ@mail.gmail.com> <CAOW4vyOjpL3Qoy02uV1dxc+wYir+yh0wWKiaV93OqzRXtk_Sxg@mail.gmail.com> <CAOW4vyMgW=3-nrgODnhj-BweWhJgW3WzTJDhSAwdnHFdho6msg@mail.gmail.com> <B55BD16B-8982-4621-A35F-6878F5045630@mit.edu> <CAD9ie-vA07gB-sQNc4Ft3jr6586N-Jh7dE5-e9ob8-wN_B0Xiw@mail.gmail.com> <CAOW4vyPQgQZ_fZB_rHvWFCvrTon4Vix7raTGG9gdc=Z1_=YA-w@mail.gmail.com> <EE0A9241-60D6-493F-9351-2F607D59D3E2@mit.edu> <CAD9ie-u9NUgPSFyUgeeuOYjJewmbugUON64cTttqhWWFGxf41g@mail.gmail.com> <CAK2Cwb4CR7PPDiifvv9s88OyBGpGNWCVSamY8xXp3PJxSx9wVg@mail.gmail.com> <CAD9ie-t6XJyF4ZjckQtoPz0zeZ-1p-RXUeQw6+N+fYrDgZ3ooQ@mail.gmail.com> <CAK2Cwb753sQ-=jtvD-qPTEAtmrmsBOWf+mTW2V4_eXw13JQonA@mail.gmail.com>
In-Reply-To: <CAK2Cwb753sQ-=jtvD-qPTEAtmrmsBOWf+mTW2V4_eXw13JQonA@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 24 Jul 2020 11:27:13 -0700
Message-ID: <CAD9ie-tnPLBK5g4486-2wLmd+P0a-ybJOgMWSGWFFf0Pz1BTjg@mail.gmail.com>
To: Tom Jones <thomasclinganjones@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Francis Pouatcha <fpo@adorsys.de>, txauth@ietf.org, Denis <denis.ietf@free.fr>
Content-Type: multipart/alternative; boundary="000000000000547c6d05ab342145"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/LvrS-cBQ6-iuJZeFmLXhssAUKdU>
Subject: Re: [Txauth] Claims [was: - Dictionary]
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2020 18:27:54 -0000

I'm not saying an access token cannot have claims. I'm saying what the
Client communicates to the GS so that there are claims in an access token
is out of scope for GNAP.

Said another way, GNAP specifies a container used by the Client to request
access tokens from the GS, and then presents those access tokens to the RS.
The contents of the container in the Client request, and the access token
contents, are out of scope of the core GNAP protocol.







On Fri, Jul 24, 2020 at 11:10 AM Tom Jones <thomasclinganjones@gmail.com>
wrote:

> now that is interesting.
> So that i can understand what you're saying.
> the access token that is issued (somehow) by the user to give the client
> access to rs resources, does not have claims?
> boy am i in the wrong place.
>
> Peace ..tom
>
>
> On Fri, Jul 24, 2020 at 10:50 AM Dick Hardt <dick.hardt@gmail.com> wrote:
>
>> Hi Tom, thanks for sharing.
>>
>> I would consider the guardianship use case to be issuing an access token,
>> not claims, as it is being used to access an RS.
>>
>> In my view, we keep Claims in GNAP to be only about the User, and the
>> only consumer of the Claims is the Client the User is using. This keeps
>> Claims from being overly complex.
>>
>> ᐧ
>>
>> On Fri, Jul 24, 2020 at 10:32 AM Tom Jones <thomasclinganjones@gmail.com>
>> wrote:
>>
>>> Nat and I just had this discussion about claims & the claims aggregation
>>> spec.
>>> An example about claims that are not entirely about the user is the
>>> gurdian ship case.
>>> That case can be solved by creating a signed set if claims (which needs
>>> a name) from the RO granting approval to the user to make a "ID Token"
>>> (whatever) from the as to the client to be passed to the RS.
>>> my suggesting is that claim as not necessarily attributes and the data
>>> about the ro from the rs are distinct from the claims about the user from
>>> the as.
>>> I do not believe that claims aggregation is about claims (at least not
>>> often).
>>> so then the data from. the ro would never be a claim, even tho it was
>>> identical in form and substance from the claim produced by the as.
>>> Peace ..tom
>>>
>>>
>>> On Fri, Jul 24, 2020 at 10:25 AM Dick Hardt <dick.hardt@gmail.com>
>>> wrote:
>>>
>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>> the OP in an ID Token, or the Client can obtain Claims using an access
>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>
>>>> The Claims are about the User (not a RO).
>>>>
>>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>>> directly in addition to the mechanisms in ODIC.
>>>>
>>>> So I don't think we are changing the definition of Claim from how it
>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>
>>>> Justin: you allude to Claims being about a party other than the User.
>>>> Would you provide an example?
>>>>
>>>> /Dick
>>>>
>>>> [1]
>>>>
>>>> UserInfo Endpoint
>>>> Protected Resource that, when presented with an Access Token by the
>>>> Client, returns authorized information about the End-User represented by
>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use
>>>> the https scheme and MAY contain port, path, and query parameter components.
>>>>
>>>>
>>>>
>>>>
>>>> ᐧ
>>>>
>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
>>>>
>>>>> I want to focus on one aspect here:
>>>>>
>>>>>
>>>>>> A Claim is a well understood term in the field. We should use it. It
>>>>>> is still a Claim if it comes directly from the GS or from an RS.
>>>>>>
>>>>> I do not understand why a Resource release by an RS shall be h to as a
>>>>> claim, even if the content of the Resource is an assertion. It will lead to
>>>>> confusion. If we limit claims to information GS releases into Token, User
>>>>> Info, and other objects it returns, this will help separate
>>>>> responsibilities between GS and RS. As soon as RS services and information,
>>>>> this is called a Resource, no matter the nature of the content of that
>>>>> information.
>>>>>
>>>>>
>>>>> This is exactly why I don’t think we should use “claim” in the way
>>>>> that we’re using it. Yes, a “claim” could come back through an RS — but in
>>>>> the context of GNAP, that makes it a resource. So we need a different word
>>>>> for data coming back directly from the AS to the client. Sometimes it’s
>>>>> going to be about the user, and that’s what we’re going to focus on here,
>>>>> but since you can also get information about the user from a resource we
>>>>> can’t just call it a “claim”. I think this has been at the heart of a lot
>>>>> of confusion in recent threads, as well as confusion about the scope of the
>>>>> inclusion of identity in the GNAP protocol.
>>>>>
>>>>> So let’s let “claim” mean what it already does, and let’s find a way
>>>>> to differentiate between when an item, claim or otherwise,  comes as part
>>>>> of a resource and when it comes back directly. This is an important
>>>>> differentiating feature for GNAP.
>>>>>
>>>>> Some straw man ideas, none of which I’m particularly in love with:
>>>>>
>>>>>  - direct data
>>>>>  - properties
>>>>>  - details
>>>>>  - statements
>>>>>
>>>>> The important thing here is that it’s not necessarily :about: the RO,
>>>>> and that it is :not: in a resource.
>>>>>
>>>>> Any other thoughts?
>>>>>
>>>>>  — Justin
>>>>>
>>>>