Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary

[Dick Hardt <[e-mail]>]

Hi Francis

It appears we have two areas to provide additional clarity:

1) In OIDC, the UserInfo endpoint is NOT part of the OP. It is a Protected
Resource. Per
https://openid.net/specs/openid-connect-core-1_0.html#Terminology

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.


Therefore a RS is providing Claims in OIDC. (RS is the same as a Protected
Resource)

2) The RO may be the User, or it may be some other entity. For example, the
Client may want access to a Resource owned/controlled by an enterprise. The
RO is not the User, and there may not be a User using the Client.

See the Independent RO Authorization sequence as an example:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-13#section-2.3

Note there is no User in this sequence


more detailed comments inserted ...


On Fri, Jul 24, 2020 at 5:15 AM Francis Pouatcha <[e-mail]> wrote:

>
>
> On Thu, Jul 23, 2020 at 10:44 PM Dick Hardt <[e-mail]> wrote:
>
>>
>>
>> On Thu, Jul 23, 2020 at 7:16 PM Francis Pouatcha <[e-mail]> wrote:
>>
>>> Hello Dick, my feedback inline
>>>
>>> @Fabian : i am not yet consistent with using the notation you
>>> referred to in
>>> https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en. Still to
>>> come.
>>>
>>> On Thu, Jul 23, 2020 at 7:52 PM Dick Hardt <[e-mail]> wrote:
>>>
>>>> Hi Francis
>>>>
>>>> Thanks again for putting this together. I have taken your definitions
>>>> and adjusted them to match how I think of them. I dropped the term
>>>> "parties" because I did not think it added value. I am explicit about what
>>>> each party is -- software, a human, or an entity. Let me know where you
>>>> disagree!
>>>>
>>>>
>>>> Resource - protected data or software functionality
>>>>       - controlled by a Resource Owner (RO),
>>>>       - protected by the Resource Server (RS)
>>>>
>>> Yes
>>>
>>>>
>>>> Claim - a statement about the User
>>>>
>>> I would stay with RO not User. I added some clarification after the
>>> feedback of Justin (see below)
>>>
>>
>>
>>
>>
>>>       - may be obtained from the Grant Server (GS) by a Client
>>>>
>>> Yes.
>>>
>>>>       - may be a Resource the Client can access through an RS
>>>>
>>> Not sure we need to refer to a Resource as a Claim.
>>>
>>
>> Here is why I say a Claim may be a Resource.
>>
>> A Claim may be obtained by a Client calling an RS. This is effectively
>> what the userinfo endpoint is in OpenID Connect. A Client may also update a
>> Claim that is managed by an RS.
>>
> In OIDC the UserInfo endpoint is exposed by the OP not by an RP. Spec
> wording is confusing because the endpoint is referred to as a protected
> resource. If you derive from this that the OP is a resource server (RP),
> you turn the OP into an RP relying on itself. This cyclic relationship has
> to be broken in GNAP for simplicity.
>

(I'm assuming you intended RS, not RP above)

See above per the UserInfo endpoint being a Protected Resource, and is not
the OP.


>
> Note-x on GS definition: having a GS protecting access to some Claims does
> not make the GS a RS.
>
> For simplicity, let us keep overlapping out:
> - GS guards Claims
> - RS guards Resources
>
> I do not see a Client updating a Claim in the scope of any of these
> protocols. Neither GNAP nor oAuth2 nor OIDC.
>

I agree that how a Client updates a Claim is out of scope (at least in the
core protocol).



>
>>
>>>
>>> A Claim - an assertion of the truth of some properties or attributes of
>>> the RO.
>>>   Note-1: A Claim is issued either by the GS or by another claim issuer.
>>>
>>
>>
>> I'm viewing the Claims Issuer as an entity, not a piece of software. It
>> is the entity trusted by other parties to make a Claim about the User. The
>> GS and RS may issue claims on behalf of the Claims Issuer.
>>
> No. Issuer is GS. Any twiking of the word will diverge it from oAuth2 and
> OIDC and increase complexity.
>

The Issuer is an entity. The GS is software.


>
> This is why RS shall not issue anything, shall not deal with claims, ....
> RS guards Resources. If you start dealing with RS issuing claims, you start
> dealing with RS exposing jwks-url so issued claims can be verified, then
> you fall back at having those RSes being GSes.
>

I'm saying a Resource *may* be a Claim, just as it is in OIDC UserInfo.



>
>>
>>
>>>   Note-2: A Claim is held and guarded by the Grant Server (GS).
>>>
>>
>> What is the significance of this statement? Signed claims don't exist
>> until asked for, so they are not "held" anywhere.
>>
> A Claim can exist before. GS might hold a Claim issued by an external
> "Claim Issued".
>

Would you provide an example?


>
>>
>>>   Note-3: A Claim is released by the GS to a Client.
>>>
>>
>> The model of a Claim being obtained from an RS is a common use case.
>>
> I am not aware of any of them. Unless we are calling a GS a RS.
>

See UserInfo above. Also, the APIs at Twitter, Facebook, Google etc. are
RSes, that may return Claims about the User.


>
>>
>>>   Note-4: The permission to release of a Claim is given by the RO.
>>>
>>
>> I will see what you say below on User ...
>>
>>
>>>
>>>
>>>> Grant - the Claims and/or Resource Access the User and/or RO have
>>>> granted to the Client by the GS
>>>>     - requested by a Client
>>>>     - granted by a GS after any required consent has been obtained from
>>>> the User and/or RO
>>>>
>>> "User and/or RO" is confusing. I suggest we keep the term User out. Term
>>> User is even eligible for renaming. I suggest staying with RO.
>>>
>>
>> The User of the Client and the RO may not be the same entity. Some
>> resources may be controlled by the RO, and others by the User. That is why
>> User and/or RO. They are two different parties.
>>
> I need the example of a User that is different from the RO and that
> controls the RO's Resource.
>

See above.


>
> And if a User controls a Resource, then he does it as the "Owner" of that
> Resource(playing the role of the RO for that Resource).
>
> If we talk about roles and not entities, we will not fall into this
> confusion.
>

I think we are defining an entity playing a specific role.


>
>>
>>>
>>>
>>>> Access Token - an artifact representing the access a client has been
>>>> granted to one or more Resources
>>>>     - created by the GS
>>>>     - presented by the Client when accessing a Resource at an RS
>>>>
>>> An access token might contain Claims.
>>>
>>
>> While there may be statements about the User in the access token, it is
>> not the mechanism for transmitting Claims to the Client -- and I think the
>> access token SHOULD be opaque to the Client most of the time.
>>
> - Access "might" contain a claim ("must" not). Precision is essential as
> we can not kill this practice without removing the concept of assertion
> based tokens.
> - Returning the information to the client does not mean the client is the
> consumer of the information. The client might not have access to the
> content of an encrypted token, or even just to the embedded encrypted
> claim. The intended destination of the claim will consume the claim. But
> for the GNAP, the GS returns the token to the client.
>

Let me restate my position. Any claim that might be in the access token is
out of scope of GNAP, or at least the core protocol. How the RS uses the
access token to protect access is out of scope, so the contents of the
access token is out of scope.



>
>>
>>>
>>> Access Token - an artifact representing the access a client has been
>>> granted to one or more Resources
>>>   Note-1: An access token is created by the GS
>>>   Note-2: An access token can also contain claims
>>>
>>
>> See above.
>>
>>
>>>   Note-3: An access token is presented by the Client when accessing a
>>> Resource at an RS
>>>
>>>
>>>> Resource Owner (RO) - the entity that
>>>>       - controls a Resource,
>>>>       - has delegated Resource access control to one or more GSes
>>>>       - may be the User
>>>>
>>> Confused here with the word "controls" both at RO and GS. I think RO
>>> delegates Resource access management to GS but keeps control (or decision).
>>>
>>
>> agreed - access management is better.
>>
>>
>>>
>>> Resource Owner (RO) - the entity that
>>>       - controls a Resource,
>>>       - relies on the services the GS to manage access to that Resource,
>>>       - relies on the services of a RS to hold a Resource and guard
>>> access to that Resource,
>>>
>>
>> I don't think "guard" is a good verb. "protect" is often used.
>>
> OK.
>
>>
>> If we are switching from "owns a resource" to "controls a resource", then
>> perhaps the entity should be a Resource Controller (RC)?
>>
> Great. Will remove confusion.
>
>>
>>
>>
>>>       - controls a Claim,
>>>
>>
>> Why does the RO control a claim?
>>
> because a Claim is an assertion of the truth of some properties or
> attributes of the RO.
>

The RO may or may not be a User. If the RO is not a User, who is the claim
about? What does "control" mean?



>
>>
>>>       - relies on the services the GS to release that Claim to a Client.
>>>
>>>>
>>>> Resource Server (RS) - the software that controls access to one or more
>>>> Resources
>>>>       - accessed via an API by Clients presenting an access token
>>>>       - accepts access tokens from one or more GSes
>>>>
>>> I suggest "guards" instead of "controls". As access to a resource is
>>> controlled by the RO.
>>>
>>
>> How about "protects access"?
>>
> OK for me.
>
>>
>>
>>>
>>> Resource Server (RS) - the software that guards access to one or more
>>> Resources
>>>       - accessed by the Client that presents an access token
>>>       - accepts access tokens from one or more GSes
>>>
>>>
>>>>
>>>> Grant Server (GS) - the software that manages Grants
>>>>     - has been delegated to manage Resource access by the RO
>>>>     - has been delegated to release Claims about the User
>>>>     - grants the Client access to Resources after obtaining the
>>>> required consent from the RO
>>>>     - provides the Client Claims about the User after obtaining the
>>>> required consent from the User
>>>>
>>> Term User is confusing here. This is why it is eligible for renaming.
>>> - Claims are about RO not User
>>> - Consent is from RO not User.
>>>
>>
>> I'm confused why the Claims are about the RO and not the User.
>>
> Because the  user consumes the resource and the claim. I do like Justin's
> suggestion to call user the "Requesting Party"
>

The Client consumes the Resource and the Claims

The Requesting Party sounds more like the Client than the User.


>
>> We have introduced the term RO so that entity can be differentiated from
>> a User, and there are many use cases where there is a User. Not having a
>> User seems very confusing to me.
>>
> Then let us call him a  "Requesting Party"
>
>>
>>
>>>
>>> Grant Server (GS) - the software that manages Grants
>>>     - has been delegated to manage Resource access by the RO
>>>     - has been delegated to release Claims about the RO
>>>     - grants the Client access to Resources after obtaining the required
>>> consent from the RO
>>>     - provides the Client Claims about the RO after obtaining the
>>> required consent from the RO
>>>
>>>
>>>> Client - the software that wants to access Resources and obtain Claims
>>>>     - executed by a User or a non-human service account
>>>>     - requests Grants from the Grant Server
>>>>     - accesses Resources at an RS using access tokens
>>>>
>>> Client - the software that wants to access Resources and obtain Claims
>>> on behalf of a User or non-human service account
>>>    Note-1: in a typical interaction cycle, the client:
>>>       - receives the resource access request from the User or acts
>>> autonomously,
>>>       - interacts with the RS to discover authorization requirements,
>>>       - interacts with the GS to obtain Access Tokens,
>>>       - interacts with the RS to access the Resource using Access Tokens.
>>>
>>
>> The Client also transfers the user experience to the GS in some flows.
>>
> Yes but this is just a mechanism. Not an act.
>
>>
>> Where do Claims fit into the cycle above?
>>
> A claim is just an Assertion (attribute, property) related to the RO. This
> can be part of the authorization requirements. e.g. User/Client/RS are
> requesting to know the e-mail of the RO.
>

I still view Claims are about the User. The RO is who controls a Resource,
since it is the *Resource* Owner.

/Dick

> ᐧ