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

Dick Hardt <dick.hardt@gmail.com> Mon, 27 July 2020 22:59 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 C18EA3A0991 for <txauth@ietfa.amsl.com>; Mon, 27 Jul 2020 15:59:47 -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 3AErsBa9GTv1 for <txauth@ietfa.amsl.com>; Mon, 27 Jul 2020 15:59:43 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 B7B563A0898 for <txauth@ietf.org>; Mon, 27 Jul 2020 15:59:42 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id m15so9250785lfp.7 for <txauth@ietf.org>; Mon, 27 Jul 2020 15:59:42 -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=kPRebEUoE3a9BCTnXXOF05TqSb3sBP6eUoB3CSvZNiY=; b=rC681dHYFSBru1AmA6OTKoPdu5V4zRz7xr/XllbGH0hdOMC741UiIBPW2sNpMsRMER T83+bQ7JUB3tdQycIildzMShqUlKBqasvzQ93BUB5fJE9ClplDzpCxoQ0ru2n3Sue36V B+olYGYoTMkkTN2mN64Se/Ozux26YCOPlNJyTEnO8vCKoC3A2Xq/bC7/Nu4SerYgbbSO pTEF4rhSd5MLUSAzvurzQ+BJtTDq7XnBKsXC28zuR2ONtFx4V/oTEJJPUWgq3S3yjlvQ 9JioOXBejGOvgV7dq2oJHnr5aq3v1UmvLOktwNU84g25yKvzZLpO/luWW4px9CXx1UsR xopA==
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=kPRebEUoE3a9BCTnXXOF05TqSb3sBP6eUoB3CSvZNiY=; b=MHTq8bkNCDAh1LyKZEpSvQRsfz6ZVLUso+CBApri86GdgGi9sugdHyGFvh3UujZF3i pz5GS+yJRbIgPTemdBx66rqKjsDkcRnQzeYCZ1x9TV3T6k8IPp7kOMvJPunEKmF0Pser 9kdStsHkSOUA+niA+X6f1Tz1ZwomwI6ycZLKd0oSikO5kmHAEZW3wDEx1t1h9FNgmpUD TWbvBl+YoW24cGxVaptKsCDZXK0KfODQeyT5QB425QFiHF3iCSOguN1JTYm0IlSSxk2M PDbjhmjHKEo6Y7xprk7LNMs2jCmy9Vg8wrkvnxeP8XX5ojUbJBaTsevd9Z6Oinf78Ipe lElQ==
X-Gm-Message-State: AOAM530qg69xbO/6uNDNfyFwQB89ZlrUyBff1h/IOIz/CRWjWpkjiwMq 6c6bpSPO7WN1EgaxKn89jWXjoAxWQWWxVZQJHks=
X-Google-Smtp-Source: ABdhPJxTVFA666gO4egcEC7H969c4UgFTetxo5z9kIZNbcUNEnyYpKkbyVWZJx/Jl40D/0IDBh1S/c+KytQNIK/vZ84=
X-Received: by 2002:ac2:4a9d:: with SMTP id l29mr12671691lfp.23.1595890780297; Mon, 27 Jul 2020 15:59:40 -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> <E5F32EB4-D47E-4E40-9F2A-9C25E7DFB86B@mit.edu> <CAD9ie-v1aRaGWEsrs71YfzZ2pdzEdLmmzKfzpVCY1dEHStnJmA@mail.gmail.com> <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu> <CAD9ie-vonF5XRk=1Rm+=gPMBxzNXG=gWmPv7_RMRt4NNNetOLg@mail.gmail.com> <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu> <CAD9ie-v-3+zBhZz7WWz5zCM7tnN0SU7pLrsiNhGsmmKa3SN4CQ@mail.gmail.com> <E2EF1969-1840-4AAC-99DE-734ED687033C@mit.edu> <CAD9ie-ug3z=kTKrRGkj7VfUCYOtSDmm2sA31z-Ph-7jxNm6_SQ@mail.gmail.com> <B769DD17-8A67-4ED4-B579-3EDB2D819828@mit.edu>
In-Reply-To: <B769DD17-8A67-4ED4-B579-3EDB2D819828@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 27 Jul 2020 15:59:04 -0700
Message-ID: <CAD9ie-sVdGK3pwLppedtFMQg60KJ4VrGBAWGPpQCNROTJf5tYQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Francis Pouatcha <fpo@adorsys.de>, txauth@ietf.org, Tom Jones <thomasclinganjones@gmail.com>, Denis <denis.ietf@free.fr>
Content-Type: multipart/alternative; boundary="0000000000000f613b05ab7447ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/X6FF1BSvUforZLoYFaqMujTKUng>
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: Mon, 27 Jul 2020 22:59:48 -0000

No, that is not accurate. XAuth is a super set of XYZ (as currently
written) as XYZ does not allow the direct return of claims from the GS.

If the Client wants an access token to retrieve Claims (name and email), it
includes the following JSON in its Grant Request:

"authorizations":{
    "token_1": {
        "type": "<standard_name_space>oidc_userinfo",
        "claims": { "email": null, "name": null }
    }

note: "standard_name_space" is to have a standardized RAR type for
oidc_userinfo


If the Client wants to get bare claims for name and email directly from the
GS, it includes:

"claims": {
    "oidc_userinfo": { "email": null, "name": null }
}

If the Client wants to get an ID Token containing name and email, it
includes:

"claims": {
    "oidc_id_token": { "email": null, "name": null }
}


Access tokens are always requested and returned in the "authorizations"
object, including if the access token is to access claims at a userinfo
endpoint.

Claims are always requested and returned in the "claims" object.

/Dick


On Mon, Jul 27, 2020 at 1:11 PM Justin Richer <jricher@mit.edu> wrote:

> I may have figured out a bit about how these approaches are actually
> different and why we might be talking past each other.
>
> From what I can see, the Xauth style query is basically saying “here’s a
> block asking for all the identity stuff in the protocol, and telling you
> where to put the identity stuff in the response no matter where that is”.
> So this is why “claims” are the high-order element where things like query
> style and delivery are details of that.
>
> XYZ takes a markedly different approach, basically saying “here’s a block
> that asks for stuff coming back from an RS and here’s a different block
> that asks for stuff coming back from the AS directly”. Some of those things
> coming back, in either place, could be claims about the user. (Or really
> claims about anything else, if you want to use the wider definition of the
> term.)
>
>
> So fundamentally the composition is different. Xauth lists the identity
> stuff all together, whereas XYZ splits identity stuff based on how it’s
> coming back. Xauth seems to prefer describing all the identity data to be
> returned regardless of how it’s returned. I prefer the XYZ approach, where
> resources are always resources regardless of what they’re about, and direct
> data is always direct data regardless of what it’s about.
>
>
> Is that an accurate read?
>
>  — Justin
>
>
>
> On Jul 27, 2020, at 9:45 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> A slide in my presentation today may clarify how I am thinking about it.
>
> On Mon, Jul 27, 2020 at 4:23 AM Justin Richer <jricher@mit.edu> wrote:
>
>> Since you focused on the individual elements of the straw man examples
>> you requested instead of the overall problem, I think you’re missing the
>> core point. Let me bring it back to a concrete example:
>>
>> In Xauth currently, you can use the “claims” query syntax from OIDC to
>> request user claims inside the “claims.oidc” object on request. However,
>> Xauth currently uses “userinfo” to mark information coming back directly to
>> the client as JSON. Since “userinfo” is already defined by OIDC in this
>> context to indicate information that should come back from the UserInfo
>> Endpoint (and therefore as a resource, with rights tied to an access
>> token), the Xauth approach would need a name other than “userinfo” here to
>> indicate such claims coming back directly as JSON.
>>
>> What would you call that field?
>>
>> Because whatever that field would be called is exactly the kind of data
>> differentiation that I’m talking about here. And considering that Xauth
>> already does differentiate between claims coming back as resources, as
>> assertions, and direct JSON, I think it’s clear that it does matter.
>>
>>  — Justin
>>
>>
>> On Jul 24, 2020, at 4:57 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>> It is not clear to me what it matters if a Claim comes from an RS, or
>> from the GS, so I don't see a need to differentiate them.
>>
>> I would include verifiable credentials and user-bound keys as Claims.
>>
>> All the payment processing information I have seen has been in RAR. When
>> would the Client get payment processing directly from the GS?
>>
>> What is your example for distributed networks storage locations? If what
>> is stored is a statement about the user, then I would consider that a Claim
>> as well.
>>
>> We disagree on how to map OIDC to GNAP.  The direct data is a claims
>> request, the data coming indirectly is an access token request.
>>
>>
>>
>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer <jricher@mit.edu> wrote:
>>
>>> Since we’re already talking about returning claims as direct data as
>>> well as a part of the resource API being protected, so we already need a
>>> way to differentiate the two kinds of items. Just calling it “claims”
>>> doesn’t help, because as you’ve pointed out they could show up in both
>>> places. So yes, defining that difference is something we should worry about
>>> now, even if the core protocol only uses it for claims.
>>>
>>> The two forms of direct data that XYZ returns are subject identifiers (a
>>> subset of identity claims) and assertions — the latter being a container
>>> not just for identity claims but also authentication information and other
>>> elements. Assertions are not claims themselves.
>>>
>>> Other use cases that have been brought up include verifiable credentials
>>> and proofs, user-bound keys, payment processing information, and
>>> distributed network storage locations. I’m sure there are a lot more. To
>>> me, these are subsets of the “direct data” but not subsets of “claims”.
>>> GNAP shouldn’t be defining what all of these look like, but it should
>>> define a way to talk about them.
>>>
>>> I think different top-level request objects are better suited for
>>> different query semantics. Like, for example, the OIDC “claims” request,
>>> which allows targeting of its claims information into different return
>>> buckets. This overlaps with the “resources” request at the very least. I
>>> don’t think GNAP should define how to do this specific combination, that
>>> should be for OIDF to debate and apply. The same with a DID service based
>>> query, or Presentation Exchange [1], or anything else that people want to
>>> come up with.
>>>
>>> In my view, GNAP should define query structures for two things: rights
>>> that get tied to an access token and data that comes back directly to the
>>> client. For the latter, I think we can do some very limited and very useful
>>> specific items, which is what I’ve put into XYZ.
>>>
>>>  — Justin
>>>
>>> [1] https://identity.foundation/presentation-exchange/
>>>
>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>
>>> I agree we want GNAP to be a strong foundation.
>>>
>>> Do you have an example of other "direct data"? If so, do you expect it
>>> to be defined in the core protocol?
>>>
>>> I would expect an extension for other "direct data" to define top level
>>> objects, and an appropriate definition for that "direct data".
>>>
>>> My "do we need to worry about it now" comment was on creating a generic
>>> term for "direct data". Unless we are solving those now, we can let further
>>> work define that "direct data" explicitly.
>>>
>>>
>>>
>>>
>>> ᐧ
>>>
>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
>>>
>>>> Yes, I do think we need to worry about it to the extent that we are not
>>>> creating something that is over-fit to a limited set of use cases.
>>>>
>>>> GNAP should be a foundation that many amazing new things can be built
>>>> on top of.
>>>>
>>>>  — Justin
>>>>
>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>
>>>> Justin, thanks for clarifying.
>>>>
>>>> What are some examples of other "direct data" that the GS may return?
>>>> If it is not in core GNAP, do we need to worry about now? We can then give
>>>> the direct data from the GS that is not a claim, an appropriate name in
>>>> that document.
>>>>
>>>>
>>>>
>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer <jricher@mit.edu> wrote:
>>>>
>>>>> Dick: No, I think you’re misunderstanding what I’m saying. I agree
>>>>> that “claims” are about the user, in this context*. But the AS could return
>>>>> other data directly to the client that isn’t about the user. Those aren’t
>>>>> “claims” by the classical definition. Also since “claims” can come back
>>>>> from places other than directly, then we shouldn’t call everything that
>>>>> comes back a “claim”.
>>>>>
>>>>> I’m arguing that we keep “claims” to mean what it already means and
>>>>> come up with a new word to mean “things that come back directly from the
>>>>> AS”. These aren’t meant to replace Francis’s more complete definitions, but
>>>>> to simplify:
>>>>>
>>>>> Claims:
>>>>> - information about the user
>>>>> - can come back directly from the AS
>>>>> - can come back in a resource from the RS
>>>>>
>>>>> Resource:
>>>>> - Returned from an RS
>>>>> - Protected by access token
>>>>> - Could contain claims about the user
>>>>>
>>>>> Direct data (or some better name):
>>>>> - Returned directly from AS
>>>>> - Could contain claims about the user
>>>>>
>>>>> I think the problem is that some people are using “claims” to mean #1
>>>>> and some to mean #3. It’s clearly #1 in OIDC. But: It’s important to
>>>>> remember, when talking about OIDC, that an IdP in OIDC combines an AS and
>>>>> an RS into one entity for identity information. There can be other RS’s as
>>>>> well, and there usually are in the wild, but the one defined by OIDC is the
>>>>> UserInfo Endpoint. The fact that it returns user data doesn’t make it any
>>>>> less of an RS.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> * In the wider context of things like the information claims inside a
>>>>> JWT, the claims could be about literally anything, but that’s not what
>>>>> we’re discussing here and it’s not how it’s being used.
>>>>>
>>>>>
>>>>> On Jul 24, 2020, at 1:24 PM, 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>