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

Dick Hardt <> Mon, 27 July 2020 13:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A21B3A18B5 for <>; Mon, 27 Jul 2020 06:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X7yIk8oz7bEo for <>; Mon, 27 Jul 2020 06:46:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 371053A0E69 for <>; Mon, 27 Jul 2020 06:46:34 -0700 (PDT)
Received: by with SMTP id b30so9013901lfj.12 for <>; Mon, 27 Jul 2020 06:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nru+EYUiebr7yDetxA968+SED1XNSKLwgJNXZ9A5Kt4=; b=GWMC2rSAVjcrXwbSbchQjXoQCqaoCSUIuh0dezS3JYhYukDbEzTphje67ynxUFZ6kE vIEgI5Jc4F3F1YWUts3+AhTQRAkf4xByUyjWun6vz98lnELKQZi2N+jqzXIhVAAJ/P/y 3mJCwNOonlABTk5sweziLW1z3dE0I0qbaTn7nfvOwC90zpEy8NKPCjs8qPvoPhbqQxNs 3GnwQ8I2XDGGOqRFJNGcOUQ7b9/b2sIhPdOna2CAmD2wUAzkea91gDbkZj0FriPRVKZZ DYy18bYryPLso1xFb1d8hmCWxpmrEq0foeyMaQo9izNKvHeXyDSte1xi3AEaAVpJrBjY CKug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nru+EYUiebr7yDetxA968+SED1XNSKLwgJNXZ9A5Kt4=; b=WSlZYZIFq7Idp0cjRU5JfhIhb+DWk7jkM+GU252zr4LECAy3QMwk5a6T5HZHtJ127o ELP28emV5o6gJh4YozwPhaLlvU/JrIeoZTTcXwcx0HEo0h55j8yMuo0YQbp8YBts3Roo oitJkSE7d50iKjb3CyKkk7mxddzRdzDG4jAWbYjlck0WbkVbXIM0aUaTRqXohi5HufnE 2ggePYchDdunFfJn98j1NUKHCYj/sQXKRjKnYNt37OXqiAXgGStCVcdu0LGZiBj4GOpn /uVuwt2yPpOsNIctFo2A71RXKpAN/GM5fGz9sX25OgZnyu/9Fb7sKOrR1ix/gqzZzSz/ 0CZg==
X-Gm-Message-State: AOAM531o2aZ8sKIjHxjdBp2dqd29xSUb6HCmRfGxGyS1IgOGTnWH3tH6 VnJ+uM6y+KpYxm38PLTf5KCTCWyq9gjF/wuGB8Y=
X-Google-Smtp-Source: ABdhPJy9bnjxUqmypSr8IW+KNND7OEste2dimy4Ct1BM33cq+Bj915TK2UfnNpQEe2ALSO3YhMMCNhNJijx4+UAQ/to=
X-Received: by 2002:a19:fc14:: with SMTP id a20mr11887318lfi.0.1595857592073; Mon, 27 Jul 2020 06:46:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Mon, 27 Jul 2020 06:45:55 -0700
Message-ID: <>
To: Justin Richer <>
Cc: Francis Pouatcha <>,, Tom Jones <>, Denis <>
Content-Type: multipart/alternative; boundary="000000000000e340fd05ab6c8c40"
Archived-At: <>
Subject: Re: [Txauth] Claims [was: - Dictionary]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2020 13:46:41 -0000

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 <> 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 <> 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 <> 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]
>> On Jul 24, 2020, at 3:58 PM, Dick Hardt <> 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 <> 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 <> 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 <> 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 <> 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 <> 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