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

[Dick Hardt <[e-mail]>]

On Sun, Jul 26, 2020 at 6:45 PM Francis Pouatcha <[e-mail]> wrote:

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

Or we could think of them all as entities. The RO is the entity that owns
the resource. The User is the human that is using the Client.


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

When I think of orchestration, I think of coordinating, which is not what I
think the Client is doing. The Client wants to consume the Claims and the
Resources (combined are a Grant). The Client requests the Grant from the
Grant Server. Where is the orchestration?


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

I'd like to take a step back and understand the requirements. We are deep
into solutions.


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