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

[Dick Hardt <[e-mail]>]

Hi Francis

User is a well understood term in OIDC and OAuth -- and User means the same
in both.

Resource Owner is who owns the resource, and the term is introduced for
when the User is NOT the Resource Owner.

I also think that Client and Resource Server are well understood terms.

It is not clear to me why we would want to reinvent these terms. Reading
over your flows, I think it would be useful to understand the requirements
you have for your use case, otherwise I fear we will be talking past each
other.

/Dick

ᐧ

On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha <[e-mail]> wrote:

> Below my opinion on the term Claim:
>
> Starting with illustration of parties/roles:
>
> User:
> This word is misleading because of its double role in oAuth2 and OIDC (see
> below). In GNAP let us have the User play only the role of a requestor.
> (from Justin reference to "Requesting Party").
>
> Client:
> This is also tightly bound to the oAuth2 and OIDC. The real purpose of
> this role is to orchestrate resource access on behalf of the "Requestor".
> Let us call this for now the "Orchestrator"
>
> Resource Owner (RO):
> This is IMO the most correct word in the entire protocol. Authorisation is
> always about the owner of something granting access to a requestor. It
> really does not matter if a human interaction is involved. We will have to
> forget oAuth2 and OIDC of also calling this a User.
>
> Grant Server:
> Even though the definition of the UserInfo endpoint in OIDC as a protected
> resource hazardously makes an OP an RS, we shall not repeat the same
> mistake here. We need a clear separation between roles of GS and RS without
> overlapping.
>
> Resource Server: services resources.
>
> Unless I got it wrong, GNAP is about grant negotiation and authorization.
> This means:
>
> GNAP is about some party requesting access to some resources.
> GNAP is about the resource owner consenting access to that resource.
> GNAP is about defining the infrastructure that allows the requesting party
> to access a resource.
>
> GNAP designs this infrastructure around:
> - an orchestrator (what we refer to as a client)
> - an grant manager (what we refer to as a GS/AS)
> - the custodian of the resource (what we call a RS)
>
> As you see:
> - The word User does not appear here, and is not relevant as the focus is
> on authorizing access to a resource.
> - The word Claim is as well absent.
>
> Claim related to RO:
> The word Claim might start getting visible if the orchestrator (a.k.a.
> Client) or the custodian (a.k.a RS) needs some additional information on
> the RO to proceed with the access control decision. These claims refer to
> assertions of attributes or properties of the RO. These claims are issued
> by the GS as the GS manages interaction with the RO (see below). In this
> first place information about the requesting party (erroneously.k.a.
> User) is not relevant to the negotiation and provisioning framework. Let us
> call this sort of claim "RO-Attributes". A better name is welcome.
>
> Some advanced resource provisioning frameworks might require knowledge on
> attributes of the requesting party (e.k.a User). These attributes shall be
> collected by the orchestrator (a.k.a Client) and added to the resource
> request. There is no way the GS can collect these attributes as the GS role
> has no interaction with the requesting party (e.k.a User). Let us call this
> sort of claim "Requestor-Attributes". A better name will be welcome.
>
> Some assertions are even related to the orchestrator (a.k.a Client)
> itself. This is the case of the public key of an orchestrator used by the
> GS to "sender constrain" an access token. Let us call this type of claim
> "Orchestrator-Attributes".
>
> This is a sample mapping of OIDC.
>
> +----+    +---+   +---+  +---+
> |User|    |RP |   |OP |  |RS |
> +----+    +---+   +-+-+  +---+
>   |(1) ServiceRequest      |
>   |-------->|       |      |
>   |(2) redirect     |      |
>   |<--------|       |      |
> === User (requestor) passes control to User (RO) ===
>   |(3) Auth + Consent      |
>   |---------------->|      |
>   |(4) redirect (code)     |
>   |<----------------|      |
> === User (RO) passes control back to User (requestor) ===
>   |(5) get(code)    |      |
>   |-------->|       |      |
>   |         |(6) token (code)
>   |         |------>|      |
>   |         |(7) token     |
>   |         |<------|      |
>   |         |(8) ServiceRequest(token)
>   |         |------------->|
>   |         |(9) ServiceResponse
>   |         |<-------------|
>   |(10) ServiceResponse    |
>   |<--------|       |      |
>   +         +       +      +
>
> - RP orchestrates interaction between User and OP to enable the user to
> obtain the protected resource.
> - In step 1 & 10 User plays the role of the requestor of the resource.
> - In step 2 User-Browser is used to pass control from User (in his role as
> the requestor) to User (in his role as the RO)
> - In step 4 User-Browser is used to pass control from User (in his role as
> the RO) back to User (in his role as the requestor)
>
> When we are talking claims here, we are talking claims on the User (in his
> role as the RO). The OP does not have any interaction with the User (in his
> role as the requestor). In the case of an App2App redirection, the OP can
> not even assert about the user agent of the User (requestor).
>
> If there is any claim the OP can provide, it is a claim on the User (RO).
>
> I hope this example clarifies the misunderstanding. Any attempt of
> bringing this double role of the User into GNAP will also bring this
> confusion. In order to keep this out of GNAP let us look for the right term
> for User (as a requestor) using the diagram displayed below.
>
> +----+  +------+  +---+  +---+  +---+
> |Reqs|  |Orchst|  |RS |  |GS |  |RO |
> +----+  +------+  +---+  +-+-+  +-+-+
>   |(1) ServiceRequest      |      |
>   |-------->|       |      |      |
>   |         |(2) ServiceIntent:AuthZChallenge
>   |         |<----->|      |      |
>   |         |       |      |      |
>   |         |(3) AuthZRequest(AuthZChallenge)
>   |         |------------->|      |
>   |         |       |      |(4) ConsentRequest:Grant
>   |         |       |      |<---->|
>   |         |(5) GrantAccess(AuthZ)
>   |         |<-------------|      |
>   |         |       |      |      |
>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>   |         |<----->|      |      |
>   |(7) ServiceResponse     |      |
>   |<--------|       |      |      |
>   +         +       +      +      +
>
> - Replacing the word User helps clarify the difference between both roles
> "Requestor" and "Resource Owner"
> - Renaming claim by attaching the Object/target of the claim (e.g.:
> RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also helps
> identify the source of those attributes (GS, RS, Client):
>
> Best regards.
> /Francis
>
> On Fri, Jul 24, 2020 at 4:58 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>