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

[Francis Pouatcha <[e-mail]>]

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/