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

[Dick Hardt <[e-mail]>]

What is Requester or Requesting Party replacing? User?

Is a Role software?

On Mon, Jul 27, 2020 at 5:14 AM Justin Richer <[e-mail]> wrote:

> I agree with the separation between “roles” and “entities”. It’s exactly
> that kind of separation into roles that helped OAuth 2 succeed with the AS
> and RS roles possibly being the same entity, or not, depending on use case.
>
> This is one of the reasons that I think “user” is an overloaded term. The
> user is an entity, not a role, and in spite of it being “understood” in the
> OAuth 2 world, it means a wide variety of other things outside that world.
> The same with “client”, I can’t tell you how many times I’ve had to explain
> what exactly an OAuth “client” is when I’m teaching a class.
>
> As for specific recommendations: I’m in favor of the role “Requester” or
> “Requesting Party”. “Client” is arguably more confusing and harder to
> replace: I had tried to use “Resource Client” to make “client” more
> specific in XYZ but that turned out to be more confusing than helpful.
>
>  — Justin
>
> On Jul 27, 2020, at 6:12 AM, Francis Pouatcha <[e-mail]> wrote:
>
>
>
> On Sun, Jul 26, 2020 at 11:58 PM Dick Hardt <[e-mail]> wrote:
>
>>
>>
>> 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.
>>
> When we think of them as entities, we run into conflicts when Entity-User
> eq. Entity-RO.
> When we think of them as roles, Role-User is always != Role-RO
>
>>
>>
>>>
>>>
>>>>
>>>> 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?
>>
> Look at the client. It is the center of interaction between User, GS and
> RS.
>
>>
>>
>>>
>>>> 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.
>>
> No, we are at the fundamental level. We Have to decide on whether to build
> a model based on roles oron entities... Then we use the result [ENTITY XOR
> ROLES] to define the use cases.
> /Francis
>
>>
>>
>>>
>>> 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/
>>>
>>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>
>
>