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

[Francis Pouatcha <[e-mail]>]

Hello Dick,

On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt <[e-mail]> wrote:

> 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.
>
This distinction is what makes it confusing as we are comparing an Entity
(the User) to a Role (the RO). We need two roles.


>
> I also think that Client and Resource Server are well understood terms.
>
Looks like contributors on the list still need clarification on the
"orchestration" role of a client.

>
> 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.
>
The oAuth flow is there as a memo. The other flow is what I proposed
before. Is there to emphasize we need to work on roles and not on entities.
It is not a suggestion to rename well known idioms. It is an attempt to
give them a proper definition in the context of this protocol. Definition
based on their roles in the protocol flows.

Best regards.
/Francis

>
> /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/
>>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/