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

From: Francis Pouatcha <[email-masked]>
Date: Mon, 20 Jul 2020 21:01:07 -0400

Hello Dick,

Here is (in a new thread) the promised attempt to define terms of interest
in the GNAP protocol.

Party - represents a role in the GNAP protocol flow. A party can take the
form of a web service, an application installed on the user device and
acting autonomously or the form of a natural person (resp. of an autonomous
device) using an application to interact with other parties.

Resource - a piece of data or web service
      - controlled by a Resource Owner (RO),
      - held and guarded by a Resource Server (RS) and
      - serviced by the RS to a Client, if the Client provides a valid
Authorization.

Resource Owner (RO) - the party that
      - owns a Resource,
      - relies on the services the GS to manage access to that Resource and
      - relies on the services of a RS to hold the Resource and guard
access to that Resource.

Resource Server (RS) - the party that
      - holds a resource and guards access to that resource on behalf of
the RO,
      - services the Resource to the requesting Client, provided the Client
presents a valid Authorization.
      The RS is generally deployed as a web service.

Grant Server (GS) - the party that manages access to a Resource on behalf
of the RO. For each Resource access request, the GS might request the
consent of the RO and produce a corresponding Authorization that is given
to the requesting Client.

Consent - act of an RO approving the release of a Resource he owns to a
Client.

Grant - material form of an RO Consent. In order not to interact with the
RO on each Resource access request, the GS might store the RO Consent in
the form of a Grant for reuse.

Authorization - externalized form of a Grant as known to the GS and the RS.
      - The GS converts a Grant into an Authorization for use in a Resource
access request.
      - The RS evaluates an Authorization to decide on whether or not to
release the Resource to the Client.

Client - the party that provides the infrastructure used by a User to
access a Resource. The client infrastructure is designed to:
      - Receive the resource access request from the User,
      - Interact with the RS to discover authorization requirements,
      - Interact with the GS to obtain an Authorization to access the
Resource,
      - Interact with the RS to access the Resource on behalf of the User.

User - the party using the infrastructure of the Client to gain access to a
Resource.

This dictionary is supposed to be the base for further discussions that
will allow us to provide each term with just enough description to reduce
ambiguities and misunderstandings in further exchanges. I intentionally
omitted the specification of the type and nature of each party (For example
Client / Registered Client / Dynamic Client). Such elaborations belong IMO
in proper subsections.

Comments are welcome.

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

---

From: Tom Jones <[email-masked]>
Date: Mon, 20 Jul 2020 19:30:35 -0700

that sounds like a good start - some points.
1. Many of the statements, like the RO owns the data, are technically or
legally incorrect, but i think we know what you mean. - controls access
might be more appropo.
2. the user may be a delegate of the RO and have some sort of token that
proves his authority. It would be interesting to know if that token is in
scope.  If not perhaps I can find someone else to own it.
Peace ..tom

On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha <fpo=
[email-masked]> wrote:

>       - services the Resource to the requesting Client, provided the
> Client presents a valid Authorization.
>       - The GS converts a Grant into an Authorization for use in a
> Resource access request.
> User - the party using the infrastructure of the Client to gain access to
> a Resource.
>
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 21 Jul 2020 08:59:55 -0700

Thanks for putting this together Francis. I like how you have put different
aspects of a definition into separate points. It reinforces the multiple
aspects.

I don't see identity claims in your definitions. Was that intentional, or
an oversight.

wrt. Registered Client / Dynamic Client - in my experience putting the
definitions together helps a reader grasp all the various terms used.

Curious why you include "party" in the definition. I would not have thought
that had a definition unique to GNAP.

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 21 Jul 2020 13:28:20 -0400

> legally incorrect, but i think we know what you mean. - controls access
OK.

> scope.  If not perhaps I can find someone else to own it.
Talking Grant Negotiation, the happy path assumes that the User/Client is
not in possession of an AuthZ.

- If a Client is in possession of an AuthZ he assumes valid, he can
directly proceed with step (6) ServiceRequest(AuthZ)
- If the client does not the authorization requirement, we could allow the
request in "step (1) ServiceIntent" to present an existing AuthZ to the RS.
If RS judges this AuthZ to be sufficient, the returned AuthZChallenge can
contain an Exemption from further Authorization, instructing the Client to
proceed with "step (6) ServiceRequest(AuthZ)".

Peace ..tom
> [email-masked]..org <[email-masked]>> wrote:
>
>> Hello Dick,
>>
>> Here is (in a new thread) the promised attempt to define terms of
>> interest in the GNAP protocol.
>>
>> ambiguities and misunderstandings in further exchanges.. I intentionally

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 21 Jul 2020 13:42:32 -0400

On Tue, Jul 21, 2020 at 12:00 PM Dick Hardt <[email-masked]> wrote:

> Thanks for putting this together Francis. I like how you have put
> different aspects of a definition into separate points. It reinforces the
> multiple aspects.
>
The extensive dictionary will surely include more terms.

I limited the list to terms relevant to the abstract sequence for now.
Making an effort to keep the discussion focused on the abstract sequence.

As we are talking authorization, identities are second class citizens,
focus shall be on Negotiating and Obtaining the AuthZ to access a Resource.

> definitions together helps a reader grasp all the various terms used.
Yes, this clarification belongs in the dictionary. Intentionally left it
out here to avoid diverging the discussion.

>
> Curious why you include "party" in the definition. I would not have
> thought that had a definition unique to GNAP.
>
I derived this from your subsection "Parties". As all participants in the
abstract sequence are "parties", the word seems too heavy to be left
undefined. Also essential to know which words in the dictionary do not
refer to parties like Resource, Grant, AuthZ, ...

---

From: Dick Hardt <[email-masked]>
Date: Tue, 21 Jul 2020 10:58:26 -0700

FYI: I consider the release of claims to be an "authorization" as well.

IE, the user authorizes the GS to release a DOB claim to a Client.

On Tue, Jul 21, 2020 at 10:42 AM Francis Pouatcha <[email-masked]> wrote:

>>> Party - represents a role in the GNAP protocol flow. A party can take
>>> the form of a web service, an application installed on the user device and
>>> Grant Server (GS) - the party that manages access to a Resource on
>>> behalf of the RO. For each Resource access request, the GS might request
>>> the consent of the RO and produce a corresponding Authorization that is
>>> given to the requesting Client.
>>>
>>> Grant - material form of an RO Consent. In order not to interact with
>>> the RO on each Resource access request, the GS might store the RO Consent
>>> in the form of a Grant for reuse.
>>>
>>> User - the party using the infrastructure of the Client to gain access
>>> to a Resource.
>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 21 Jul 2020 14:09:10 -0400

> FYI: I consider the release of claims to be an "authorization" as well.
Great. Then it is included.

> IE, the user authorizes the GS to release a DOB claim to a Client.
I guess you mean the "RO" authorizes the GS to release a DOB!

>>> I don't see identity claims in your definitions. Was that intentional,
>>> or an oversight.
>>>
>>>>       - holds a resource and guards access to that resource on behalf
>>>> of the RO,
>>>>       - The RS evaluates an Authorization to decide on whether or not
>>>> to release the Resource to the Client.
>>>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 21 Jul 2020 11:15:05 -0700

> Great. Then it is included.

I pivoted to using the term Grant rather than authorization so that it
included both authorizing access to a resource, and authorizing the release
of an identity claim.

Perhaps we should not use the word "authorization"?

"resource access" and "claim release"

A Grant then covers both?

> I guess you mean the "RO" authorizes the GS to release a DOB!

Yes, thanks for clarifying!

/Dick

---

From: Tom Jones <[email-masked]>
Date: Tue, 21 Jul 2020 11:22:06 -0700

Peace ..tom

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 21 Jul 2020 14:27:10 -0400

> Perhaps we should not use the word "authorization"?
Authorization is currently used to refer to the token issued by the GSand
presented to the RS by the Client. I have no alternative word for now.

> A Grant then covers both?
Yes, Great! The word Grant fits best for both. I suggest adding this
clarification to that dictionary.

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 21 Jul 2020 20:33:27 -0400

Hello Dick, Justin, Tom, Denis,

Below is a new version of the dictionary includings comments from
different threads. Change log includes:
- avoided the expression "owns a resource" in favor of the expression
"controls a resource"
- included the clarification "resource access" and "claim release"
- included a clarification User vs. RO
- tried to clarify the word User-Agent
- added the definition of a Claim

Terms
=====

Claim - a piece of data
      - controlled by a Resource Owner (RO),
      - held and guarded by the Grant Server (GS) and
      - released by the GS to a Client as part of an Authorization.

Resource Owner (RO) - the party 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 the Resource and guard
access to that Resource,
      - controls a Claim,
      - relies on the services the GS to release that Claim to a Client.

Grant Server (GS) - the party that
      - manages access to a Resource on behalf of the RO,
      - holds Claims and releases them when consented by the RO.
      For each Resource access request, the GS might request the Consent of
the RO and produce a corresponding Authorization that is given to the
requesting Client.

Consent - act of an RO :
      - approving access to a Resource, means approval that a Resource he
controls can be given to the Client by the RS.
      - approving release of a Claim, means approval that a Claim he
controls can be included by the GS in an Authorization to be returned to
the Client.

Resource or a Claim.

Clarifications:
==========

User vs. RO :
      - the User is the party using the infrastructure of the Client to
gain access to a Resource or a Claim,
      - the RO is the party controlling access to a Resource or controlling
the release of a Claim.
In many use cases, User and RO will be represented by the same party (see
oAuth2), but GNAP exposes use cases where User and RO are represented by
different parties.

User-Agent :
User and RO are parties that might be represented by a natural person or an
autonomous device. In those cases, User (resp. RO) might need the help of
an application to interact with other parties. Such an application is
generally referred to as the "User-Agent".

Feedbacks are welcome.

Best regards,
/Francis

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 22 Jul 2020 10:25:46 +0200

Hi all,

Thanks for that work.
It would make things easier if we could group the definitions which can be
generic (without any knowledge of the GNAP architecture) from the terms
which are dependent on the protocol flow itself.

For terminology, the way it is done in ISO standards is quite interesting
and we probably could reuse some ideas. The general rule of thumb is to
reuse definitions when that's possible and re-define only when necessary.
See for instance
https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en
You'll find :
- a definition
- potentially some notes (here we can explain how it differs from an
already existing term used in a different context) and some examples
- related reference (in many cases, we don't even need to reinvent
something, as we just need to be consistent with terms already used in the
community)

Generic definitions :
- resource, claim, consent, grant, authorization -> seems to me these are
generic. Why does it matter in the definition that we know which party is
doing it?
- in most cases, those definitions shouldn't be different from other WGs,
or else we should explain why that is.
- party : if we refer to roles, we need to define that too.
- grant : I don't get what you mean by "material form of an RO consent".
What is material?

Specific definitions :
- User, User-Agent, Client, RO, GS : all these are specific to the way the
protocol is specified, so it does make sense to relate to the parties doing
it.
- But even then, we need to check whether that specificity is required. I'm
not sure I agree with your definition of User, though. In 99% of use cases,
a user is just... a user, i.e. a natural person. Why do we need to make
this definition so convoluted? The User-Agent definition seems enough to
convey the idea that interactions can be done through real users or things.

Cheers

Fabien

On Wed, Jul 22, 2020 at 2:33 AM Francis Pouatcha <fpo=
[email-masked]> wrote:

> acting autonomously or the form of a natural person (resp.. of an
> autonomous device) using an application to interact with other parties.
>
>       For each Resource access request, the GS might request the Consent
> of the RO and produce a corresponding Authorization that is given to the
> requesting Client.
>
> Consent - act of an RO :
> a Resource or a Claim.
>       - the RO is the party controlling access to a Resource or
> controlling the release of a Claim.
> User and RO are parties that might be represented by a natural person or
> an autonomous device. In those cases, User (resp. RO) might need the help
> of an application to interact with other parties. Such an application is

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 22 Jul 2020 17:12:33 -0400

Hello Fabian,

> something, as we just need to be consistent with terms already used in the
Good idea.

> generic. Why does it matter in the definition that we know which party is
Relationship to parties is essential for the understanding of the GNAP
protocol.

> - party : if we refer to roles, we need to define that too.
party is defined to help delimitate User, Client, RS, GS, RO from other
terms.

> - grant : I don't get what you mean by "material form of an RO consent".
I meant: a Grant is a [materialization/database representation/...] of an
RO consent. GS stores the RO Consent in the form of a Grant.

> protocol is specified, so it does make sense to relate to the parties doing
Ok.

> this definition so convoluted?
>
Term User is introduced by Dick (see:
https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-1.1). We
am trying to distance it from the RO. As this confusion leads to a lot of
misunderstandings in discussions in the group.

The User-Agent definition seems enough to convey the idea that interactions
> can be done through real users or things.
>
Not so sure. Precision helps reduce misunderstandings in discussions we are
conducting on GNAP.

Best regards.
/Francis

>> acting autonomously or the form of a natural person (resp... of an
>>> Authorization is currently used to refer to the token issued by the
>>> GSand presented to the RS by the Client. I have no alternative word for now.
>>>
>>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 23 Jul 2020 11:07:26 -0400

Up-front question to the Chairs, do we have a good place to capture this kind of thing? A non-spec document like this would be a good candidate for a wiki page. Do we have plans to set up a GitHub repository or similar? If so we could use the wiki capabilities there to at least get this stuff written down. Use cases would be good to capture there as well. 

Francis,

First, I want to thank you for putting the work in to getting some vocabulary down. This is not an easy task! Some notes on specific items inline below.

> On Jul 21, 2020, at 8:33 PM, Francis Pouatcha <[email-masked]> wrote:
> 
> Below is a new version of the dictionary includings comments from different threads. Change log includes:
> - avoided the expression "owns a resource" in favor of the expression "controls a resource"
> Party - represents a role in the GNAP protocol flow. A party can take the form of a web service, an application installed on the user device and acting autonomously or the form of a natural person (resp. of an autonomous device) using an application to interact with other parties.
> 
>       - serviced by the RS to a Client, if the Client provides a valid Authorization.
> 
> Claim - a piece of data

The differentiation between “resource” and “claim” is important since it separates items that get tied to an access token’s rights (“resources”) with items that come back directly to the client without going through a separate API. The term “claim” is problematic here though because it is used broadly in the community to mean, roughly, “a statement about the end user”. It’s therefore both too broad and too narrow in the wrong ways: a “claim” could come back as part of an API response, like the OIDC UserInfo Endpoint, and so it’s not a good name for this item. Even the OIDC “claims” query language defines several different targets for returning the “claims” about the user, and none of them match the method that GNAP is looking to use here. A “claim” is also generally understood in the identity community to be a statement about the user, and the data coming back directly to the client might be about the user or something else, especially as we look forward to extensions of GNAP. 

I think we should focus on the separation of the delivery mechanism, but I’m not sure what good alternatives would be. Perhaps:

 - “access right” for things tied to the API/token
 - “data response” for things coming back directly to the client

I’m not particularly thrilled by these names, but I think recent list conversation shows that we need to get away from “claim” as it’s overloaded.

>       - relies on the services of a RS to hold the Resource and guard access to that Resource,
>       - controls a Claim,
>       - holds a resource and guards access to that resource on behalf of the RO,
>       - services the Resource to the requesting Client, provided the Client presents a valid Authorization.
>       For each Resource access request, the GS might request the Consent of the RO and produce a corresponding Authorization that is given to the requesting Client.

I don’t like the shift from “Authorization Server” to “Grant Server”, and it especially doesn’t make sense in light of the definitions of “grant” and “authorization” above. I believe we should stick with “Authorization Server” if it’s a single role. I would also propose that we have a separate term for the RO-interactive portion vs. the client-facing portion, as has been brought up in a few threads. Maybe these get different names entirely, or maybe they are “aspects” of the AS, I’m not sure.

> 
> Consent - act of an RO :
>       - approving access to a Resource, means approval that a Resource he controls can be given to the Client by the RS.
>       - approving release of a Claim, means approval that a Claim he controls can be included by the GS in an Authorization to be returned to the Client.
> 
> Grant - material form of an RO Consent. In order not to interact with the RO on each Resource access request, the GS might store the RO Consent in the form of a Grant for reuse.
> 
>       - The GS converts a Grant into an Authorization for use in a Resource access request.
>       - The RS evaluates an Authorization to decide on whether or not to release the Resource to the Client.
> 
> Client - the party that provides the infrastructure used by a User to access a Resource. The client infrastructure is designed to:
>       - Interact with the GS to obtain an Authorization to access the Resource,

I think we should be clear that what we call the “client” is a piece of software operated by the user. It’s true that this software might have multiple parts of its “infrastructure” but it’s always software.

> 
> User - the party using the infrastructure of the Client to gain access to a Resource or a Claim.
> 

In UMA, we call this the “Requesting Party”, or RqP. We might want to consider adopting this terminology here as well.

> 
> Clarifications:
> ==========
> 
> User vs. RO : 
>       - the User is the party using the infrastructure of the Client to gain access to a Resource or a Claim,
>       - the RO is the party controlling access to a Resource or controlling the release of a Claim.
> In many use cases, User and RO will be represented by the same party (see oAuth2), but GNAP exposes use cases where User and RO are represented by different parties.
> 
> User-Agent :
> User and RO are parties that might be represented by a natural person or an autonomous device. In those cases, User (resp. RO) might need the help of an application to interact with other parties. Such an application is generally referred to as the "User-Agent".

The term “user agent” is often used to be equivalent to the web browser, and not the more general use here. I think we’re seeing more “agent” terminology for helper applications like digital wallets and AI bots, which would seem to be covered under your definition here.

> Feedbacks are welcome.

Again, thanks so much for getting this going!

 — Justin

> Best regards,
> /Francis
> 
> 
> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> I pivoted to using the term Grant rather than authorization so that it included both authorizing access to a resource, and authorizing the release of an identity claim.
> 
> Authorization is currently used to refer to the token issued by the GSand presented to the RS by the Client. I have no alternative word for now.
> 
> Yes, Great! The word Grant fits best for both. I suggest adding this clarification to that dictionary.
> 
>  
> 
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>
> 
> -- 
> Francis Pouatcha
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 23 Jul 2020 16:52:15 -0700

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)

Claim - a statement about the User
      - may be obtained from the Grant Server (GS) by a Client
      - may be a Resource the Client can access through an RS

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

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

Resource Owner (RO) - the entity that
      - controls a Resource,
      - has delegated Resource access control to one or more GSes
      - may be the User

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

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

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

User - the human using a Client
    - may also be the RO for one or more Resources
    - may have Claims managed at a GS

Some comments:

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 think Grant Server is the right term. A Grant contains claims and/or
access to resources. I have defined all the terms above without using the
term authorization. :) -- I am pondering renaming most things called
Authorization in XAuth to Access.

Claim Issuer - I think we may need to add this party to our nomenclature.
This is the entity that issues Claims. It may be a GS or an RS.

/Dick

ᐧ

On Thu, Jul 23, 2020 at 8:07 AM Justin Richer <[email-masked]> wrote:

> Up-front question to the Chairs, do we have a good place to capture this
> kind of thing? A non-spec document like this would be a good candidate for
> a wiki page. Do we have plans to set up a GitHub repository or similar? If
> so we could use the wiki capabilities there to at least get this stuff
> written down. Use cases would be good to capture there as well.
>
>
>
> Francis,
>
> First, I want to thank you for putting the work in to getting some
> vocabulary down. This is not an easy task! Some notes on specific items
> inline below.
>
> The differentiation between “resource” and “claim” is important since it
> separates items that get tied to an access token’s rights (“resources”)
> with items that come back directly to the client without going through a
> separate API. The term “claim” is problematic here though because it is
> used broadly in the community to mean, roughly, “a statement about the end
> user”. It’s therefore both too broad and too narrow in the wrong ways: a
> “claim” could come back as part of an API response, like the OIDC UserInfo
> Endpoint, and so it’s not a good name for this item. Even the OIDC “claims”
> query language defines several different targets for returning the “claims”
> about the user, and none of them match the method that GNAP is looking to
> use here. A “claim” is also generally understood in the identity community
> to be a statement about the user, and the data coming back directly to the
> client might be about the user or something else, especially as we look
> forward to extensions of GNAP.
>
> I think we should focus on the separation of the delivery mechanism, but
> I’m not sure what good alternatives would be. Perhaps:
>
> I’m not particularly thrilled by these names, but I think recent list
> conversation shows that we need to get away from “claim” as it’s overloaded.
>
>
> I don’t like the shift from “Authorization Server” to “Grant Server”, and
> it especially doesn’t make sense in light of the definitions of “grant” and
> “authorization” above. I believe we should stick with “Authorization
> Server” if it’s a single role. I would also propose that we have a separate
> term for the RO-interactive portion vs. the client-facing portion, as has
> been brought up in a few threads. Maybe these get different names entirely,
> or maybe they are “aspects” of the AS, I’m not sure.
>
>
> Consent - act of an RO :
> I think we should be clear that what we call the “client” is a piece of
> software operated by the user. It’s true that this software might have
> multiple parts of its “infrastructure” but it’s always software.
>
>
> In UMA, we call this the “Requesting Party”, or RqP. We might want to
> consider adopting this terminology here as well.
>
>
> Clarifications:
> ==========
>
> User vs. RO :
> The term “user agent” is often used to be equivalent to the web browser,
> and not the more general use here. I think we’re seeing more “agent”
> terminology for helper applications like digital wallets and AI bots, which
> would seem to be covered under your definition here.
>
>
> Feedbacks are welcome.
>
>

---

From: Francis Pouatcha <[email-masked]>
Date: Thu, 23 Jul 2020 21:01:57 -0400

Hello Justin,

thanks a lot for the feedback, some comments inline,

> forward to extensions of GNAP.
I fully understand your problem. It won't be obvious to find a replacement.
I often think about the word Assertion. But I not sure if the word won't
come with its own controversies.

Essential for us now is to narrow the intended meaning of the term in the
context of GNAP and then look for the correct replacement, if any.  What
about this?

<In the context of GNAP>
A Claim
  - is an "assertion" of the truth of some properties or attributes of the
RO.
  Note-1: A Claim is produced either by the GS or by another claim source.
  Note-2: A Claim is held and guarded by the Grant Server (GS).
  Note-3: A Claim is released by the GS to a Client.
                  [REMOVED: "as part of an Authorization", as Justin
mentions bellow possibility of a claim to be included in userInfo and other
introspection responses]
  Note-4: The release of a Claim is controlled by the RO
                  [ADDED: "release", to distinguish it from the
"production" of the claim. Some Claims are just provided by the RO, some
other Claims are produced by authorities, that take care of verifying the
claim and/or legitimating them]

>  - “data response” for things coming back directly to the client
Here you are referring to the target of the information. And it is more
difficult to nail formalized. A claim might be targeted for the RS and not
the Client.

I suggest we first stay with: "resource access" and "claim release" (both
Grants as mentioned by Dick above). Rationale being:
- the clarification that a Resource is not a Claim, but that both are
controlled by the RO
- the clarification of a Claim is held by the GS,
- the clarification of a Resource is held by the RS,

> conversation shows that we need to get away from “claim” as it’s overloaded.
Let us look at this after we have narrowed a definition in the context of
GNAP.

> or maybe they are “aspects” of the AS, I’m not sure.
I also did not see any difference to functions of an AS. But i suggest we
shift the discussion on renaming the term GS to another thread and keep the
focus on this thread on elaborating terms in the context of GNAP.

> multiple parts of its “infrastructure” but it’s always software.
Yes.
Client - the party that implements the infrastructure used by a User to
access a Resource:
   Note-1: a Client is always a piece of software running either on the
User device or as a web service.
   Note-2: The Client infrastructure is designed to:
      - receive the resource access request from the User,
      - interact with the RS to discover authorization requirements,
      - interact with the GS to obtain an Authorization to access the
Resource,
      - interact with the RS to access the Resource on behalf of the User.

> consider adopting this terminology here as well.
I admit the term User is confusing. Like for GS vs AS above, let us start a
new thread on this.

> Yes. We do need feedback here.

Just as a summary:
- I will update the dictionary after we receive feedback on the definitions
of Claim and Client as reformulated in the answer.
- would you start a new thread for the renaming of GS to AS?
- would you start a new thread for the renaming of Client to Requesting
Party.

Thanks a lot for the feedback.

---

From: Francis Pouatcha <[email-masked]>
Date: Thu, 23 Jul 2020 21:04:03 -0400

>
>
> Just as a summary:
> - I will update the dictionary after we receive feedback on the
> definitions of Claim and Client as reformulated in the answer.
> - would you start a new thread for the renaming of "User" to "Requesting
Party"

---

From: Francis Pouatcha <[email-masked]>
Date: Thu, 23 Jul 2020 22:16:14 -0400

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.

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

Yes.

>       - may be a Resource the Client can access through an RS
Not sure we need to refer to a Resource as a Claim.

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.
  Note-2: A Claim is held and guarded by the Grant Server (GS).
  Note-3: A Claim is released by the GS to a Client.
  Note-4: The permission to release of a Claim is given by the RO.

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

>     - presented by the Client when accessing a Resource at an RS
An access token might contain Claims.

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
  Note-3: An access token is presented by the Client when accessing a
Resource at an RS

>       - has delegated Resource access control to one or more GSes
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).

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,
      - controls a Claim,
      - relies on the services the GS to release that Claim to a Client.

>       - accepts access tokens from one or more GSes
I suggest "guards" instead of "controls". As access to a resource is
controlled by the RO.

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

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

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

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

>     - may have Claims managed at a GS
Not sure a user has to be human.
Maybe first renaming to "Requesting Party" might help with narrowing the
term.

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

Ok.

> This is the entity that issues Claims. It may be a GS or an RS.
Yes for the term "Claim Issuer".

No for a "Claim Issuer" being an RS. At least not in its role as an RS. RS
shall focus on guarding and serving a Resource. Issuing a claim is
authoritative and might come with more complexity (verification of
authenticity). Having an RS issue a claim will overload the role of an RS
and increase the complexity of the framework.

/Francis

---

From: Dick Hardt <[email-masked]>
Date: Thu, 23 Jul 2020 19:43:15 -0700

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

>
> A Claim - an assertion of the truth of some properties or attributes of
> the RO.

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.

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

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

>   Note-4: The permission to release of a Claim is given by the RO.

I will see what you say below on User ...

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

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

>   Note-2: An access token can also contain claims

See above.

> delegates Resource access management to GS but keeps control (or decision).

agreed - access management is better.

>       - relies on the services of a RS to hold a Resource and guard access

I don't think "guard" is a good verb. "protect" is often used.

If we are switching from "owns a resource" to "controls a resource", then
perhaps the entity should be a Resource Controller (RC)?

>       - controls a Claim,

Why does the RO control a claim?

> I suggest "guards" instead of "controls". As access to a resource is

How about "protects access"?

> - Consent is from RO not User.

I'm confused why the Claims are about the RO and not 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.

>       - interacts with the RS to access the Resource using Access Tokens.

The Client also transfers the user experience to the GS in some flows.

Where do Claims fit into the cycle above?

> Not sure a user has to be human.

Why not? I think NOT having the User be a human is confusing.

>>> I don’t like the shift from “Authorization Server” to “Grant Server”,
>>> and it especially doesn’t make sense in light of the definitions of “grant”
>>> and “authorization” above. I believe we should stick with “Authorization
>>>       - approving access to a Resource, means approval that a Resource
>>> he controls can be given to the Client by the RS.
>>> to a Resource or a Claim.
>>>
>>>
>>> In many use cases, User and RO will be represented by the same party
>>> (see oAuth2), but GNAP exposes use cases where User and RO are represented
>>> by different parties.
>>>
>>> User-Agent :
ᐧ

---

From: Tom Jones <[email-masked]>
Date: Thu, 23 Jul 2020 22:28:46 -0700

i generally like this - i guess. you decided to drop "claim" from the list?
that is probably for the best. Claims certainly can come from the resource
one minor suggestion resource is data or service.  (nit - a piece of data
is called a datum)

I must object to the statement that the resource owner actually owns the
resource. That is demonstrably untrue in all the systems I work on. It is a
holder-over from microsoft Sharepoint where it meant the business owner. It
has never meant the actual data owner. Then Sharepoint goes to the extreme
of claiming to be the resource owner, but it never actually sets the acls
which give the access. So it never met the conditions of being an RO. The
Sharepoint system rapidly became unmanageable by the very business owners
that were meant to control the access. It is not a good model to follow. I
would be much happier if we stopped calling it a RO, but if we are stuck
with that at least say that the RO controls access rather than perpetuate a
myth.
Peace ..tom

---

From: Francis Pouatcha <[email-masked]>
Date: Fri, 24 Jul 2020 08:15:08 -0400

On Thu, Jul 23, 2020 at 10:44 PM Dick Hardt <[email-masked]> wrote:

>> in https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en. Still
>> to come.
>>
>>> 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!
>>>
>>>
> 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
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.

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.

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

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.

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

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

>>> Grant - the Claims and/or Resource Access the User and/or RO have
>>> granted to the Client by the GS
>>>     - requested by a Client
I need the example of a User that is different from the RO and that
controls the RO's Resource.

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.

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

>>       - relies on the services of a RS to hold a Resource and guard
>> access to that Resource,
>>
>
OK.

> perhaps the entity should be a Resource Controller (RC)?
Great. Will remove confusion.

> Why does the RO control a claim?
because a Claim is an assertion of the truth of some properties or
attributes of the RO.

> How about "protects access"?
OK for me.

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

> seems very confusing to me.
Then let us call him a  "Requesting Party"

>>     - provides the Client Claims about the RO after obtaining the
>> required consent from the RO
>>
>>
>> on behalf of a User or non-human service account
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.

> Why not? I think NOT having the User be a human is confusing.
Let us stay by the role "Requesting Party"instead of the entity "User"

>>> Claim Issuer - I think we may need to add this party to our
>>> nomenclature. This is the entity that issues Claims. It may be a GS or an
>>> RS.
>>>
>> No for a "Claim Issuer" being an RS. At least not in its role as an RS.
>> RS shall focus on guarding and serving a Resource. Issuing a claim is
>>>> Up-front question to the Chairs, do we have a good place to capture
>>>> this kind of thing? A non-spec document like this would be a good candidate
>>>> for a wiki page. Do we have plans to set up a GitHub repository or similar?
>>>> If so we could use the wiki capabilities there to at least get this stuff
>>>> The differentiation between “resource” and “claim” is important since
>>>> it separates items that get tied to an access token’s rights (“resources”)
>>>> I think we should focus on the separation of the delivery mechanism,
>>>> but I’m not sure what good alternatives would be. Perhaps:
>>>>
>>>>       For each Resource access request, the GS might request the
>>>> Consent of the RO and produce a corresponding Authorization that is given
>>>> User and RO are parties that might be represented by a natural person
>>>> or an autonomous device. In those cases, User (resp. RO) might need the
>>>> help of an application to interact with other parties. Such an application
>>>> is generally referred to as the "User-Agent".
>>>>
>>>>
>>>> The term “user agent” is often used to be equivalent to the web
>>>> browser, and not the more general use here. I think we’re seeing more
>>>> “agent” terminology for helper applications like digital wallets and AI
>>>> bots, which would seem to be covered under your definition here.
>>>>
>>>>
>>>> Feedbacks are welcome.
>>>>
>>>>
>>>>>> I pivoted to using the term Grant rather than authorization so that
>>>>>> it included both authorizing access to a resource, and authorizing the
>>>>>> release of an identity claim.
>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Jul 2020 08:58:24 -0400

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

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Jul 2020 10:16:26 -0700

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 <[email-masked]> wrote:

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

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

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

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

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

The Issuer is an entity. The GS is software.

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

> A Claim can exist before. GS might hold a Claim issued by an external

Would you provide an example?

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

See above.

> If we talk about roles and not entities, we will not fall into this

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

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

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.

> because a Claim is an assertion of the truth of some properties or

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?

>>>>     - grants the Client access to Resources after obtaining the

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

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

/Dick

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Jul 2020 10:24:30 -0700

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

ᐧ

On Fri, Jul 24, 2020 at 5:58 AM Justin Richer <[email-masked]> wrote:

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

---

From: Tom Jones <[email-masked]>
Date: Fri, 24 Jul 2020 10:32:24 -0700

Nat and I just had this discussion about claims & the claims aggregation
spec.
An example about claims that are not entirely about the user is the gurdian
ship case.
That case can be solved by creating a signed set if claims (which needs a
name) from the RO granting approval to the user to make a "ID Token"
(whatever) from the as to the client to be passed to the RS.
my suggesting is that claim as not necessarily attributes and the data
about the ro from the rs are distinct from the claims about the user from
the as.
I do not believe that claims aggregation is about claims (at least not
often).
so then the data from. the ro would never be a claim, even tho it was
identical in form and substance from the claim produced by the as.
Peace ..tom

On Fri, Jul 24, 2020 at 10:25 AM Dick Hardt <[email-masked]> 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
> Justin: you allude to Claims being about a party other than the User.
> 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.
>
>
>
>
> ᐧ
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Jul 2020 10:49:48 -0700

Hi Tom, thanks for sharing.

I would consider the guardianship use case to be issuing an access token,
not claims, as it is being used to access an RS.

In my view, we keep Claims in GNAP to be only about the User, and the only
consumer of the Claims is the Client the User is using. This keeps Claims
from being overly complex.

ᐧ

On Fri, Jul 24, 2020 at 10:32 AM Tom Jones <[email-masked]>
wrote:

> An example about claims that are not entirely about the user is the
> gurdian ship case.

---

From: Tom Jones <[email-masked]>
Date: Fri, 24 Jul 2020 11:10:09 -0700

now that is interesting.
So that i can understand what you're saying.
the access token that is issued (somehow) by the user to give the client
access to rs resources, does not have claims?
boy am i in the wrong place.

Peace ..tom

On Fri, Jul 24, 2020 at 10:50 AM Dick Hardt <[email-masked]> wrote:

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

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Jul 2020 11:27:13 -0700

I'm not saying an access token cannot have claims. I'm saying what the
Client communicates to the GS so that there are claims in an access token
is out of scope for GNAP.

Said another way, GNAP specifies a container used by the Client to request
access tokens from the GS, and then presents those access tokens to the RS.
The contents of the container in the Client request, and the access token
contents, are out of scope of the core GNAP protocol.

On Fri, Jul 24, 2020 at 11:10 AM Tom Jones <[email-masked]>
wrote:

>> In my view, we keep Claims in GNAP to be only about the User, and the
>> only consumer of the Claims is the Client the User is using. This keeps
>> Claims from being overly complex.
>>
>> ᐧ
>>
>>> That case can be solved by creating a signed set if claims (which needs
>>> a name) from the RO granting approval to the user to make a "ID Token"
>>>> 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].
>>>>
>>>> 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.
>>>>
>>>>> 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
>>>>> 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

---

From: Tom Jones <[email-masked]>
Date: Fri, 24 Jul 2020 11:31:27 -0700

right - & i want the client to be the as, so i guess there is no need for
what you claim to be the purpose of GNAP in self-issed ids.
Since that is what i want, i am outta here.
Peace ..tom

On Fri, Jul 24, 2020 at 11:27 AM Dick Hardt <[email-masked]> wrote:

>>> I would consider the guardianship use case to be issuing an access
>>> token, not claims, as it is being used to access an RS.
>>>
>>>> Nat and I just had this discussion about claims & the claims
>>>> aggregation spec.
>>>>>> 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

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Jul 2020 14:46:30 -0400

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 <[email-masked]> 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].
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Jul 2020 12:06:28 -0700

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 <[email-masked]> 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:
> 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.
>
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Jul 2020 15:42:28 -0400

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 <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 24, 2020, at 1:24 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Jul 2020 12:58:00 -0700

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 <[email-masked]> 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.
>
> 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
>> * 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.
>>
>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Jul 2020 16:39:49 -0400

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 <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 24, 2020, at 3:06 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 24 Jul 2020 13:57:50 -0700

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 <[email-masked]> 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
>
>>> 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
>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Fri, 24 Jul 2020 22:21:26 -0400

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 <[email-masked]> wrote:

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

---

From: Francis Pouatcha <[email-masked]>
Date: Fri, 24 Jul 2020 22:48:49 -0400

Hello Dick,

UserInfo Endpoint

This definition transported to GNAP will lead to confusion. The term user
in OIDC refers to both the User and the RO. Correct mapping to GNAP will
lead to the RoInfo Endpoint...

See [Txauth] Claims [was: - Dictionary]

>
> 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.
>
Have an illustration in the thread on Claims. User in oAuth and OIDC plays
both roles of User (as requestor of a resource) and User (as owner of a
resource)

> (I'm assuming you intended RS, not RP above)
yes. Sorry. RS....

> See above per the UserInfo endpoint being a Protected Resource, and is not
This endpoint is generally provided by the OP. Means the OP plays the role
of an RS.

>
>
>>
>> Note-x on GS definition: having a GS protecting access to some Claims
>> does not make the GS a RS.
>>
>>>> A Claim - an assertion of the truth of some properties or attributes
>>>> of the RO.
What do we refer to with the "iss" in a JWT?

> I'm saying a Resource *may* be a Claim, just as it is in OIDC UserInfo.
The word UserInfo in OIDC is misleading. This is the Info on User in it's
role as the RO. It is the RoInfo...

> Would you provide an example?
RO Identity Card signed by another authority, given to GS by RO, guarded by
GS and returned on request to Client/RS.

> RSes, that may return Claims about the User.
These are all OP/AS. They don't see the user, but the RO.

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

>>> If we are switching from "owns a resource" to "controls a resource",
>>> then perhaps the entity should be a Resource Controller (RC)?
>>>
Claim of User (in his role as an RO) -> RO-Attributed
Claim of User (in his role as a requesting party) -> Requestor Attributes.
See [Txauth] Claims [was: - Dictionary]

>>>>> Resource Server (RS) - the software that controls access to one or
>>>>> more Resources
I have a more extensive elaboration in : [Txauth] Claims [was: -
Dictionary]

>> 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
See [Txauth] Claims [was: - Dictionary]

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 26 Jul 2020 18:02:54 +0300

Hi Justin,

No. Unlike the use cases (which we agree should not be published as an RFC), a glossary is clearly a part of the specification. So it can be parked here on the mailing list until we have a WG document, and then copied over into the I-D.

Thanks,

                Yaron

From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Thursday, July 23, 2020 at 18:07
To: Francis Pouatcha <[email-masked]>
Cc: Tom Jones <[email-masked]>, Denis <[email-masked]>, <[email-masked]>, Dick Hardt <[email-masked]>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary

 

Francis,

Terms
=====

Claim - a piece of data

Consent - act of an RO :

Clarifications:

==========

User vs. RO : 

User-Agent :

Feedbacks are welcome.

 — Justin

Best regards,

/Francis

 

 

 

/Dick

-- 

Francis Pouatcha

adorsys GmbH & Co. KG

 

-- 

Francis Pouatcha

adorsys GmbH & Co. KG

-- Txauth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/txauth

---

From: Dick Hardt <[email-masked]>
Date: Sun, 26 Jul 2020 18:13:32 -0700

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.

I also think that Client and Resource Server are well understood terms.

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.

/Dick

ᐧ

On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha <[email-masked]> wrote:

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

---

From: Francis Pouatcha <[email-masked]>
Date: Sun, 26 Jul 2020 21:45:09 -0400

Hello Dick,

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

> Hi Francis
>
> User is a well understood term in OIDC and OAuth -- and User means the
> same in both.
>

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

> you have for your use case, otherwise I fear we will be talking past each
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

>> 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 IMO the most correct word in the entire protocol. Authorisation
>> is always about the owner of something granting access to a requestor. It
>> 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.
>>
>> GNAP is about defining the infrastructure that allows the requesting
>> party to access a 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).
>>
>>>> The two forms of direct data that XYZ returns are subject identifiers
>>>> (a subset of identity claims) and assertions — the latter being a container
>>>> 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”.
>>>>> 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.
>>>>>
>>>>>>>> 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.
>>>>>>>>

---

From: Tom Jones <[email-masked]>
Date: Sun, 26 Jul 2020 20:44:44 -0700

yeah. - one thought
let's look at a token issued by a user - so here's a guess.
1, a claim is a statement made about themself by the user (or the RO when
that is different.)
2. a grant is an authz for the client to acquire data about (inter alia)
data about the user.
Peace ..tom

---

From: Dick Hardt <[email-masked]>
Date: Sun, 26 Jul 2020 20:57:31 -0700

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

> "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?

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

>>> Unless I got it wrong, GNAP is about grant negotiation and
>>> authorization. This means:
>>>
>>> - The word User does not appear here, and is not relevant as the
>>> focus is on authorizing access to a resource.
>>> 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
>>> - Replacing the word User helps clarify the difference between both
>>> roles "Requestor" and "Resource Owner"
>>>> 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.
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ᐧ
>>>>>
>>>>>>> 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
>>>>>>> * 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
>>>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the
>>>>>>> GS directly in addition to the mechanisms in ODIC.
>>>>>>>
>>>>>>>> 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
>>>>>>>> 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

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 27 Jul 2020 06:12:27 -0400

> 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

> 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
Look at the client. It is the center of interaction between User, GS and RS.

> I'd like to take a step back and understand the requirements. We are deep
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

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 27 Jul 2020 07:23:07 -0400

Since you focused on the individual elements of the straw man examples you requested instead of the overall problem, I think you’re missing the core point. Let me bring it back to a concrete example:

In Xauth currently, you can use the “claims” query syntax from OIDC to request user claims inside the “claims.oidc” object on request. However, Xauth currently uses “userinfo” to mark information coming back directly to the client as JSON. Since “userinfo” is already defined by OIDC in this context to indicate information that should come back from the UserInfo Endpoint (and therefore as a resource, with rights tied to an access token), the Xauth approach would need a name other than “userinfo” here to indicate such claims coming back directly as JSON. 

What would you call that field?

Because whatever that field would be called is exactly the kind of data differentiation that I’m talking about here. And considering that Xauth already does differentiate between claims coming back as resources, as assertions, and direct JSON, I think it’s clear that it does matter.

 — Justin

> On Jul 24, 2020, at 4:57 PM, Dick Hardt <[email-masked]> 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.
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> [1] https://identity.foundation/presentation-exchange/ <https://identity.foundation/presentation-exchange/>
> 
>> On Jul 24, 2020, at 3:58 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Mon, 27 Jul 2020 08:14:52 -0400

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 <[email-masked]> wrote:
> 
> 
> 
> On Sun, Jul 26, 2020 at 11:58 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Sun, Jul 26, 2020 at 6:45 PM Francis Pouatcha <[email-masked] <mailto:[email-masked]>> wrote:
> Hello Dick,
> 
> On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> 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.
> 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.
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 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.
> 
> Unless I got it wrong, GNAP is about grant negotiation and authorization. This means:
> 
> GNAP is about defining the infrastructure that allows the requesting party to access a resource. 
> 
> - The word User does not appear here, and is not relevant as the focus is on authorizing access to a resource.
> 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".
> 
> - RP orchestrates interaction between User and OP to enable the user to obtain the protected 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).
> 
> 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.
> 
> - 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 <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Jul 2020 06:45:55 -0700

A slide in my presentation today may clarify how I am thinking about it.

On Mon, Jul 27, 2020 at 4:23 AM Justin Richer <[email-masked]> wrote:

> Since you focused on the individual elements of the straw man examples you
> requested instead of the overall problem, I think you’re missing the core
> point. Let me bring it back to a concrete example:
>
> In Xauth currently, you can use the “claims” query syntax from OIDC to
> request user claims inside the “claims.oidc” object on request. However,
> Xauth currently uses “userinfo” to mark information coming back directly to
> the client as JSON. Since “userinfo” is already defined by OIDC in this
> context to indicate information that should come back from the UserInfo
> Endpoint (and therefore as a resource, with rights tied to an access
> token), the Xauth approach would need a name other than “userinfo” here to
> indicate such claims coming back directly as JSON.
>
> Because whatever that field would be called is exactly the kind of data
> differentiation that I’m talking about here. And considering that Xauth
> already does differentiate between claims coming back as resources, as
> assertions, and direct JSON, I think it’s clear that it does matter.
>
>  — Justin
>
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Jul 2020 06:48:41 -0700

What is Requester or Requesting Party replacing? User?

Is a Role software?

On Mon, Jul 27, 2020 at 5:14 AM Justin Richer <[email-masked]> 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
>
>>> This distinction is what makes it confusing as we are comparing an
>>> Entity (the User) to a Role (the RO). We need two roles.
>>>
>>
>>>> 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.
>>>>
>>>>> 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:
>>>>> - 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)
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>>> 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:
>>>>>>>>> * 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ᐧ
>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Mon, 27 Jul 2020 15:00:14 -0400

Yes, the “Requester” would be replacing the “user” as the party operating the client software within the protocol. “End-user” also gets at this better than “user” as Mike Jones pointed out, but I think “Requester” or “Requesting Party” is even more specific.

A role isn’t software it’s … a role. It’s a set of actions and expectations that define relationships with other roles. A role could be fulfilled by a piece of software, though. The “AS” and “RS” roles would be fulfilled by software implementing those, and it might be the same piece of software (and therefore the same entity) in a particular instance.

 — Justin

> On Jul 27, 2020, at 9:48 AM, Dick Hardt <[email-masked]> wrote:
> 
> On Mon, Jul 27, 2020 at 5:14 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 27, 2020, at 6:12 AM, Francis Pouatcha <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>

---

From: Justin Richer <[email-masked]>
Date: Mon, 27 Jul 2020 16:11:20 -0400

I may have figured out a bit about how these approaches are actually different and why we might be talking past each other.

From what I can see, the Xauth style query is basically saying “here’s a block asking for all the identity stuff in the protocol, and telling you where to put the identity stuff in the response no matter where that is”. So this is why “claims” are the high-order element where things like query style and delivery are details of that.

XYZ takes a markedly different approach, basically saying “here’s a block that asks for stuff coming back from an RS and here’s a different block that asks for stuff coming back from the AS directly”. Some of those things coming back, in either place, could be claims about the user. (Or really claims about anything else, if you want to use the wider definition of the term.)

So fundamentally the composition is different. Xauth lists the identity stuff all together, whereas XYZ splits identity stuff based on how it’s coming back. Xauth seems to prefer describing all the identity data to be returned regardless of how it’s returned. I prefer the XYZ approach, where resources are always resources regardless of what they’re about, and direct data is always direct data regardless of what it’s about.

Is that an accurate read?

 — Justin

> On Jul 27, 2020, at 9:45 AM, Dick Hardt <[email-masked]> wrote:
> 
> On Mon, Jul 27, 2020 at 4:23 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 24, 2020, at 4:57 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Jul 2020 15:59:04 -0700

No, that is not accurate. XAuth is a super set of XYZ (as currently
written) as XYZ does not allow the direct return of claims from the GS.

If the Client wants an access token to retrieve Claims (name and email), it
includes the following JSON in its Grant Request:

"authorizations":{
    "token_1": {
        "type": "<standard_name_space>oidc_userinfo",
        "claims": { "email": null, "name": null }
    }

note: "standard_name_space" is to have a standardized RAR type for
oidc_userinfo

If the Client wants to get bare claims for name and email directly from the
GS, it includes:

"claims": {
    "oidc_userinfo": { "email": null, "name": null }
}

If the Client wants to get an ID Token containing name and email, it
includes:

"claims": {
    "oidc_id_token": { "email": null, "name": null }
}

Access tokens are always requested and returned in the "authorizations"
object, including if the access token is to access claims at a userinfo
endpoint.

Claims are always requested and returned in the "claims" object.

/Dick

On Mon, Jul 27, 2020 at 1:11 PM Justin Richer <[email-masked]> wrote:

> I may have figured out a bit about how these approaches are actually
> different and why we might be talking past each other.
>
> From what I can see, the Xauth style query is basically saying “here’s a
> block asking for all the identity stuff in the protocol, and telling you
> where to put the identity stuff in the response no matter where that is”.
> So this is why “claims” are the high-order element where things like query
> style and delivery are details of that.
>
> XYZ takes a markedly different approach, basically saying “here’s a block
> that asks for stuff coming back from an RS and here’s a different block
> that asks for stuff coming back from the AS directly”. Some of those things
> coming back, in either place, could be claims about the user. (Or really
> claims about anything else, if you want to use the wider definition of the
> term.)
>
>
> So fundamentally the composition is different. Xauth lists the identity
> stuff all together, whereas XYZ splits identity stuff based on how it’s
> coming back. Xauth seems to prefer describing all the identity data to be
> returned regardless of how it’s returned. I prefer the XYZ approach, where
> resources are always resources regardless of what they’re about, and direct
> data is always direct data regardless of what it’s about.
>
>
>> Since you focused on the individual elements of the straw man examples
>> you requested instead of the overall problem, I think you’re missing the
>> core point. Let me bring it back to a concrete example:
>>

---

From: Justin Richer <[email-masked]>
Date: Mon, 27 Jul 2020 19:09:49 -0400

Not really the point I was making here, and you can return claims directly from the AS in XYZ, but now we’re just talking in circles so I don’t think this is a productive thread anymore.

 — Justin

> On Jul 27, 2020, at 6:59 PM, Dick Hardt <[email-masked]> wrote:
> 
> No, that is not accurate. XAuth is a super set of XYZ (as currently written) as XYZ does not allow the direct return of claims from the GS.
> 
> If the Client wants an access token to retrieve Claims (name and email), it includes the following JSON in its Grant Request:
> 
> "authorizations":{ 
>     "token_1": { 
> note: "standard_name_space" is to have a standardized RAR type for oidc_userinfo
> 
> If the Client wants to get bare claims for name and email directly from the GS, it includes:
> 
> "claims": {
> If the Client wants to get an ID Token containing name and email, it includes:
> 
> "claims": {
> Access tokens are always requested and returned in the "authorizations" object, including if the access token is to access claims at a userinfo endpoint.
> 
> On Mon, Jul 27, 2020 at 1:11 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 27, 2020, at 9:45 AM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 27 Jul 2020 16:16:51 -0700

If I missed the point, please clarify.

This description of XYZ, is also a description of XAuth:

"here’s a block that asks for stuff coming back from an RS and here’s a
different block that asks for stuff coming back from the AS directly”. Some
of those things coming back, in either place, could be claims about the
user. (Or really claims about anything else, if you want to use the wider
definition of the term.)"

And the last I checked XYZ, it only supported identifier claims coming back
from the GS. If it now supports any claims, then XYZ and XAuth are pretty
much the same.

On Mon, Jul 27, 2020 at 4:09 PM Justin Richer <[email-masked]> wrote:

> Not really the point I was making here, and you can return claims directly
> from the AS in XYZ, but now we’re just talking in circles so I don’t think
> this is a productive thread anymore.
>
>  — Justin
>
> If the Client wants an access token to retrieve Claims (name and email),
> it includes the following JSON in its Grant Request:
>
> "authorizations":{
>     "token_1": {