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

[Dick Hardt <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>>>
>>>>
>>>>
>>>
>>
>