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

From: Francis Pouatcha <[email-masked]>
Date: Sat, 11 Jul 2020 13:04:42 -0400

Some points raised here might match what I wrote before after reviewing the
last draft of XYZ.

1. Dictionary
I do like sections 1.x dealing with terms but this is kept too short. I
have noticed that most of the discussion conducted on the list results from
different understanding of terms used.

2. Abstract Protocol Flow

I am missing an abstract protocol flow like the one defined in
https://tools.ietf.org/html/rfc6749#section-1.2.

3. Parties
a) graphical illustration (#section-1.1)
I do like the graphical illustration in #section-1.1. The main difference
to the picture in https://tools.ietf.org/html/rfc6749#section-1.2 is the
clear separation between the "User" and the "Resource Owner" (RO). To help
transition the understanding of current oAuth2 implementers, it is
essential to illustrate and highlight the rationale behind this design.

b) Dynamic Client (#section-1.1)
I would like to mention that the dynamic client can present a certificate
issued by some authorities known to the GS. This is the case of QSeal
certificates designed by European eiDas.

c) Grant Server (GS)
If the GS is a SIOP running on the user device, how does it influence the
protocol design?

4. Interaction Modes (Protocol Flows)
And mentioned in my review of the XYZ protocol, I am missing a grouping of
interaction models. We need an abstraction layer in which we define groups
of flows based on key interaction between parties. I am expecting at least:

- "redirect" Interaction
here the GS instructs the Client to redirect the RO/User to the given
interaction
URL. This is well covered in #section-2.1. But for transparency this
picture must also display the "User". Shall the redirect interaction
presume that the "User" and the "Ro" are represented by the same party,
then it is worth mentioning this. In this case we can draw a single box to
represent both.

- "decoupled" Interaction
This interaction model is currently represented by the "user_code"
Interaction (#section-2.2) and the "indirect" Interaction (#section-2.3 and
#section-5.2). Both of these are forms of "decoupled" Interactions. Main
characteristic of a decoupled interaction shall be that the device used by
the RO to interact with the GS shall be separated from the. device used by
the "User" to interact with the "Client".

- "embedded" Interaction
With the evolving of smart end user devices that can keep private keys,
perform cryptographic operations, it is essential to include the "embedded"
Interaction in which RO/User device send authorization grant to "Client"
that in turns takes it to the GS in exchange of the authorization token. In
XYZ I found this hidden behind the didcom interaction.
The "embedded" interaction shall open room for different types of
synchronous transaction authorization requests in which the "RO/User" gives
a verifiable assertion (inkl. proof of possession) to the "Client" for use
at the GS in exchange for the seeked access token.

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

---

From: Dick Hardt <[email-masked]>
Date: Sun, 12 Jul 2020 11:53:58 -0700

Francis, thanks for the review ... questions and comments inserted ...

On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha <fpo=
[email-masked]> wrote:

> Some points raised here might match what I wrote before after reviewing
> the last draft of XYZ.
>

I'm assuming you are referring to this post:

https://mailarchive.ietf.org/arch/msg/txauth/v-iH5ID8VaOojx7fGniffrxCQdo/

Correct?

> different understanding of terms used.

Are terms missing, are the definitions too short, or both?
If you provide specific examples I can work on addressing them!

> https://tools.ietf.org/html/rfc6749#section-1.2.

That's an interesting point. GNAP also has identity claims, so the abstract
flow is somewhat different (there is no Authorization Grant from the RO),
and not all steps always happen. (there may not be steps (E) and (F) with a
Resource Server)

Would you elaborate on what you think would be useful here, that is not in
the specific flows?

> essential to illustrate and highlight the rationale behind this design.

Would a reference to #section-2.3
<https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-2.3> in
the RO definition, and more explanation in #section-2-3 on the rationale
address your concern?

> certificates designed by European eiDas.

I agree.

If we do mention that, we should specify how the certificate would be
presented and work. We can do that in the core GNAP document, in an GNAP
extension, or reference another specification. I'm not that familiar with
QSeal. Is it specified somewhere?

> If the GS is a SIOP running on the user device, how does it influence the

With mobile apps having URIs bound to specific apps, I think the protocol
would work the same, but I've not worked with SIOPs. Do you have any
concerns?

> here the GS instructs the Client to redirect the RO/User to the given interaction

Did you mean to say '... the picture must also display the "RO"'?

There could be a separate RO in a more complex flow, but we could define
this flow to represent where the User and RO are the same party.

> #section-5.2).. Both of these are forms of "decoupled" Interactions. Main

I like the word "decoupled" -- would "redirect" then be named "coupled"? Or
renamed "indirect" to "decoupled"?

While "user_code" and "indirect" are both decoupled, the "indirect" has
different security properties as it uses a link, which an attacker can
trick a user into clicking on wherever a link may be used.

I do agree that "user_code" and "indirect" are both a decoupled
interaction, and calling that out would be useful.

> at the GS in exchange for the seeked access token.

I have been thinking that the functionality you describe above would be in
the "user" object rather than in the "interaction" object as it is not an
interaction between the GS and the User. IE, the Client presents some
artifact to the GS that establishes the User in the GS context so that a GS
/ User interaction is not needed.

That looks similar to me to what Denis was proposing in

https://mailarchive.ietf.org/arch/msg/txauth/kgTKFHZDRDsXJlwW95Gqv_-LctA/

Does that work, or am I missing something?

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

---

From: Tom Jones <[email-masked]>
Date: Sun, 12 Jul 2020 13:47:38 -0700

Our health care solution is aligned quite well with Francis' design.  WRT
the client to GS assertion i recommend the use of the entity statement from
the OpenID federation spec.

The major issue with SIOP is getting some assertion that the user
device/app is trustworthy.  Kantara is working that problem right now. The
issue there is creation of some sort of "software statement" that could be
attested.

Peace ..tom

On Sun, Jul 12, 2020 at 12:01 PM Dick Hardt <[email-masked]> wrote:

> That's an interesting point. GNAP also has identity claims, so the
> abstract flow is somewhat different (there is no Authorization Grant from
> the RO), and not all steps always happen. (there may not be steps (E) and
> (F) with a Resource Server)
>
> <https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-2.3>
> in the RO definition, and more explanation in #section-2-3 on the rationale
> address your concern?
>
>
>
>>
>> And mentioned in my review of the XYZ protocol, I am missing a grouping
>> of interaction models. We need an abstraction layer in which we define
>> groups of flows based on key interaction between parties. I am expecting at
>> least:
>>
>> - "redirect" Interaction
> I like the word "decoupled" -- would "redirect" then be named "coupled"?
> Or renamed "indirect" to "decoupled"?
>

---

From: Francis Pouatcha <[email-masked]>
Date: Sun, 12 Jul 2020 22:31:37 -0400

Dick, my response inline

> https://mailarchive.ietf.org/arch/msg/txauth/v-iH5ID8VaOojx7fGniffrxCQdo/
Yes.

> If you provide specific examples I can work on addressing them!
Definitions are too short. I will provide a proper mail with my proposal of
what we might need to clarify and als limit each term.

> Would you elaborate on what you think would be useful here, that is not in
A diagram that generalizes the steps, independently of interaction mode is
essential for the reader's navigation of the rest of the document. This is
what #section-1.2 of RFC6749 does. I hope we can produce a similar diagram.

A subsection of
https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1 could
be defined for this.

> in the RO definition, and more explanation in #section-2-3 on the rationale
A subsection of
https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1 with
the RO vs. User clarification and some example interactions where they
diverge.

> QSeal. Is it specified somewhere?
This is the ETSI standard used by the European PSD2:
https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.04.01_60/ts_119495v010401p.pdf
.
There is a well managed infrastructure in the European Economic Area that
allows for "Certificate Based Dynamic Client".

> would work the same, but I've not worked with SIOPs. Do you have any
Yes. As the protocol flow designs inbound connectivity from Client to GS.
How does a client initiate a connection to the user device? Or we might
have alternative interactions without inbound connectivity to the GS?

> Did you mean to say '... the picture must also display the "RO"'?
Yes. For transparency, even if they are both in the same box.

> this flow to represent where the User and RO are the same party.
Yes.

> Or renamed "indirect" to "decoupled"?
Not sure.
- Let us use redirect, decoupled and embedded to refer to "families/types
of interaction". In which case "Indirect" will be an interaction mode of
the "decoupled family".
- I wouldn't call "redirect" and interaction mode, as there are many
variants of redirect. Let us keep the keyword for the family and specify
known variants of redirect interaction for more precision.

> interaction, and calling that out would be useful.
Yes.

> https://mailarchive.ietf.org/arch/msg/txauth/kgTKFHZDRDsXJlwW95Gqv_-LctA/
No. It is different.

> Does that work, or am I missing something?
Embedded in the sense above is about embedding the interaction RO <-> GS
into the communication path User <-> Client <-> GS.
The main purpose is to keep the Link User <-> Client uninterrupted (by any
type of redirect or decoupled interaction).

Best regards,

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Jul 2020 10:49:10 -0700

This was helpful! ... but I have more questions inline ...

On Sun, Jul 12, 2020 at 7:31 PM Francis Pouatcha <[email-masked]> wrote:

> <snip>

> Definitions are too short. I will provide a proper mail with my proposal
> of what we might need to clarify and als limit each term.
>

Great, thanks!

>> Would you elaborate on what you think would be useful here, that is not
>> in the specific flows?
>>
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
> could be defined for this.
>

Interaction modes are one dimension where the steps could be generalized,
but some steps are optional. For example, the User may not interact with
the GS, and the GS may interact with the RO. The Client may only want
claims, and there would be no step of the Client calling the RS.

A generalized diagram would need to include all optional steps so that it
did not mislead a reader into thinking the diagram included all general
steps, but it does not seem that is what you are asking for as you wrote:

A subsection of
be defined for this."

Perhaps you can share how you think the diagram would look?

>>> I do like the graphical illustration in #section-1.1. The main
>>> difference to the picture in
>>> https://tools.ietf.org/html/rfc6749#section-1.2 is the clear separation
>>> between the "User" and the "Resource Owner" (RO). To help transition the
>>> understanding of current oAuth2 implementers, it is essential to illustrate
>>> and highlight the rationale behind this design.
>>>
>>
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
> with the RO vs. User clarification and some example interactions where they
> diverge.
>

ok

>>> I would like to mention that the dynamic client can present a
>>> certificate issued by some authorities known to the GS. This is the case of
>>> QSeal certificates designed by European eiDas.
>>>
>>
>> I agree.
>>

Thanks! I'll look into that.

>
>>
>>>
>>> c) Grant Server (GS)
>>> If the GS is a SIOP running on the user device, how does it influence
>>> the protocol design?
>>>
>>

Now I think I understand. How does the Client make the Grant Request if the
Client is running locally on the User's device. Correct?

> Yes. For transparency, even if they are both in the same box.

Got it. Will add it to next version.

> known variants of redirect interaction for more precision.

I had not thought there were variants to "redirect". Would you elaborate on
the variants?

>> I have been thinking that the functionality you describe above would be
>> in the "user" object rather than in the "interaction" object as it is not
>> an interaction between the GS and the User. IE, the Client presents some

How is it different?

> type of redirect or decoupled interaction).

I'm sorry, I'm not following what you are getting at.
Would you elaborate more on what you are envisioning here?
Perhaps in a new thread so that others with interest in the same subject
are more likely to participate?

/Dick

ᐧ

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 15 Jul 2020 23:28:08 -0400

Hello Dick,

>> A diagram that generalizes the steps, independently of interaction mode
>> is essential for the reader's navigation of the rest of the document. This
>> is what #section-1.2 of RFC6749 does. I hope we can produce a similar
>> diagram.
>>
>> A subsection of
> could be defined for this."
>
find below my proposal of an abstract sequence diagram.

+----+  +------+  +---+  +---+  +---+
|User|  |Client|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
  |(1) Service Request     |      |
  |-------->|       |      |      |
  |         |(2) Service Intent   |
  |         |------>|      |      |
  |         |(3) AuthZ Challenge  |
  |         |<------|      |      |
  |         |(4) AuthZ Request    |
  |         |------------->|      |
  |         |       |      |(5) Consent Request
  |         |       |      |----->|
  |         |       |      |(6) Grant Consent
  |         |       |      |<-----|
  |         |(7) Grant Access (Token)
  |         |<-------------|      |
  |         |(8) Service Request (Token)
  |         +------>+      |      |
  |         |(9) Service Response |
  |         |<------|      |      |
  |(10) Service Response   |      |
  +<--------|       |      |      |
  +         +       +      +      +

(1) Service Request: This is the service request sent by a User to the
Client. This can be a simple file read request or even a complex payment
initiation request.

(2) Service Intent: In order to discover authorization requirements, the
Client sends a service intent to the RS.

(3) AuthZ Challenge: The response to a service intent request is generally
an AuthZ Challenge. The content of this AuthZ Challenge, can be an
identification challenge, an AuthZ exemption, or details on requested
AuthZ. The content AuthZ Challenge can be similar to the oAuth2 RAR.

(4) AuthZ Request : the Client sends an AuthZ Request to the GS including
the AuthZ Challenge. This request can be similar to the oAuth PAR request.

(5) Requests Consent : GS sends consent request to RO.
Remark: The abstract protocol flow does not display a response of the
request (4) to the Client. This is IMO a general misunderstanding. This
protocol wants the GS to collect a consent from the RO.
- In the case of a "redirect interaction", GS will use transport
infrastructure provided by the Client to instruct the User to send the RO
to the GS (in most cases, user and RO are identical).
- In the case of a "decoupled interaction", GS will directly contact RO and
collect consent in a direct interaction with the RO (see CIBA).
- In the case of an "embedded interaction", GS will allow the Client to
directly collect the Consent of the RO in a direct interaction with the
User.

(6) Grant Consent : RO return a Consent Grant to GS.

(7) Grant Access : GS produces the corresponding access token and returns
it to Client.

(8) Service Request : Client uses the access token to send the service
request to RS.

(9) and (10) are self explaining.

One of our upcoming exercises will be to challenge this abstract protocol
flow with existing interactions (and if possible associated use cases) to
see if we are missing something. After an agreement on the abstract
protocol flow we can make sure each interaction provides a mapping to step
1 to 10.

I will strip the rest of the post here. And bring further responses in
separate mails.

Best regards.
/Francis

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 16 Jul 2020 10:46:44 +0200

Hi,

That's interesting, however the important logic is actually implemented
within (5). And so for the reader, it might be quite difficult to
understand what we're after (compared to oauth2 for instance). So in my
view, this kind of schema has its place, but not at the start of the
document where we should primarily be concerned about explaining why
someone should read the document.

It's also not easy to understand :
- why we sometimes use different labels between requests and responses (for
instance, 5 and 6)
- sometimes we use "grant" and sometimes "authZ", and it doesn't seem very
clear what is the difference in use
A terminology section would be great to clarify.

If I understand correctly your remark in 5, you think the request/response
scheme (as in XYZ) may be misleading.
On the contrary, I think it allows support rich interaction scenarios (and
especially the ones you describe) with greater flexibility. For instance,
some would disagree with the assertion that the goal is for the GS to
gather consent (see discussion on putting that on client side). A fixed
interaction schema has the downside of not permitting other setups.

Fabien

On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha <fpo=
[email-masked]> wrote:

> - In the case of a "decoupled interaction", GS will directly contact RO
> and collect consent in a direct interaction with the RO (see CIBA).
> (9) and (10) are self explaining..
>

---

From: Francis Pouatcha <[email-masked]>
Date: Thu, 16 Jul 2020 08:10:07 -0400

Hello Fabian,

On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault <[email-masked]>
wrote:

> - why we sometimes use different labels between requests and responses
> (for instance, 5 and 6)
>
Will need support in drafting the correct terms. The main purpose of this
diagram is to help sharpen the definition of terms and verbs used in the
draft.

> clear what is the difference in use
IMO: the granting is the process of given permission.
- RO can grant his Consent to the User or Client
- GS can turn the RO Grant into an AuthZ.
- Client can use AuthZ to access a Resource.

Yes. There is a terminology section in there. We need to bring the wissing
words into the list and sharpen those already there.

> scheme (as in XYZ) may be misleading.
No. XYZ does IMO exactly  that. Just try to be more abstract for a better
description of the models.

> especially the ones you describe) with greater flexibility.
>
Flexibility shall not be put ahead of formal correctness.

> For instance, some would disagree with the assertion that the goal is for
> the GS to gather consent (see discussion on putting that on client side). A
> fixed interaction schema has the downside of not permitting other setups.
>
This discussion is the result of the lack of sharp terminology. Most of the
time mixing up gathering consent (the act) and the way consent is gathered
and transported from RO to GS (the interaction).
/Francis

>>>>> Would you elaborate on what you think would be useful here, that is
>>>>> not in the specific flows?
>>>>>
>>> Interaction modes are one dimension where the steps could be
>>> generalized, but some steps are optional. For example, the User may not
>>> interact with the GS, and the GS may interact with the RO. The Client may
>>> only want claims, and there would be no step of the Client calling the RS.
>>>
>>> A generalized diagram would need to include all optional steps so that
>>> it did not mislead a reader into thinking the diagram included all general
>> (3) AuthZ Challenge: The response to a service intent request is
>> generally an AuthZ Challenge. The content of this AuthZ Challenge, can be
>> an identification challenge, an AuthZ exemption, or details on requested
>> (9) and (10) are self explaining...
>>

---

From: Denis <[email-masked]>
Date: Thu, 16 Jul 2020 14:45:12 +0200

Hello  Francis,

The first two steps of your scenario are nice, in particular the second one:

    (2) Service Intent: In order to discover *authorization
    requirements*, the Client sends a service intent to the RS.

This means that the client first contacts the RS, instead of the GS.

However, the third step is missing to disclose to the client these 
"*authorization requirements*", in particular which AS(s),
it may contact, which attributes are requested and how/when/where the 
user consent is gathered.

Unless the scenario is mandating all the RSs to trust one and only one 
GS and the client to have a relationship with that GS,
the remaining steps of this scenario do not work.

Step (5) mandates the GS to know who the owner of a given RS is, and 
thus mandates the client to disclose to the GS the identity of the RS.
The consequence is the following : this scenario, /as well as the 
scenario described in draft-hardt-xauth-protocol-13/, allows the GS to 
act as Big Brother.

Denis

> Hello Fabian,
>
> On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     That's interesting, however the important logic is actually
>     implemented within (5). And so for the reader, it might be quite
>     difficult to understand what we're after (compared to oauth2 for
>     instance). So in my view, this kind of schema has its place, but
>     not at the start of the document where we should primarily be
>     concerned about explaining why someone should read the document..
>
>     - why we sometimes use different labels between requests and
>     responses (for instance, 5 and 6)
>
> Will need support in drafting the correct terms. The main purpose of 
> this diagram is to help sharpen the definition of terms and verbs used 
> in the draft.
>
>     - sometimes we use "grant" and sometimes "authZ", and it doesn't
>     seem very clear what is the difference in use
>
> Yes. There is a terminology section in there. We need to bring the 
> wissing words into the list and sharpen those already there.
>
>
>     If I understand correctly your remark in 5, you think the
>     request/response scheme (as in XYZ) may be misleading.
>
> No. XYZ does IMO exactly  that. Just try to be more abstract for a 
> better description of the models.
>
>     On the contrary, I think it allows support rich interaction
>     scenarios (and especially the ones you describe) with greater
>     flexibility.
>
>     For instance, some would disagree with the assertion that the goal
>     is for the GS to gather consent (see discussion on putting that on
>     client side). A fixed interaction schema has the downside of not
>     permitting other setups.
>
> This discussion is the result of the lack of sharp terminology. Most 
> of the time mixing up gathering consent (the act) and the way consent 
> is gathered and transported from RO to GS (the interaction).
> /Francis
>
>
>     Fabien
>
>     On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha
>     <fpo=[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hello Dick,
>
>
>                     That's an interesting point. GNAP also has
>                     identity claims, so the abstract flow is somewhat
>                     different (there is no Authorization Grant from
>                     the RO), and not all steps always happen. (there
>                     may not be steps (E) and (F) with a Resource Server)
>
>                     Would you elaborate on what you think would be
>                     useful here, that is not in the specific flows?
>
>                 A diagram that generalizes the steps, independently of
>                 interaction mode is essential for the reader's
>                 navigation of the rest of the document. This is
>             Interaction modes are one dimension where the steps could
>             be generalized, but some steps are optional. For example,
>             the User may not interact with the GS, and the GS may
>             interact with the RO. The Client may only want claims, and
>             there would be no step of the Client calling the RS.
>
>             A generalized diagram would need to include all optional
>             steps so that it did not mislead a reader into thinking
>             the diagram included all general steps, but it does not
>             seem that is what you are asking for as you wrote:
>
>             A subsection of
>         (1) Service Request: This is the service request sent by a
>         User to the Client. This can be a simple file read request or
>         even a complex payment initiation request.
>
>         (2) Service Intent: In order to discover authorization
>         requirements, the Client sends a service intent to the RS.
>
>         (3) AuthZ Challenge: The response to a service intent request
>         is generally an AuthZ Challenge. The content of this AuthZ
>         Challenge, can be an identification challenge, an AuthZ
>         exemption, or details on requested AuthZ. The content AuthZ
>         Challenge can be similar to the oAuth2 RAR.
>
>         (4) AuthZ Request : the Client sends an AuthZ Request to the
>         GS including the AuthZ Challenge. This request can be similar
>         to the oAuth PAR request.
>
>         Remark: The abstract protocol flow does not display a response
>         of the request (4) to the Client. This is IMO a general
>         misunderstanding. This protocol wants the GS to collect a
>         consent from the RO.
>         - In the case of a "redirect interaction", GS will use
>         transport infrastructure provided by the Client to instruct
>         the User to send the RO to the GS (in most cases, user and RO
>         are identical).
>         - In the case of a "decoupled interaction", GS will directly
>         contact RO and collect consent in a direct interaction with
>         the RO (see CIBA).
>         - In the case of an "embedded interaction", GS will allow the
>         Client to directly collect the Consent of the RO in a direct
>         interaction with the User.
>
>         (7) Grant Access : GS produces the corresponding access token
>         and returns it to Client.
>
>         (8) Service Request : Client uses the access token to send the
>         service request to RS.
>
>         (9) and (10) are self explaining....
>
>         One of our upcoming exercises will be to challenge this
>         abstract protocol flow with existing interactions (and if
>         possible associated use cases) to see if we are missing
>         something. After an agreement on the abstract protocol flow we
>         can make sure each interaction provides a mapping to step 1 to 10.
>
>         I will strip the rest of the post here. And bring further
>         responses in separate mails.
>
>         Best regards.
>         /Francis
>
>             ᐧ
>
>         -- 
>         Francis Pouatcha
>         [email-masked] <mailto:[email-masked]>

---

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

Hello Denis,

On Thu, Jul 16, 2020 at 8:45 AM Denis <[email-masked]> wrote:

> (2) Service Intent: In order to discover *authorization requirements*,
> the Client sends a service intent to the RS.
>

> However, the third step is missing to disclose to the client these "*authorization
> requirements*", in particular which AS(s),
> it may contact, which attributes are requested and how/when/where the user
> consent is gathered.
>
The response (2) AuthZ Challenge carries the reference to the GS. Mean the
resource server instructs the Client on which GS to approach for
authorization.

> Unless the scenario is mandating all the RSs to trust one and only one GS
> and the client to have a relationship with that GS,
Can you elaborate why it shall not work for many GSs?

> Step (5) mandates the GS to know who the owner of a given RS is
>
Step (5) mandates the GS to know the RO, as owner of the target Resource,
but not the RS (Resource Server). Resource not-equals RS.

, and thus mandates the client to disclose to the GS the identity of the
> RS.
No. Here there is no requirement from GS to know the RS.

> The consequence is the following : this scenario, *as well as the
> scenario described in draft-hardt-xauth-protocol-13*, allows the GS to
> act as Big Brother.
>
No.

RS will find a way to validate AuthZ produced by any GS. Means RS must
trust that very GS or trust somebody that trusts that very GS (e.g. CA).
GS must not know the RS but must understand the Resource and trust the
Resource Owner, so that GS can validate the RO Grant.

/Francis

>> someone should read the document..
>>
>> On the contrary, I think it allows support rich interaction scenarios
>> (and especially the ones you describe) with greater flexibility.
>>
> This discussion is the result of the lack of sharp terminology. Most of
> the time mixing up gathering consent (the act) and the way consent is
> gathered and transported from RO to GS (the interaction).
> /Francis
>
>
>> Fabien
>>
>>>>> A diagram that generalizes the steps, independently of interaction
>>>>> mode is essential for the reader's navigation of the rest of the
>>>>> document. This is what #section-1.2 of RFC6749 does. I hope we can produce
>>>>> a similar diagram.
>>>>>
>>>>> A subsection of
>>> (4) AuthZ Request : the Client sends an AuthZ Request to the GS
>>> including the AuthZ Challenge. This request can be similar to the oAuth PAR
>>> request.
>>>
>>> (7) Grant Access : GS produces the corresponding access token and
>>> returns it to Client.
>>>
>>> One of our upcoming exercises will be to challenge this abstract
>>> protocol flow with existing interactions (and if possible associated use
>>> cases) to see if we are missing something. After an agreement on the
>>> abstract protocol flow we can make sure each interaction provides a mapping
>>> to step 1 to 10.
>>>

---

From: Denis <[email-masked]>
Date: Thu, 16 Jul 2020 18:57:23 +0200

Hello Francis,

> Hello Denis,
>
> On Thu, Jul 16, 2020 at 8:45 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello  Francis,
>
>     it may contact, which attributes are requested and how/when/where
>     the user consent is gathered.
>
> The response (2) AuthZ Challenge carries the reference to the GS. Mean 
> the resource server instructs the Client on which GS to approach for 
> authorization.

This information was not mentioned in your description.

>
>     Unless the scenario is mandating all the RSs to trust one and only
>     one GS and the client to have a relationship with that GS,

Your answer above mentions : "which GS to approach for authorization". 
It uses the singular whereas it should use the plural.

In addition, indicating only which GS*s* (plural) is insufficient, since 
the RS also needs to indicate to the Client which attributes
are requested for each of these GSs.

Your description is also silent to explain how/when/where the user 
consent is gathered.

> Step (5) mandates the GS to know the RO, as owner of the target 
> Resource, but not the RS (Resource Server). Resource not-equals RS.
>
>     , and thus mandates the client to disclose to the GS the identity
>     of the RS.
>

> No. Here there is no requirement from GS to know the RS.

In your are using the terminology of RFC 6749, then page 5 states:

    In OAuth, the client requests access to resources controlled by the
    resource owner and hosted by the resource server.

In order to make sure that the right RO is in charge of the appropriate 
RS, the GS needs to maintain a mapping between the RS and the RO.
The client does not know who the ROs are.

>     scenario described in draft-hardt-xauth-protocol-13/, allows the
>     GS to act as Big Brother.
>
> No.

If the GS is in a position to know when a client is attempting to make 
an access to a given RS, then it can maintain logs of these events.

> RS will find a way to validate AuthZ produced by any GS.

No. A RS trusts some GSs for some kinds of attributes. It does not trust 
all the GSs that might exist in the world.

> Means RS must trust that very GS or trust somebody that trusts that 
> very GS (e.g. CA).

Trust relationships are not necessarily transitive (nor bilateral).

> Resource Owner, so that GS can validate the RO Grant.

It would be interesting if you could elaborate on the last part of this 
sentence :
"[GS] must understand the Resource and trust the Resource Owner, so that 
GS can validate the RO Grant".

Denis

>>         implemented within (5). And so for the reader, it might be
>>         quite difficult to understand what we're after (compared to
>>         oauth2 for instance). So in my view, this kind of schema has
>>         its place, but not at the start of the document where we
>>         should primarily be concerned about explaining why someone
>>         should read the document..
>>
>>     Will need support in drafting the correct terms. The main purpose
>>     of this diagram is to help sharpen the definition of terms and
>>     verbs used in the draft.
>>
>>         - sometimes we use "grant" and sometimes "authZ", and it
>>         doesn't seem very clear what is the difference in use
>>
>>     Yes. There is a terminology section in there. We need to bring
>>     the wissing words into the list and sharpen those already there.
>>
>>
>>     No. XYZ does IMO exactly  that. Just try to be more abstract for
>>     a better description of the models.
>>
>>         For instance, some would disagree with the assertion that the
>>         goal is for the GS to gather consent (see discussion on
>>         putting that on client side). A fixed interaction schema has
>>         the downside of not permitting other setups.
>>
>>     This discussion is the result of the lack of sharp terminology.
>>     Most of the time mixing up gathering consent (the act) and the
>>     way consent is gathered and transported from RO to GS (the
>>     interaction).
>>     /Francis
>>
>>
>>         Fabien
>>
>>                         identity claims, so the abstract flow is
>>                         somewhat different (there is no Authorization
>>                         Grant from the RO), and not all steps always
>>                         happen. (there may not be steps (E) and (F)
>>                         with a Resource Server)
>>
>>                         Would you elaborate on what you think would
>>                         be useful here, that is not in the specific
>>                         flows?
>>
>>                     A diagram that generalizes the steps,
>>                     independently of interaction mode is essential
>>                     for the reader's navigation of the rest of the
>>                     document. This is what #section-1.2 of RFC6749
>>                     does. I hope we can produce a similar diagram.
>>
>>                     A subsection of
>>                 Interaction modes are one dimension where the steps
>>                 could be generalized, but some steps are optional.
>>                 For example, the User may not interact with the GS,
>>                 and the GS may interact with the RO. The Client may
>>                 A generalized diagram would need to include all
>>                 optional steps so that it did not mislead a reader
>>                 into thinking the diagram included all general steps,
>>                 but it does not seem that is what you are asking for
>>                 as you wrote:
>>
>>                 A subsection of
>>             (1) Service Request: This is the service request sent by
>>             a User to the Client. This can be a simple file read
>>             request or even a complex payment initiation request.
>>
>>             (3) AuthZ Challenge: The response to a service intent
>>             request is generally an AuthZ Challenge. The content of
>>             this AuthZ Challenge, can be an identification challenge,
>>             an AuthZ exemption, or details on requested AuthZ. The
>>             content AuthZ Challenge can be similar to the oAuth2 RAR.
>>
>>             (4) AuthZ Request : the Client sends an AuthZ Request to
>>             the GS including the AuthZ Challenge. This request can be
>>             similar to the oAuth PAR request.
>>
>>             Remark: The abstract protocol flow does not display a
>>             response of the request (4) to the Client. This is IMO a
>>             general misunderstanding. This protocol wants the GS to
>>             collect a consent from the RO.
>>             transport infrastructure provided by the Client to
>>             instruct the User to send the RO to the GS (in most
>>             cases, user and RO are identical).
>>             - In the case of a "decoupled interaction", GS will
>>             directly contact RO and collect consent in a direct
>>             interaction with the RO (see CIBA).
>>             - In the case of an "embedded interaction", GS will allow
>>             the Client to directly collect the Consent of the RO in a
>>             direct interaction with the User.
>>
>>             (7) Grant Access : GS produces the corresponding access
>>             token and returns it to Client.
>>
>>             (8) Service Request : Client uses the access token to
>>             send the service request to RS.
>>
>>             something. After an agreement on the abstract protocol
>>             flow we can make sure each interaction provides a mapping
>>             to step 1 to 10.
>>

---

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

Hi Francis

Thanks for drafting the sequence diagram and descriptions! I really like
where. you are going with it.

As our objective is to provide an abstraction,  what do you think of
collapsing steps 2&3, 5&6, and 8&9 in the diagram?

Per the discussion to your post, there is also some tuning of the
descriptions of each step. I would also add in which steps are optional.

Referencing other parts of the document would be useful, as this
abstraction is intended to be a high level guide to the protocol, so adding
other top level sections to the document, even if they are thin, would help
the reader in grasping the possible flows.

/Dick

On Thu, Jul 16, 2020 at 9:57 AM Denis <[email-masked]> wrote:

> Your answer above mentions : "which GS to approach for authorization". It
> uses the singular whereas it should use the plural.
>
> Your description is also silent to explain how/when/where the user consent
> is gathered.
>
>
>>
> If the GS is in a position to know when a client is attempting to make an
> access to a given RS, then it can maintain logs of these events.
>
> Means RS must trust that very GS or trust somebody that trusts that very
> GS (e.g. CA).
>
>> - sometimes we use "grant" and sometimes "authZ", and it doesn't seem
>>> very clear what is the difference in use
>>>
>>> For instance, some would disagree with the assertion that the goal is
>>> for the GS to gather consent (see discussion on putting that on client
>>> side). A fixed interaction schema has the downside of not permitting other
>>> setups.
>>>
>>>> (2) Service Intent: In order to discover authorization requirements,

---

From: Francis Pouatcha <[email-masked]>
Date: Thu, 16 Jul 2020 16:05:27 -0400

Hello Dick, Denis,

here is an updated version of the diagram following Dick's advice to
collapse responses and some clarifications as raised by Denis:

+----+  +------+  +---+  +---+  +---+
|User|  |Client|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
  |(1) ServiceRequest      |      |
  |-------->|       |      |      |
  |         |(2) ServiceIntent:AuthZChallenge
  |         |<----->|      |      |
  |         |       |      |      |
  |         |(3) AuthZRequest(AuthZChallenge)
  |         |------------->|      |
  |         |       |      |(4) ConsentRequest:Grant
  |         |       |      |<---->|
  |         |(5) GrantAccess(AuthZ)
  |         |<-------------|      |
  |         |       |      |      |
  |         |(6) ServiceRequest(AuthZ):ServiceResponse
  |         |<----->|      |      |
  |(7) ServiceResponse     |      |
  |<--------|       |      |      |
  +         +       +      +      +

Nomenclature of Arrows:
---> designate a request.
<--- designates a response.
<--> request with immediate response.

Step, Action and Interaction:
This diagram describes actions and not interactions:
- Each step carries a number.
- An action with immediate response is collapsed into a single step (2, 4,
6).
- An action with deferred response is represented by two steps (1&7, 3&5).
- An action might be carried out using many interactions and might for the
purpose of transport involve more parties (see redirect interaction bellow)

(1) ServiceRequest
This is the service request sent by the User to the Client. This can be a
simple file read request or a complex payment initiation request.

(2) ServiceIntent:AuthZChallenge
In order to discover authorization requirements, the Client sends
a ServiceIntent request to the RS. The response to a ServiceIntent request
is an AuthZChallenge.
The content of an AuthZChallenge can be similar to the oAuth2 RAR.
The content of the AuthZChallenge can be:
- An identification challenge. Generally when the RS can not associate the
ServiceRequest with an RO.
- An AuthZ exemption. Generally when the RS needs no further AuthZ to
fulfill the Client request.
- Details on the requested AuthZ, including instructions on which GSs the
Client can approach for AuthZ; instructions on which attributes are
requested for each of these GSs.

(3) AuthZRequest(AuthZChallenge)
The Client sends an AuthZRequest to the GS including the AuthZChallenge.
This request can be similar to the oAuth2 PAR request.

(4) ConsentRequest:Grant
GS sends a consent request to RO. The way a GS connects with the RO to
collect RO's consent (Grant) is dependent on the interaction mode. This is
also valid for the nature of the Grant returned by the RO to the GS.
- In the case of a "redirect interaction", GS will use the transport
infrastructure provided by the Client to instruct the User to send the RO
to the GS authorization endpoint (in most cases, user and RO are
identical). In the case of oAuth2 AuthCode flow, the Grant provided by the
RO is stored by the GS (AS) at the AuthZ endpoint, then mapped to an
authCode that is transported by the User (User Agent) through the Client to
the token endpoint of the GS.
- In the case of a "decoupled interaction", GS will directly contact RO and
collect consent in a direct interaction with the RO (see CIBA). This
diagram assumes GS can evaluate the AuthZChallenge to find out how to
locate the RO. As there is a direct interaction between the GS and the RO,
the form/nature of the Grant is left to the discretion of the concrete
interaction mode.
- In the case of an "embedded interaction", GS will allow the Client to
directly collect the Consent (Grant) of the RO in a direct interaction
between the Client and the User (also assuming in most cases, that user and
RO are identical); and then send it to the GS in exchange of the AuthZ. We
say the interaction between GS and RO is embedded in the communication with
the Client.

(5) GrantAccess(AuthZ)
>From evaluating the Grant provided by the client, the GS produces a
corresponding access token and returns it to the Client.
Note that GS knowledge of the original or target RS is not necessary for
the issuance of the access token, unless GS is required to bind the token
to a target RS.

(6) ServiceRequest(AuthZ):ServiceResponse
Client uses the GS provided AuthZ to send the service request to RS. Recall
that AuthZ (token) can be, but must not be bound to an RS.

(7) is self explaining.

1 to 7.

/Francis

On Thu, Jul 16, 2020 at 2:15 PM Dick Hardt <[email-masked]> wrote:

>>> this diagram is to help sharpen the definition of terms and verbs used in
>>> the draft.
>>>
>>>>>> A generalized diagram would need to include all optional steps so
>>>>>> that it did not mislead a reader into thinking the diagram included all
>>>>>> general steps, but it does not seem that is what you are asking for as you
>>>>>> wrote:
>>>>>>
>>>>>> A subsection of
>>>>> - In the case of a "decoupled interaction", GS will directly contact
>>>>> RO and collect consent in a direct interaction with the RO (see CIBA).
>>>>> - In the case of an "embedded interaction", GS will allow the Client
>>>>> to directly collect the Consent of the RO in a direct interaction with the
>>>>> User.
>>>>>

---

From: Denis <[email-masked]>
Date: Fri, 17 Jul 2020 18:21:07 +0200

Hello Francis and Dick,

The good news first: we are making some progress. We are now close to an 
agreement with steps (1) up to (3),
... except that the place where the user consent is captured is not 
mentioned/indicated.

If a RO needs to be involved and since a RO is directly associated with 
a RS, why can't it be directly queried
by the appropriate RS after step (2) or later on ?

Which information is supposed to be presented to the RO ?
Which information is supposed to be returned by the RO ?

Denis

> - An action with immediate response is collapsed into a single step 
> (2, 4, 6).
> - An action might be carried out using many interactions and might for 
> the purpose of transport involve more parties (see redirect 
> interaction bellow)
>
> (1) ServiceRequest
> This is the service request sent by the User to the Client. This can 
> be a simple file read request or a complex payment initiation request.
>
> a ServiceIntent request to the RS. The response to a ServiceIntent 
> request is an AuthZChallenge.
> - An identification challenge. Generally when the RS can not associate 
> the ServiceRequest with an RO.
> - Details on the requested AuthZ, including instructions on which GSs 
> the Client can approach for AuthZ; instructions on which attributes 
> The Client sends an AuthZRequest to the GS including the 
> AuthZChallenge. This request can be similar to the oAuth2 PAR request.
>
> (4) ConsentRequest:Grant
> collect RO's consent (Grant) is dependent on the interaction mode. 
> This is also valid for the nature of the Grant returned by the RO to 
> the GS.
> infrastructure provided by the Client to instruct the User to send the 
> RO to the GS authorization endpoint (in most cases, user and RO are 
> identical). In the case of oAuth2 AuthCode flow, the Grant provided by 
> the RO is stored by the GS (AS) at the AuthZ endpoint, then mapped to 
> an authCode that is transported by the User (User Agent) through the 
> Client to the token endpoint of the GS.
> This diagram assumes GS can evaluate the AuthZChallenge to find out 
> how to locate the RO. As there is a direct interaction between the GS 
> and the RO, the form/nature of the Grant is left to the discretion of 
> the concrete interaction mode.
> to directly collect the Consent (Grant) of the RO in a direct 
> interaction between the Client and the User (also assuming in most 
> cases, that user and RO are identical); and then send it to the GS in 
> exchange of the AuthZ. We say the interaction between GS and RO is 
> embedded in the communication with the Client.
>
> (5) GrantAccess(AuthZ)
> Note that GS knowledge of the original or target RS is not necessary 
> for the issuance of the access token, unless GS is required to bind 
> the token to a target RS.
>
> Client uses the GS provided AuthZ to send the service request to RS. 
> Recall that AuthZ (token) can be, but must not be bound to an RS.
>
> (7) is self explaining.
>
> protocol flow with existing interactions (and if possible associated 
> use cases) to see if we are missing something. After an agreement on 
> the abstract protocol flow we can make sure each interaction provides 
> a mapping to step 1 to 7.
>
> /Francis
>
> On Thu, Jul 16, 2020 at 2:15 PM Dick Hardt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Francis
>
>     Thanks for drafting the sequence diagram and descriptions! I
>     really like where. you are going with it.
>
>     As our objective is to provide an abstraction,  what do you think
>     of collapsing steps 2&3, 5&6, and 8&9 in the diagram?
>
>     abstraction is intended to be a high level guide to the protocol,
>     so adding other top level sections to the document, even if they
>     are thin, would help the reader in grasping the possible flows.
>
>     /Dick
>
>     On Thu, Jul 16, 2020 at 9:57 AM Denis <[email-masked]
>>                 (2) Service Intent: In order to discover
>>                 *authorization requirements*, the Client sends a
>>                 service intent to the RS.
>>
>>             However, the third step is missing to disclose to the
>>             client these "*authorization requirements*", in
>>             particular which AS(s),
>>             it may contact, which attributes are requested and
>>             how/when/where the user consent is gathered.
>>
>>         The response (2) AuthZ Challenge carries the reference to the
>>         GS. Mean the resource server instructs the Client on which GS
>>         to approach for authorization.
>
>>             Unless the scenario is mandating all the RSs to trust one
>>             and only one GS and the client to have a relationship
>>             with that GS,
>         Your answer above mentions : "which GS to approach for
>         authorization". It uses the singular whereas it should use the
>         plural.
>
>         In addition, indicating only which GS*s* (plural) is
>         insufficient, since the RS also needs to indicate to the
>         Client which attributes
>         Your description is also silent to explain how/when/where the
>>         Step (5) mandates the GS to know the RO, as owner of the
>>         target Resource, but not the RS (Resource Server). Resource
>>         not-equals RS.
>>
>>             , and thus mandates the client to disclose to the GS the
>>             identity of the RS.
>>
>
>             In OAuth, the client requests access to resources
>             controlled by the resource owner and hosted by the
>             resource server.
>
>         In order to make sure that the right RO is in charge of the
>         appropriate RS, the GS needs to maintain a mapping between the
>         RS and the RO.
>>             The consequence is the following : this scenario, /as
>>             well as the scenario described in
>>             draft-hardt-xauth-protocol-13/, allows the GS to act as
>>             Big Brother.
>>
>>         No.
>
>         If the GS is in a position to know when a client is attempting
>         to make an access to a given RS, then it can maintain logs of
>         these events.
>
>         No. A RS trusts some GSs for some kinds of attributes. It does
>         not trust all the GSs that might exist in the world.
>
>>         Means RS must trust that very GS or trust somebody that
>>         trusts that very GS (e.g. CA).
>
>>         GS must not know the RS but must understand the Resource and
>>         trust the Resource Owner, so that GS can validate the RO Grant.
>
>         It would be interesting if you could elaborate on the last
>         part of this sentence :
>         "[GS] must understand the Resource and trust the Resource
>         Owner, so that GS can validate the RO Grant".
>
>         Denis
>
>>
>>         /Francis
>>
>>
>>             Denis
>>
>>>             Hello Fabian,
>>>
>>>             <[email-masked]
>>>             <mailto:[email-masked]>> wrote:
>>>
>>>                 Hi,
>>>
>>>                 That's interesting, however the important logic is
>>>                 actually implemented within (5). And so for the
>>>                 reader, it might be quite difficult to understand
>>>                 what we're after (compared to oauth2 for instance).
>>>                 So in my view, this kind of schema has its place,
>>>                 but not at the start of the document where we should
>>>                 primarily be concerned about explaining why someone
>>>                 - why we sometimes use different labels between
>>>                 requests and responses (for instance, 5 and 6)
>>>
>>>             Will need support in drafting the correct terms. The
>>>             main purpose of this diagram is to help sharpen the
>>>             definition of terms and verbs used in the draft.
>>>
>>>                 - sometimes we use "grant" and sometimes "authZ",
>>>                 and it doesn't seem very clear what is the
>>>                 difference in use
>>>
>>>             Yes. There is a terminology section in there. We need to
>>>             bring the wissing words into the list and sharpen those
>>>             already there.
>>>
>>>
>>>                 If I understand correctly your remark in 5, you
>>>                 think the request/response scheme (as in XYZ) may be
>>>                 misleading.
>>>
>>>             No. XYZ does IMO exactly  that. Just try to be more
>>>             abstract for a better description of the models.
>>>
>>>                 On the contrary, I think it allows support rich
>>>                 interaction scenarios (and especially the ones you
>>>                 describe) with greater flexibility.
>>>
>>>                 For instance, some would disagree with the assertion
>>>                 that the goal is for the GS to gather consent (see
>>>                 discussion on putting that on client side). A fixed
>>>             This discussion is the result of the lack of sharp
>>>             terminology. Most of the time mixing up gathering
>>>             consent (the act) and the way consent is gathered and
>>>             transported from RO to GS (the interaction).
>>>             /Francis
>>>
>>>
>>>                 Fabien
>>>
>>>                                     I am missing an abstract
>>>                                     protocol flow like the one
>>>                                     defined in
>>>                                 abstract flow is somewhat different
>>>                                 (there is no Authorization Grant
>>>                                 from the RO), and not all steps
>>>                                 always happen. (there may not be
>>>                                 steps (E) and (F) with a Resource
>>>                                 Server)
>>>
>>>                             independently of interaction mode is
>>>                         Interaction modes are one dimension where
>>>                         the steps could be generalized, but some
>>>                         steps are optional. For example, the User
>>>                         may not interact with the GS, and the GS may
>>>                         interact with the RO. The Client may only
>>>                         want claims, and there would be no step of
>>>                         the Client calling the RS.
>>>
>>>                         A generalized diagram would need to include
>>>                         all optional steps so that it did not
>>>                         mislead a reader into thinking the diagram
>>>                         included all general steps, but it does not
>>>                     (1) Service Request: This is the service request
>>>                     sent by a User to the Client. This can be a
>>>                     simple file read request or even a complex
>>>                     payment initiation request.
>>>
>>>                     (2) Service Intent: In order to discover
>>>                     authorization requirements, the Client sends a
>>>                     service intent to the RS.
>>>
>>>                     (3) AuthZ Challenge: The response to a service
>>>                     intent request is generally an AuthZ Challenge.
>>>                     The content of this AuthZ Challenge, can be an
>>>                     identification challenge, an AuthZ exemption, or
>>>                     details on requested AuthZ. The content AuthZ
>>>                     (4) AuthZ Request : the Client sends an AuthZ
>>>                     Request to the GS including the AuthZ Challenge.
>>>                     This request can be similar to the oAuth PAR
>>>                     request.
>>>
>>>                     Remark: The abstract protocol flow does not
>>>                     display a response of the request (4) to the
>>>                     Client. This is IMO a general misunderstanding.
>>>                     This protocol wants the GS to collect a consent
>>>                     from the RO.
>>>                     - In the case of a "redirect interaction", GS
>>>                     will use transport infrastructure provided by
>>>                     the Client to instruct the User to send the RO
>>>                     - In the case of a "decoupled interaction", GS
>>>                     will directly contact RO and collect consent in
>>>                     a direct interaction with the RO (see CIBA).
>>>                     - In the case of an "embedded interaction", GS
>>>                     will allow the Client to directly collect the
>>>                     Consent of the RO in a direct interaction with
>>>                     the User.
>>>
>>>                     (7) Grant Access : GS produces the corresponding
>>>                     access token and returns it to Client.
>>>
>>>                     (8) Service Request : Client uses the access
>>>                     token to send the service request to RS.
>>>
>>>                     One of our upcoming exercises will be to
>>>                     challenge this abstract protocol flow with
>>>                     existing interactions (and if possible
>>>                     associated use cases) to see if we are missing
>>>                     something. After an agreement on the abstract
>>>                     protocol flow we can make sure each interaction
>>>                     provides a mapping to step 1 to 10.
>>>
>>>                     I will strip the rest of the post here. And
>>>                     bring further responses in separate mails.
>>>
>>>                     Best regards.
>>>                     /Francis
>>>
>>>                         ᐧ
>>>
>>>                     -- 
>>>                     Francis Pouatcha

---

From: Dick Hardt <[email-masked]>
Date: Fri, 17 Jul 2020 11:11:41 -0700

On Fri, Jul 17, 2020 at 9:21 AM Denis <[email-masked]> wrote:

> If a RO needs to be involved and since a RO is directly associated with a
> RS, why can't it be directly queried

Good question. Perhaps you can expand on a use case where that would be
useful?

> Which information is supposed to be returned by the RO ?

Just like how the user authenticates to an AS, how the AS and RO
communicate is out of scope. For many use cases, the User is the RO, and
the interaction is through a user interface, not a machine protocol.
ᐧ

---

From: Denis <[email-masked]>
Date: Mon, 20 Jul 2020 11:04:54 +0200

Hi Dick,

> On Fri, Jul 17, 2020 at 9:21 AM Denis <[email-masked] 
>     The good news first: we are making some progress. We are now close
>     to an agreement with steps (1) up to (3),
>     ... except that the place where the user consent is captured is
>     not mentioned/indicated.
>

This major question which is currently left unanswered is where, when 
and how the user consent is captured.

Another important point to consider and to explain is related to the 
assurances that the user can obtain about
the respect of his choices. This point is currently left unanswered in 
draft-hardt-xauth-protocol-13.

>
>     If a RO needs to be involved and since a RO is directly associated
>     with a RS, why can't it be directly queried
> Good question. Perhaps you can expand on a use case where that would 
> be useful?

Before I expand, would you be able to explain first under which 
circumstances a RO needs to be queried by a GS ?
How can the GS identify which RO to query ?

> communicate is out of scope.

At the moment, the usefulness of a dialogue between a GS and a RO has 
not been explained, nor demonstrated.
The question is about the functionality of that dialogue in terms of 
input and output information (and not about
the design of a protocol or of a user interface). Anyway, AFAIU a 
dialogue between a GS and a RO is optional.

> For many use cases, the User is the RO, and the interaction is through 
> a user interface, not a machine protocol.

Wait a second. You wrote "the User is the RO". The User is attempting to 
make an access to a RS by using a Client.
_That_ User is not the RO of the RS.

Denis

---

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

Hello Denis,

On Mon, Jul 20, 2020 at 5:04 AM Denis <[email-masked]> wrote:

> This major question which is currently left unanswered is where, when and
> how the user consent is captured.
>
In all circumstances. Can you name a situation where this is not the case?

> How can the GS identify which RO to query ?
There is supposed to be a preexisting relationship between GS and RO, If
not RO will have to register with GS in the first interaction (onboarding).

How can the GS identify how to connect with RO?
GS must evaluate the RS provided info in step (3)
AuthZRequest(AuthZChallenge) to decide how to contact the RO. This is where
selection of interaction mode takes place.

> At the moment, the usefulness of a dialogue between a GS and a RO has not
> been explained, nor demonstrated.
> The question is about the functionality of that dialogue in terms of input
> and output information (and not about
> the design of a protocol or of a user interface). Anyway, AFAIU a dialogue
> between a GS and a RO is optional.
>
> For many use cases, the User is the RO, and the interaction is through a
> user interface, not a machine protocol.
>
> *That* User is not the RO of the RS.
>
> The User interacts with the Client.
The RO interacts with the GS.

In some use cases (where we use redirect interaction) we assume the person
controlling the "User-Agent" is also the person controlling the "RO-Agent"
and they reside on the same device. These are cases where we say User
equals RO.
-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

---

From: Denis <[email-masked]>
Date: Mon, 20 Jul 2020 19:12:47 +0200

Hello  Francis,

> Hello Denis,
>
> On Mon, Jul 20, 2020 at 5:04 AM Denis <[email-masked] 
>>         The good news first: we are making some progress. We are now
>>         close to an agreement with steps (1) up to (3),
>>         ... except that the place where the user consent is captured
>>         is not mentioned/indicated.
>>
>
>     This major question which is currently left unanswered is where,
>     when and how the user consent is captured.
>
>     Another important point to consider and to explain is related to
>     the assurances that the user can obtain about
>     the respect of his choices. This point is currently left
>     unanswered in draft-hardt-xauth-protocol-13.
>
[Denis] These two major points are still left unanswered at this time.

>
>>
>>         If a RO needs to be involved and since a RO is directly
>>         associated with a RS, why can't it be directly queried
>>     Good question. Perhaps you can expand on a use case where that
>>     would be useful?
>

[Denis] This is quite easy. The final decision is always taken by the 
RS. If a Client presents access tokens issued by ASs trusted by the RS
that contain appropriate attributes to perform the requested operation, 
then the operation is allowed.

If really a human RO needs to be involved for whatever reason, it is 
possible to get its involvement when the Client connects to the RS.
However such involvement does not need to be formalized by a protocol. 
It can be application specific.

> There is supposed to be a preexisting relationship between GS and RO, 
> If not RO will have to register with GS in the first interaction 
> (onboarding).
>
> AuthZRequest(AuthZChallenge) to decide how to contact the RO. This is 
> where selection of interaction mode takes place.

[Denis] This means that a GS must have prior relationships with the RSs 
and ROs. While this should not be prevented for backward compatibility 
with OAuth 2.0,
this should not be the single case. Prior relationships between ROs and 
GSs is a door half-opened for Big Brother. If in addition the GS is able 
to know which operation
is attempted by the client on which RSs, then it is a door wide-opened 
for Big Brother.

>     At the moment, the usefulness of a dialogue between a GS and a RO
>     has not been explained, nor demonstrated.
>     The question is about the functionality of that dialogue in terms
>     of input and output information (and not about
>>     For many use cases, the User is the RO, and the interaction is
>>     through a user interface, not a machine protocol.
>
>     Wait a second. You wrote "the User is the RO". The User is
>     attempting to make an access to a RS by using a Client.
> In some use cases (where we use redirect interaction) we assume the 
> person controlling the "User-Agent" is also the person
> controlling the "RO-Agent" and they reside on the same device. These 
> are cases where we say User equals RO.

[Denis] Sorry, I have difficulties to understand such a case. A person 
giving his consent to himself ?

Denis

---

From: Tom Jones <[email-masked]>
Date: Mon, 20 Jul 2020 10:27:16 -0700

This interchange exhibits an essential problem of most of this work. The
idea that humans populate the web. I have yet to see a human with an
ethernet connection. So i must assume that the user agent is the essence of
the human on the web.

Second there are two terms which need to be distinct in the general case -
at least where the RO is a human and the resource contains PII.
The RO aka subject is the identifier that is used by a real world human
that has data on the web that is (inter alia) PII about them.
The user aka guardian (and often also the subject) is the identifier that
is used by a real world human that has acquired control of access to the
PII about the subject.

Peace ..tom

On Mon, Jul 20, 2020 at 10:13 AM Denis <[email-masked]> wrote:

> [Denis] This is quite easy. The final decision is always taken by the RS.
> If a Client presents access tokens issued by ASs trusted by the RS
> However such involvement does not need to be formalized by a protocol. It
> can be application specific.
>
> and ROs. While this should not be prevented for backward compatibility with
> OAuth 2.0,
> GSs is a door half-opened for Big Brother. If in addition the GS is able to
> know which operation
> is attempted by the client on which RSs, then it is a door wide-opened for
> Big Brother.
>
>
>>
> controlling the "User-Agent" is also the person
> controlling the "RO-Agent" and they reside on the same device. These are
> cases where we say User equals RO.
>

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 20 Jul 2020 14:46:48 -0400

Hello Denis,

> There is nothing like a User consent. It is essential for further
discussions to use the correct keywords.

Clarification 1: User vs. RO
1. User interacts with Client
2. RO interacts with GS

Clarification 2: Consent vs. AuthZ (Authorization)
1. Consent is given by RO to GS and used to produce an Authz.
2. AuthZ is given by GS to Client and used by Client to access Resource at
RS interface on behalf of User.

Modified Question: where, when and how the "RO" Consent is captured?

Answer:
how: Consent is given by the RO to the GS.
where: Depend of interaction mode.
when: before step (5).

> [Denis] These two major points are still left unanswered at this time.
I do not understand the question.

> then the operation is allowed.
We should be using GS instead of AS to avoid confusion.

> can be application specific.
Client has no Relationship with the RO.

There is no reference to a human here. User, Client, RS, GS, RO are all
roles. Nothing states the type of participants they are.

> and ROs.
No. Evaluating an AuthZChallenge to discover the RO:
- does not assume GS knows RS.
- does not presume RS knows GS.

But:
- GS will generally have to know RO, as RO delegates the work to produce
authorizations on his behalf to GS.
- RS will generally have to know RO, as RO custodies his Resources with RS
and trusts RS to only release it to authorized parties.

How do you establish a contract without contracting parties knowing each
other?

> While this should not be prevented for backward compatibility with OAuth
> 2.0,
I do not understand this. GS is working for RO.

> giving his consent to himself ?
We do not have people here, but roles.
RO is consenting
  - that the Client can access his Resource
  - on behalf of the User [optional].

So RO and User are different roles, even if they are sometimes assumed by
the same human/device/machine/...

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 20 Jul 2020 14:53:54 -0400

Hello Tom,

> ethernet connection. So i must assume that the user agent is the essence of
No. The User agent is the agent of the User. The RO agent is the agent of
the RO. Off course the word "agent" only appears when the party (RO, User)
assuming a role needs some means of interacting with other parties.

Referring to a User agent does not conclude to the User being a human.

> at least where the RO is a human and the resource contains PII.
What is PII?

> that has data on the web that is (inter alia) PII about them.
Next confusion: RO vs. Subject.

> is used by a real world human that has acquired control of access to the
Next confusion: User vs. Subject

This last sentence looks like the content of a new thread....

---

From: Dick Hardt <[email-masked]>
Date: Mon, 20 Jul 2020 12:10:44 -0700

> how the user consent is captured.

When is covered, per the sequence. How and where are out of scope of what I
drafted.

> How can the GS identify which RO to query ?

If the User is the RO, then the GS knows who to query.

If the RO is a separate entity, then the GS knows the RO from the RS being
queried. An example is a user would like access to an enterprise asset
where a workflow is started to gain approval, and an administrator or
manager provides consent.

> between a GS and a RO is optional.

See enterprise example above.

> *That* User is not the RO of the RS.
The user being the RO is the initial use case for OAuth. A client
application would like access to the user's photos at a photo sharing site.
The resource is the user's photos. The user is the owner of that resource.

ᐧ

---

From: Tom Jones <[email-masked]>
Date: Mon, 20 Jul 2020 12:16:20 -0700

pii = personally identifiable information - it is from the GDPR - i am
not so fond of it myself but it has been used on this list before.
human on internet ==> there exists a user agent.  I never mentioned the
other direction.
RO seems to be used as a real world term.  subject is a digital identifier
which has been used and misused for decades.
i use the word "user" in a different meaning than you - i guess we should
remove the term if there is no common meaning. I detest arguing about the
meaning of words.

Peace ..tom

On Mon, Jul 20, 2020 at 11:54 AM Francis Pouatcha <[email-masked]> wrote:

>> Second there are two terms which need to be distinct in the general case
>> - at least where the RO is a human and the resource contains PII.
>>
> What is PII?
>

---

From: Denis <[email-masked]>
Date: Tue, 21 Jul 2020 14:53:16 +0200

Hello Francis,

> Hello Denis,
>
>>>
>>>             The good news first: we are making some progress. We are
>>>             now close to an agreement with steps (1) up to (3),
>>>             ... except that the place where the user consent is
>>>             captured is not mentioned/indicated.
>>>
>>
>>         This major question which is currently left unanswered is
>>         where, when and how the user consent is captured.
>>

The draft defines a user as "the person interacting with the Client". 
The User consent is the very first property related to privacy principles.
It is mentioned in clause 5.2  "Consent and choice" from ISO 29100. 
Before the release of personal attributes to a RS, the consent of the 
person
holding these personal attributes must  be obtained. Unfortunately, 
since this stage is not mentioned in the draft, it is very unlikely that
implementers will even think to implement it.

> 1. User interacts with Client

No. A RO interacts with its RS. Before any access, the RO defines the 
authorization conditions at the RS.
Once it is done, any client that fulfils these authorization conditions 
will be granted an access.

> 1. Consent is given by RO to GS and used to produce an Authz.

No. There is no need for a RO to interact with a GS.

> 2. AuthZ is given by GS to Client and used by Client to access 
> Resource at RS interface on behalf of User.

Authz is a set of attributes released to a Client in an access token. 
There is no need to have any RO involvement in that process.

>>         Another important point to consider and to explain is related
>>         to the assurances that the user can obtain about

If access tokens are considered to be opaque to the client, then the 
client can verify that the "Consent and choices"
formulated by the user (i.e. person) have indeed been taken into 
consideration. On the contrary, if access tokens are
considered to be opaque to the client, such assurance cannot be obtained 
by the client and hence the user.

>>>         Good question. Perhaps you can expand on a use case where
>>>         that would be useful?
>>
>>         Before I expand, would you be able to explain first under
>>         which circumstances a RO needs to be queried by a GS ?
>>
>     [Denis] This is quite easy. The final decision is always taken by
>     the RS. If a Client presents access tokens issued by ASs trusted
>     by the RS
>     that contain appropriate attributes to perform the requested
>     operation, then the operation is allowed.
>
>     If really a human RO needs to be involved for whatever reason, it
>     is possible to get its involvement when the Client connects to the
>     RS.
>     However such involvement does not need to be formalized by a
>     protocol. It can be application specific.
>
> There is no reference to a human here. User, Client, RS, GS, RO are 
> all roles. Nothing states the type of participants they are.

A user is currently defined as a person. The case of a "client 
application" interacting with the system through a Client
should however also be addressed. Both a user and a client application 
are interacting with the system through a Client.

>>     There is supposed to be a preexisting relationship between GS and
>>     RO, If not RO will have to register with GS in the first
>>     interaction (onboarding).
>>
>>     AuthZRequest(AuthZChallenge) to decide how to contact the RO.
>>     This is where selection of interaction mode takes place.
>
>     [Denis] This means that a GS must have prior relationships with
>     the RSs and ROs.
>

Your position is in contradiction with the response from the editor of 
this draft (Dick) who wrote:

    If the RO is a separate entity, then the GS knows the RO from the RS
    being queried.

In order to discover the RO, the GS must know who the the RS is. 
However, while being necessary, this is insufficient. The GS must
be able to authenticate the RO and to associate it with the RS and there 
is no reason why this information shall necessarily be made
publicly available. Hence, this is why prior relationships between GSs 
and RSs/ROs  are necessary and this makes the whole architecture
complicated whereas it can be quite simple when the RO only interacts 
with its RS.

> - GS will generally have to know RO, as RO delegates the work to 
> produce authorizations on his behalf to GS.
> - RS will generally have to know RO, as RO custodies his Resources 
> with RS and trusts RS to only release it to authorized parties.
>
> How do you establish a contract without contracting parties knowing 
> each other?
>
>     While this should not be prevented for backward compatibility with
>     OAuth 2.0, this should not be the single case.
>     Prior relationships between ROs and GSs is a door half-opened for
>     Big Brother.
>     If in addition the GS is able to know which operation is attempted
>     by the client on which RSs, then it is a door wide-opened for Big
>     Brother.
>

A GS is not "working for" any RO. A GS when receiving an access token 
request does not even know whether it should contact or not a RO.

>>>         Just like how the user authenticates to an AS, how the AS
>>>         and RO communicate is out of scope.
>>
>>         At the moment, the usefulness of a dialogue between a GS and
>>         a RO has not been explained, nor demonstrated.
>>         The question is about the functionality of that dialogue in
>>         terms of input and output information (and not about
>>         the design of a protocol or of a user interface). Anyway,
>>         AFAIU a dialogue between a GS and a RO is optional.
>>
>>>         For many use cases, the User is the RO, and the interaction
>>>         is through a user interface, not a machine protocol.
>>
>>     In some use cases (where we use redirect interaction) we assume
>>     the person controlling the "User-Agent" is also the person
>>     controlling the "RO-Agent" and they reside on the same device.
>>     These are cases where we say User equals RO.
>
>     [Denis] Sorry, I have difficulties to understand such a case. A
>     person giving his consent to himself ?
>
> So RO and User are different roles, even if they are sometimes assumed 
> by the same human/device/machine/...

If, prior to any access, authorization conditions are well defined and 
managed by the RO of the RS, then the RO does not need to be involved
in real time, in particular at the time of an access of a client.

Denis

---

From: Denis <[email-masked]>
Date: Tue, 21 Jul 2020 15:03:30 +0200

Hello Dick,

I duplicate the most important comment at the beginning of this email:

    You are considering using an access control model to build
    a**workflow model.
    **
    While it may be interesting to define a workflow model, this should
    be considered
    as a separate and different work item.

See the other comments between the lines.

> On Mon, Jul 20, 2020 at 2:05 AM Denis <[email-masked] 
> When is covered, per the sequence. How and where are out of scope of 
> what I drafted.

It is clear that the "User consent and choice" is not currently 
addressed in the draft, but it should.
The support of the "User consent and choice" has strong implications not 
only in the sequences of the exchanges
but also by which entity it should be performed.

>     unanswered in draft-hardt-xauth-protocol-13.
This point is equally important: such assurance can only be obtained if 
the access token returned to the client
is not considered to be opaque to the client. This is a necessary 
condition but not the single condition:
the Client must also be in a position to capture/memorize the "User 
consent and choice" of the user in order to be able
to verify it afterwards using the content of the access token(s).

> If the User is the RO, then the GS knows who to query.

I still have difficulties to understand what you mean here.
How could a GS know that "the User is the RO" ?  If "the User is the 
RO", why does the GS needs to query the User ?

> If the RO is a separate entity, then the GS knows the RO from the RS 

  ... and this gives the ability for the GS to log/trace all the RSs 
accessed by a given User and at which instant of time the access token 
has been granted.

> An example is a user would like access to an enterprise asset where a 
> workflow is started to gain approval, and an administrator or manager 
> provides consent.

Thanks for this example. I finally understand what you have in mind: you 
are considering using an access control model to build a *workflow model*.
While it may be interesting to define a workflow model, this should be 
considered as a *separate and different work item*.

The model you propose may be suited for an enterprise environment but is 
not scalable over the Internet.
What is needed is an access control model usable over the Internet with 
millions of RSs and thousands of ASs/GSs.

> See enterprise example above.

It is not an access control example, but a workflow example.

Access  control has been defined a long time ago and the last edition of 
the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
"Information technology — Open Systems Interconnection — Security 
frameworks for open systems: Access control framework — Part 3".

Two major functions have ben defined: an AccessControl Enforcement 
Function (AEF) and an AccessControl Decision Function(ADF).

    AccessControl Enforcement Function (AEF):
    A specialized function that is part of the access path between an
    initiator and a target on each access request and enforces the
    decision made by the ADF.

    AccessControl Decision Function (ADF) :
    A specialized function that makes access control decisions by
    applying access control policy rules to an access request, ADI (of
    initiators, targets, access requests,
    or that retained from prior decisions), and the context in which the
    access request is made.

The role of the RO is to define the "access control policy rules" at the 
RS according to thecontext in which the access request is made.

> The user being the RO is the initial use case for OAuth.

OAuth 2.0 is no more mandating such a case.

> A client application would like access to the user's photos at a photo 
> sharing site. The resource is the user's photos. The user is the owner 
> of that resource.

If the user has already pre established the access control policy rules 
so that it can access to his own photos
then he does not need to grant in real time any additional authorization.

Denis

---

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

comments inserted ...

On Tue, Jul 21, 2020 at 6:03 AM Denis <[email-masked]> wrote:

> You are considering using an access control model to build a workflow
> model.
>
> considered
> When is covered, per the sequence. How and where are out of scope of what
> I drafted.
>
> It is clear that the "User consent and choice" is not currently addressed
> in the draft, but it should.
"consent" is in the latest draft 7 times.

I think the abstract sequence as proposed by Francis is a great addition,
and would clarify where consent is in the sequence.

> to verify it afterwards using the content of the access token(s).

We disagree on this being a requirement for all use cases. It may be in
some.

> How could a GS know that "the User is the RO" ?  If "the User is the RO",
> why does the GS needs to query the User ?
>

To get consent?

> queried.
> accessed by a given User and at which instant of time the access token has
> been granted.
>

The actual workflow is out of scope. if the admin grants access, then the
access granted to the client changes.

> not scalable over the Internet.

It is one of the use cases we are working to address.

> millions of RSs and thousands of ASs/GSs.

I agree the model should also scale to internet scale.

> Two major functions have ben defined: an Access Control Enforcement Function
> (AEF) and an Access Control Decision Function(ADF).
>
> Access Control Enforcement Function (AEF):
> initiator and a target on each access request and enforces the decision
> made by the ADF.
> Access Control Decision Function (ADF) :
> A specialized function that makes access control decisions by applying
> access control policy rules to an access request, ADI (of initiators,
> targets, access requests,
> RS according to the context in which the access request is made.
>
I'm pretty familiar with access control systems. :)

I would say that the access control is happening at the RS. The client
presents a token when accessing an API. The RS uses the token, and any
policy required, to make an access decision.

Here is flow:

1) The Client requests access to an RS from the GS.
2) The GS queries the RS if access should be granted.
3) If access is granted, the GS creates an access token representing the
granted access, and returns it to the Client.
4) The Client presents the access token to the RS to show it has been
granted access.

A couple advantages of this model:
- that the RS does not need to know much, if anything about the Client.
- the access token MAY be self contained so that the Client does not need
to query the GS on each access.

I would not say that GNAP is an access control protocol, as how the RS uses
the token to determine access is out of scope.

> OAuth 2.0 is no more mandating such a case.

I don't know what you mean by that.

> sharing site. The resource is the user's photos. The user is the owner of
> that resource.
>
> If the user has already pre established the access control policy rules so
> that it can access to his own photos

I don't understand what you are trying to say. The photo sharing example
was a driving use case for the creation of OAuth.

/Dick

---

From: Denis <[email-masked]>
Date: Tue, 21 Jul 2020 20:26:36 +0200

Hello Dick,

Thank you for your feedback. Comments are between the lines.

> comments inserted ...
>
> On Tue, Jul 21, 2020 at 6:03 AM Denis <[email-masked] 
>         While it may be interesting to define a workflow model, this
>         should be considered
>>     When is covered, per the sequence. How and where are out of scope
>>     of what I drafted.
>
>     The support of the "User consent and choice" has strong
>     implications not only in the sequences of the exchanges

"Consent" is present 5 times. The User consent is different from the RO 
consent (when/if it is required).

    The server acquires consent and authorization from the user
    *and/**or resource owner **if required.*

    User consent is *often required* at the GS. GNAP enables a Client
    and  GS to negotiate the interaction mode for the GS to obtain consent.

    The GS *may *require explicit consent from the RO or User to provide
    these to the Client.

The User consent is not an alternative to the RO consent. So using 
"and/or" in the first sentence is incorrect.

Since the second sentence is using the wording "often required" there is 
no requirement to get the User consent.

The second sentence does not consider the possibility to get the User 
consent in a place different from the GS.

IMO, the User consent should be captured by the Client, i.e. not by the GS.
The information used to obtain the User consent should be standardized 
(... and it can be standardized).

>
> I think the abstract sequence as proposed by Francis is a great 
> addition, and would clarify where consent is in the sequence.

The current sketch does not illustrate the place the User Consent is 
captured, in particular by the Client.

>     This point is equally important: such assurance can only be
>     obtained if the access token returned to the client
>     the Client must also be in a position to capture/memorize the
>     "User consent and choice" of the user in order to be able
> We disagree on this being a requirement for all use cases. It may be 
> in some.

OK. Then this means that there will be no sentence in the draft such as :
"access tokens returned to the client are not considered to be opaque to 
the client".

>     How could a GS know that "the User is the RO" ?  If "the User is
>     the RO", why does the GS needs to query the User ?
>
>
> To get consent?

To get a "RO consent" to himself ???

>>     If the RO is a separate entity, then the GS knows the RO from the
>>     RS being queried.
>
>      ... and this gives the ability for the GS to log/trace all the
>     RSs accessed by a given User and at which instant of time the
>     access token has been granted.
>
>>     An example is a user would like access to an enterprise asset
>>     where a workflow is started to gain approval, and an
>>     administrator or manager provides consent.
>
>     Thanks for this example. I finally understand what you have in
>     mind: you are considering using an access control model to build a
>     *workflow model*.
>     While it may be interesting to define a workflow model, this
>     should be considered as a *separate and different work item*.
>
>
> The actual workflow is out of scope.

I am glad you agree with this. But this means that your example was not 
appropriate to illustrate your point.

As soon as there is a RO consent obtained at the GS, the major problem 
is that the GS is able to act as Big Brother.
If a RO consent is performed at the RS, then the GS will not know who 
the RS is: it is then unable to act as Big Brother,
even if it would enjoy to play that role.

> if the admin grants access, then the access granted to the client 
> changes.
>
>     The model you propose may be suited for an enterprise environment
>     but is not scalable over the Internet.
>
>     What is needed is an access control model usable over the Internet
>     with millions of RSs and thousands of ASs/GSs.
>

Fine. Another point on which we are in agreement.

The model can scale to the Internet based on the following assumptions:

    The flow starts with the steps (1) to (4) as illustrated by Francis,
    i.e. the flow starts with a contact with a RS.

*+----+  +------+  +---+  +---+  +---+
|User|  |Client|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
   |(1) Service Request     |      |
   |-------->|       |      |      |
   |         |(2) Service Intent   |
   |         |------>|      |      |
   |         |(3) AuthZ Challenge  |
   |         |<------|      |      |
   |         |(4) AuthZ Request    |
   |         |------------->|      |*

The GS/AS does not need to have any prior relationship with ROs and/or RSs.

Furthermore, it is possible to prevent the GS to act as Big Brother when 
the identity of the RS is not disclosed to the GS.

>     Access  control has been defined a long time ago and the last
>     edition of the model has been confirmed in year 1996:
>     ISO/IEC 10181-3: 1996.
>         A specialized function that is part of the access path between
>         an initiator and a target on each access request and enforces
>         the decision made by the ADF.
>
>         applying access control policy rules to an access request, ADI
>         (of initiators, targets, access requests,
>         or that retained from prior decisions), and the context in
>         which the access request is made.
>
>     The role of the RO is to define the "access control policy rules"
>     at the RS according to thecontext in which the access request is made.
>
> presents a token when accessing an API.
> The RS uses the token, and any policy required, to make an access 
> decision.

Fine. It looks like we are in agreement. Unfortunately, this is not the 
case just below.

> 1) The Client requests access to an RS from the GS.

No. We are no more in agreement. This is different from the flow drawn 
by Francis.

> 2) The GS queries the RS if access should be granted.

  No. The GS should not be forced to have a flow with the RS.

> 3) If access is granted, the GS creates an access token representing 
> the granted access, and returns it to the Client.

This model is by no way conformant to ISO/IEC 10181-3: 1996

> 4) The Client presents the access token to the RS to show it has been 

No. The client presents a token when accessing an API. The RS uses the 
token, and any policy required, to make an access decision.
The token never contains an information like "Please grant an access to 
the holder of this token".

> - the access token MAY be self contained so that the Client does not 
> need to query the GS on each access.

There are so many disadvantages that I will not list them.

> I would not say that GNAP is an access control protocol, as how the RS 
> uses the token to determine access is out of scope.

This is where we have a major discrepancy: how the RS uses the token to 
determine access is *within* the scope.

The RS announces in advance to the client what it needs so that the 
client can perform a a given operation and if the client supplies the 
requested attributes
obtained from some GS/AS(s) trusted by the RS, then access to that RS is 
granted by the RS. If the RS cannot perform the requested operation on 
its own,
then the client should be informed about some requested attributes that 
need to be obtained from some GS/AS(s) trusted by the next RS(s) in a chain
for subsequent operations. The User consent should also be obtained 
before performing the chaining operation.

Chaining operations between RSs over the Internet is within the scope 
(... and may be achieved).

> I don't know what you mean by that.

Copy and paste from draft-ietf-oauth-security-topics:

    OAuth initially assumed a static relationship between client,
    authorization server and resource servers.  (...)
    With the increasing adoption of OAuth, this simple model dissolved
    and, in several scenarios, was replaced
    by a dynamic establishment of the relationship between clients on
    one side and the authorization and
    resource servers of a particular deployment on the other side.

    This way, the same client could be used to access services of
    different providers (in case of standard APIs,
    such as e-mail or OpenID Connect) or serve as a frontend to a
    particular tenant in a multi-tenancy environment.

>>     A client application would like access to the user's photos at a
>>     photo sharing site. The resource is the user's photos. The user
>>     is the owner of that resource.
>
>     If the user has already pre established the access control policy
>     rules so that it can access to his own photos
> I don't understand what you are trying to say. The photo sharing 
> example was a driving use case for the creation of OAuth.

We would need to revisit the original scenario and consider if it can be 
addressed in a different way than the original way.

Denis

---

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

On Tue, Jul 21, 2020 at 11:26 AM Denis <[email-masked]> wrote:

>>>> The good news first: we are making some progress. We are now close to
>>>> an agreement with steps (1) up to (3),
> The server acquires consent and authorization from the user *and/**or
> resource owner **if required.*
>
> User consent is *often required* at the GS. GNAP enables a Client and  GS
> to negotiate the interaction mode for the GS to obtain consent.
>

My language is sloppy there. Consent is always from the RO. The User may be
the RO.

> no requirement to get the User consent.

User consent may not be required. There may not be a User. The consent may
have been gathered previously.

> consent in a place different from the GS.

Agreed. But we do agree that the GS gets the consent, either directly from
the RO, or from the Client (in your example)

> captured, in particular by the Client.

It is an abstraction. The GS receives the consent. How consent is gathered
is a detail that is dependent on the use case.

> "access tokens returned to the client are not considered to be opaque to

For OAuth use cases, which GNAP supports, the access token is opaque to the
Client. As you have noted, there are use cases where the access token is
NOT opaque.

> To get a "RO consent" to himself ???

The GS needs consent from the RO. If the RO is the User, then consent from
the RO is equivalent to consent from the User.

> appropriate to illustrate your point.

It illustrates a use case where the RO and User are not the same party, and
why the GS needs to query the RO, which was your question if I understood
it correctly.

>
> As soon as there is a RO consent obtained at the GS, the major problem is
> that the GS is able to act as Big Brother.
> If a RO consent is performed at the RS, then the GS will not know who the
> RS is: it is then unable to act as Big Brother,

In an enterprise use case, the GS's knowledge of who is accessing which RS
is a feature.

In your use cases, it seems that the RO is the User. The GS knows the User
is wanting to let a Client access something. If the access token is
generic, and could be presented to any RS that provides a standardized
function, then the GS does not know which RS is being accessed by a Client
for the User. This seems to meet your privacy objectives. If not, what is
wrong?

> if the admin grants access, then the access granted to the client changes.
>
> The flow starts with the steps (1) to (4) as illustrated by Francis, i.e.
> the flow starts with a contact with a RS.
>
>
>
>
>
>
>
>
>
>
>
> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS |  |RO
> | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request     |      |
>   |-------->|       |      |      |   |         |(2) Service Intent   |   |
>         |------>|      |      |   |         |(3) AuthZ Challenge  |   |
>     |<------|      |      |   |         |(4) AuthZ Request    |   |
> |------------->|      |*
>

What happens after (4) above?

> The RS uses the token, and any policy required, to make an access decision.
>
> No. We are no more in agreement. This is different from the flow drawn by
> Francis.
>

My bad. Typo. I meant RO.

>  No. The GS should not be forced to have a flow with the RS.

Same mistake as above, I meant RO.

> This model is by no way conformant to ISO/IEC 10181-3: 1996
I'm unclear on why, or why it is even relevant.

> the holder of this token".
Let me provide more clarity in the sentence:

The Client presents the access token to the RS, to show the RS that the
Client has been granted access to a resource at the RS by the GS.

> There are so many disadvantages that I will not list them.
Darn: I clearly was not firing on all cylinders when I typed this out. Let
me correct:

- the access token MAY be self contained so that the RS does not need to
query the GS on each access to the RS by the Client.

> The RS announces in advance to the client what it needs so that the client
> can perform a a given operation and if the client supplies the requested
> attributes
> granted by the RS. If the RS cannot perform the requested operation on its
> own,
> for subsequent operations. The User consent should also be obtained before
> performing the chaining operation.
>
> Chaining operations between RSs over the Internet is within the scope (...
> and may be achieved).
>
>
>>
> With the increasing adoption of OAuth, this simple model dissolved and, in
> several scenarios, was replaced
> by a dynamic establishment of the relationship between clients on one side
> and the authorization and
> This way, the same client could be used to access services of different
> providers (in case of standard APIs,
> such as e-mail or OpenID Connect) or serve as a frontend to a particular
> tenant in a multi-tenancy environment.
>
>
This sentence does not mention the RO or the Client. I'm confused what we
are talking about

> addressed in a different way than the original way.
The use case is the same. Is there a different solution you are proposing?

---

From: Denis <[email-masked]>
Date: Wed, 22 Jul 2020 18:34:36 +0200

Hello Dick,

I have identified the reason of the major difference between our two 
approaches.

Access control may be performed using either ACLs (Access Control Lists) 
or Capabilities.

_Note _: a capability identifies a resource and an allowed operation 
that can be performed on that resource.

You are advocating a Capabilities approach while I am advocating an ACL 
approach.

The capabilities approach allows the GS to trace every operation 
performed by the users on any RS known by a GS.
The management of these capabilities is made via the GS or at the GS by 
the various ROs. If the management is made
via the GS, then a trusted communication channel needs to be established 
with every RO. If the management is made
at the GS, then an authentication mechanism needs to be established with 
every RO. In the last case, the GS has the
ability to know all the capabilities of the users whether they are used 
or not. The less that can be said is that this model
is not privacy friendly.

With the ACL approach, a RO directly manages an ACL placed in front of 
each RS. The AccessControl Decision Function
(ADF) at the RS is able to keep track from prior decisions. The GS is 
kept ignorant of the content of these ACLs and only
delivers to its clients attributes that are placed into access tokens. 
Such a model may be privacy friendly.

Other comments are between the lines prefixed with [Denis].

>
> On Tue, Jul 21, 2020 at 11:26 AM Denis <[email-masked] 
>>             You are considering using an access control model to
>>             build a**workflow model.
>>             **
>>             While it may be interesting to define a workflow model,
>>             this should be considered
>>>>             On Fri, Jul 17, 2020 at 9:21 AM Denis
>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>                 Hello Francis and Dick,
>>>>
>>>>                 The good news first: we are making some progress.
>>>>                 We are now close to an agreement with steps (1) up
>>>>                 to (3),
>>>             This major question which is currently left unanswered
>>>             is where, when and how the user consent is captured.
>>>
>>>
>>>         When is covered, per the sequence. How and where are out of
>>>         scope of what I drafted.
>>
>>         It is clear that the "User consent and choice" is not
>>         currently addressed in the draft, but it should.
>     "Consent" is present 5 times. The User consent is different from
>     the RO consent (when/if it is required).
>
>         User consent is *often required* at the GS. GNAP enables a
>         Client and  GS to negotiate the interaction mode for the GS to
>         obtain consent.
>
>         The GS *may *require explicit consent from the RO or User to
>         provide these to the Client.
>
> My language is sloppy there. Consent is always from the RO. The User 
> may be the RO.

[Denis] No. Once again: The "/User consent/" is different from what you 
call the "/RO consent/" (when/if it is required).
The "RO consent" is not in fact a consent but the release of a 
capability to a client by one of the many R0s with which
the GS has relationships.

>     Since the second sentence is using the wording "often required"
>     there is no requirement to get the User consent.
>
> User consent may not be required. There may not be a User. The consent 
> may have been gathered previously.

[Denis] In order to follow the privacy principles, a "User consent" 
phase is required. The User is a natural person.
A Client is called either by a User (i.e. a natural person) or by a 
Client application.

>     The second sentence does not consider the possibility to get the
>     User consent in a place different from the GS.
>
> Agreed. But we do agree that the GS gets the consent, either directly 
> from the RO, or from the Client (in your example).

[Denis] No. I disagree. In an ACL based systems, the GS does not need to 
ask or receive any consent.
The client selects the set of attributes that it wants to be inserted 
into an access token.
If the GS has the requested attributes, then it provides them, otherwise 
it returns an error to the Client.

>     The information used to obtain the User consent should be
>     standardized (... and it can be standardized).
>
>     The current sketch does not illustrate the place the User Consent
>     is captured, in particular by the Client.
>
> It is an abstraction. The GS receives the consent. How consent is 
> gathered is a detail that is dependent on the use case.

[Denis] I really wonder whether there is really a "consent" to be 
received by the GS in both cases (i.e. ACLs or Capabilities).

  * For ACLs, the consent needs to be done by the Client.
  * For Capabilities, the current description is not clear since the
    inputs and the outputs for this "consent" phase
    are not currently described in the draft.

>>>             Another important point to consider and to explain is
>>>             related to the assurances that the user can obtain about
>>         is not considered to be opaque to the client. This is a
>>         necessary condition but not the single condition:
>>     We disagree on this being a requirement for all use cases. It may
>>     be in some.
>
>     "access tokens returned to the client are not considered to be
>     opaque to the client".
>
>
> For OAuth use cases, which GNAP supports, the access token is opaque 
> to the Client. As you have noted, there are use cases where the access 
> token is NOT opaque.

[Denis] Wait a second. There is no requirement to support all OAuth use 
cases.
I believe that there is a requirement to support OAuth 2.0 ASs, while 
the clients may be different
and hence GNAP clients do not need to inherit of the limitations of 
OAuth 2.0 clients.

>>>
>>>>                 If a RO needs to be involved and since a RO is
>>>>                 directly associated with a RS, why can't it be
>>>>                 directly queried
>>>>             Good question. Perhaps you can expand on a use case
>>>>             where that would be useful?
>>>
>>>             Before I expand, would you be able to explain first
>>>             under which circumstances a RO needs to be queried by a GS ?
>>         How could a GS know that "the User is the RO" ?  If "the User
>>         is the RO", why does the GS needs to query the User ?
>>
>>
>>     To get consent?
>
> The GS needs consent from the RO. If the RO is the User, then consent 
> from the RO is equivalent to consent from the User.

[Denis] See above.

>
>>>         If the RO is a separate entity, then the GS knows the RO
>>>         from the RS being queried.
>>
>>          ... and this gives the ability for the GS to log/trace all
>>         the RSs accessed by a given User and at which instant of time
>>         the access token has been granted.
>>
>>>         An example is a user would like access to an enterprise
>>>         asset where a workflow is started to gain approval, and an
>>         Thanks for this example. I finally understand what you have
>>         in mind: you are considering using an access control model to
>>         build a *workflow model*.
>     I am glad you agree with this. But this means that your example
>     was not appropriate to illustrate your point.
>
>
> It illustrates a use case where the RO and User are not the same 
> party, and why the GS needs to query the RO, which was your question 
> if I understood it correctly.

[Denis] Since the inputs and the outputs for this "RO consent" phase are 
not currently described in the draft, the point is still unsolved.

>     As soon as there is a RO consent obtained at the GS, the major
>     problem is that the GS is able to act as Big Brother.
>     If a RO consent is performed at the RS, then the GS will not know
>     who the RS is: it is then unable to act as Big Brother,
> In an enterprise use case, the GS's knowledge of who is accessing 
> which RS is a feature.

Do you mean that it is "normal" in an enterprise that a single point of 
control is able to trace all their actions ?
 From a security point of view, a single point of failure will have 
dramatic consequences.

> In your use cases, it seems that the RO is the User.

I do hope that you have finally understood that, in my use case, the RO 
is **not** the User.

> The GS knows the User is wanting to let a Client access something. If 
> the access token is generic, and could be presented to any RS that 
> provides a standardized function,
> then the GS does not know which RS is being accessed by a Client for 
> the User. This seems to meet your privacy objectives. If not, what is 
> wrong?

For security reasons, an access token needs to be targeted (which does 
not necessarily mean that an identifier of the RS shall be included into 
the access token).

>>         The model you propose may be suited for an enterprise
>>         environment but is not scalable over the Internet.
>>
>>         What is needed is an access control model usable over the
>>         Internet with millions of RSs and thousands of ASs/GSs.
>>
>         The flow starts with the steps (1) to (4) as illustrated by
>         Francis, i.e. the flow starts with a contact with a RS.
>
>     Furthermore, it is possible to prevent the GS to act as Big
>     Brother when the identity of the RS is not disclosed to the GS.
>
>

[Denis] The key point is that we first need to agree on the first four 
exchanges. Do we ?

The fifth exchange is different whether ACLs or Capabilities are being used.

>>>>             Just like how the user authenticates to an AS, how the
>>>>             AS and RO communicate is out of scope.
>>>
>>>             At the moment, the usefulness of a dialogue between a GS
>>>             and a RO has not been explained, nor demonstrated.
>>>             The question is about the functionality of that dialogue
>>>             in terms of input and output information (and not about
>>>             the design of a protocol or of a user interface).
>>>             Anyway, AFAIU a dialogue between a GS and a RO is optional.
>>>
>>>
>>         "Information technology — Open Systems Interconnection —
>>         Security frameworks for open systems: Access control
>>         framework — Part 3".
>>
>>         Two major functions have ben defined: an AccessControl
>>         Enforcement Function (AEF) and an AccessControl Decision
>>         Function(ADF).
>>
>>             A specialized function that is part of the access path
>>             between an initiator and a target on each access request
>>             and enforces the decision made by the ADF.
>>
>>             A specialized function that makes access control
>>             decisions by applying access control policy rules to an
>>             access request, ADI (of initiators, targets, access
>>             requests,
>>             or that retained from prior decisions), and the context
>>             in which the access request is made.
>>
>>         The role of the RO is to define the "access control policy
>>         rules" at the RS according to thecontext in which the access
>>         request is made.
>>
>>     I would say that the access control is happening at the RS. The
>>     client presents a token when accessing an API.
>     Fine. It looks like we are in agreement. Unfortunately, this is
>     not the case just below.
>
>>     Here is flow:
>>
>     No. We are no more in agreement. This is different from the flow
>     drawn by Francis.
>
>>     3) If access is granted, the GS creates an access token
>>     representing the granted access, and returns it to the Client.
>
>>     4) The Client presents the access token to the RS to show it has
>>     been granted access.
>
>     No. The client presents a token when accessing an API. The RS uses
>     the token, and any policy required, to make an access decision.
>     The token never contains an information like "Please grant an
>     access to the holder of this token".
>
> The Client presents the access token to the RS, to show the RS that 
> the Client has been granted access to a resource at the RS by the GS.

[Denis] This time, please consider both the ACLs approach and the 
Capabilities approach.

>>     - the access token MAY be self contained so that the Client does
>>     not need to query the GS on each access.
>
> Darn: I clearly was not firing on all cylinders when I typed this out. 
> Let me correct:
>
>> - the access token MAY be self contained so that the RS does not need 
>> to query the GS on each access to the RS by the Client.

[Denis] A few comments in the case of a capability approach:

    - for each GS, the RS needs to locally manage which operation(s)
    is/are allowed to it.

    - the GS needs to establish a trusted communication channel or an
    authentication mechanism with each RO
        (which is associated with an explicit RS identifier).

    - the GS could play the role of the RO and hence be in a position to
    issue any capability for any RS (without a "RO consent").

        The target of an attack will clearly be the GS.

>>     I would not say that GNAP is an access control protocol, as how
>>     the RS uses the token to determine access is out of scope.
>
>     This is where we have a major discrepancy: how the RS uses the
>     token to determine access is *within* the scope.
>
[Denis] Do you agree or disagree ?
>
>     The RS announces in advance to the client what it needs so that
>     the client can perform a a given operation and if the client
>     supplies the requested attributes
>     obtained from some GS/AS(s) trusted by the RS, then access to that
>     RS is granted by the RS. If the RS cannot perform the requested
>     operation on its own,
>     then the client should be informed about some requested attributes
>     that need to be obtained from some GS/AS(s) trusted by the next
>     RS(s) in a chain
>     for subsequent operations. The User consent should also be
>     obtained before performing the chaining operation.
>
>     Chaining operations between RSs over the Internet is within the
>     scope (... and may be achieved).
>
[Denis] Do you agree or disagree ?

Denis

>>>>             For many use cases, the User is the RO, and the
>>>>             interaction is through a user interface, not a machine
>>>>             protocol.
>>>
>>>             Wait a second. You wrote "the User is the RO". The User
>>>             is attempting to make an access to a RS by using a Client.
>         With the increasing adoption of OAuth, this simple model
>         dissolved and, in several scenarios, was replaced
>         by a dynamic establishment of the relationship between clients
>         on one side and the authorization and
> This sentence does not mention the RO or the Client. I'm confused what 
> we are talking about
>
>>>         A client application would like access to the user's photos
>>>         at a photo sharing site. The resource is the user's photos.
>>>         The user is the owner of that resource.
>>
>>         If the user has already pre established the access control
>>         policy rules so that it can access to his own photos
>     We would need to revisit the original scenario and consider if it
>     can be addressed in a different way than the original way.
>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 23 Jul 2020 02:51:07 +0200

Hi Denis,

I won't answer to most of your thread, as it is addressed to Dick.

However I'm puzzled by your comment, I think you're misunderstanding what
capabilities are about. As I understand it, this is due to the desire to
align your proposal with xauth/xyz, while a significant difference remains:
the agency model is different (and this reflects in the terminology work
started by Francis, which mandates some behaviour from the GS, which is
quite classical but that you don't agree with). But this has really nothing
to do with either capabilities or ACLs.

Most of existing access control systems are based on ACLs. This includes RS
protection endpoints with role based access, which is a very typical setup.
There's a practical reason why that is: with ACLs people tend to think
about who (individual or group) is making what action, and that is a simple
model to implement (albeit quite hard to maintain). There are downsides to
that approach both in terms of security (e.g. doesn't implement POLA) and
privacy that are well documented.

In no occurrence a capability system mandates that you trace anything,
quite the opposite actually. Capability systems work without a reference to
the user  identity, instead it works based on what the user proves it is
holding (such as a token). And therefore the privacy model is stronger (not
linked to an identity by default, although it probably will be at some
point in practice) and it allows properties which cannot be implemented
through ACLs, such as delegation (without the need of a third party such as
a GS). A downside is that it requires a more granular approach to rights
management (typical solutions for this include membranes) and traceability
can be challenging (see for instance Hortons "who's done it" for one
approach to this issue).

Fabien

Le mer. 22 juil. 2020 à 18:34, Denis <[email-masked]> a écrit :

> *Note *: a capability identifies a resource and an allowed operation that
> can be performed on that resource.
>
> The capabilities approach allows the GS to trace every operation performed
> by the users on any RS known by a GS.
> ability to know all the capabilities of the users whether they are used or
> not. The less that can be said is that this model
> is not privacy friendly.
>
> each RS. The Access Control Decision Function
>> User consent is *often required* at the GS. GNAP enables a Client and
>> GS to negotiate the interaction mode for the GS to obtain consent.
>>
> My language is sloppy there. Consent is always from the RO. The User may
> be the RO.
>
> [Denis] No. Once again: The "*User consent*" is different from what you
> call the "*RO consent*" (when/if it is required).
> The "RO consent" is not in fact a consent but the release of a capability
> to a client by one of the many R0s with which
> [Denis] In order to follow the privacy principles, a "User consent" phase
> is required. The User is a natural person.
> A Client is called either by a User (i.e. a natural person) or by a Client
> application.
>
> the RO, or from the Client (in your example).
>
> The client selects the set of attributes that it wants to be inserted into
> an access token.
> [Denis] I really wonder whether there is really a "consent" to be received
> by the GS in both cases (i.e. ACLs or Capabilities).
>
>    - For ACLs, the consent needs to be done by the Client.
>    - For Capabilities, the current description is not clear since the
> For OAuth use cases, which GNAP supports, the access token is opaque to
> the Client. As you have noted, there are use cases where the access token
> is NOT opaque.
>
> I believe that there is a requirement to support OAuth 2.0 ASs, while the
> clients may be different
> and hence GNAP clients do not need to inherit of the limitations of OAuth
> 2.0 clients.
>
>
>
>>
>>
>>>
> It illustrates a use case where the RO and User are not the same party,
> and why the GS needs to query the RO, which was your question if I
> understood it correctly.
>
> I do hope that you have finally understood that, in my use case, the RO is
> **not** the User.
>
> The GS knows the User is wanting to let a Client access something. If the
> access token is generic, and could be presented to any RS that provides a
> standardized function,
> then the GS does not know which RS is being accessed by a Client for the
> User. This seems to meet your privacy objectives. If not, what is wrong?
>
> For security reasons, an access token needs to be targeted (which does not
> necessarily mean that an identifier of the RS shall be included into the
> access token).
>
>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS |
>>  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request     |
>>    |   |-------->|       |      |      |   |         |(2) Service Intent
>> |   |         |------>|      |      |   |         |(3) AuthZ Challenge  |
>> |         |<------|      |      |   |         |(4) AuthZ Request    |   |
>>       |------------->|      |*
>>
>>> The role of the RO is to define the "access control policy rules" at
>>> the RS according to the context in which the access request is made.
>>>
> - for each GS, the RS needs to locally manage which operation(s) is/are
> allowed to it.
>
> - the GS could play the role of the RO and hence be in a position to issue
> any capability for any RS (without a "RO consent").
>
>>>> Wait a second. You wrote "the User is the RO". The User is attempting
>>>> to make an access to a RS by using a Client.
>> With the increasing adoption of OAuth, this simple model dissolved and,
>> in several scenarios, was replaced
>> by a dynamic establishment of the relationship between clients on one
>> side and the authorization and

---

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

Hi Denis

I think it would be useful to take a step back and for you to describe your
use case. After that, we can explore the different ways that your use case
can be addressed.

Looking at your previous communication, it describes the solution, and the
justification, but it is not clear what use cases you are needing to solve.

/Dick

ᐧ

---

From: Denis <[email-masked]>
Date: Fri, 24 Jul 2020 18:07:58 +0200

Hi Dick,

draft-hardt-xauth-protocol-13 describes a solution without clearly 
stating what the problem(s) to be solved is/are.

At the moment, draft-hardt-xauth-protocol-13 includes a single figure on 
page 4 and from previous discussions I understood that
it is no more up-to-date since the first data flow is now a contact with 
a RS. The reason(s) for the GS to contact a RO has still not
been explained (since the inputs and outputs are not described). The 
discovery information made available at various steps at the RS
is not described.

Figure 4 shows only a single RS. Is the relaying of one operation by 
that RS to a second RS in the scope of this document ?
If yes, how is it handled ?

Figure 4 shows only a single GS. How would be the data flow when access 
tokens from two GSs are needed by a RS ?

What we need first is not a set of "use cases" but a clear model with a 
data flows and a list of its properties/characteristics.
Then after, we can understand much better which use cases can/will be 
supported. For example, shall a RS (or its RO) have
prior relationships with the GS ? What is the difference/implications 
when it has or it hasn't ?

In order to have a fair comparison, we should try to list model 
properties/characteristics.

At the moment, the model I have described including the data flows is 
clear. The discovery information made available by a RS is clear.
I have not listed all its properties/characteristics of that model, but 
I am pretty sure that you already have a flavour of it.

In the mean time, it would be nice if you could show using two figures:

  * the case of the relaying of one operation by one RS to a second RS
    (if it is in the scope of your document),
  * the case where access tokens from two GSs are needed by one RS (if
    it is in the scope of your document).

Denis

> Hi Denis
>
> I think it would be useful to take a step back and for you to describe 
> your use case.
> After that, we can explore the different ways that your use case can 
> be addressed.
>
> Looking at your previous communication, it describes the solution, and 
> the justification,
> but it is not clear what use cases you are needing to solve.
>
> /Dick
>
>
> ᐧ
>
> On Wed, Jul 22, 2020 at 9:34 AM Denis <[email-masked] 
>     I have identified the reason of the major difference between our
>     two approaches.
>
>     Access control may be performed using either ACLs (Access Control
>     Lists) or Capabilities.
>
>     _Note _: a capability identifies a resource and an allowed
>     operation that can be performed on that resource.
>
>     You are advocating a Capabilities approach while I am advocating
>     an ACL approach.
>
>     The management of these capabilities is made via the GS or at the
>     GS by the various ROs. If the management is made
>     via the GS, then a trusted communication channel needs to be
>     established with every RO. If the management is made
>     at the GS, then an authentication mechanism needs to be
>     established with every RO. In the last case, the GS has the
>     ability to know all the capabilities of the users whether they are
>     used or not. The less that can be said is that this model
>     is not privacy friendly.
>
>     With the ACL approach, a RO directly manages an ACL placed in
>     front of each RS. The AccessControl Decision Function
>     (ADF) at the RS is able to keep track from prior decisions. The GS
>     is kept ignorant of the content of these ACLs and only
>     delivers to its clients attributes that are placed into access
>     tokens. Such a model may be privacy friendly.
>
>>>                 While it may be interesting to define a workflow
>>>                 model, this should be considered
>>>>             On Mon, Jul 20, 2020 at 2:05 AM Denis
>>>>>                     The good news first: we are making some
>>>>>                     progress. We are now close to an agreement
>>>>>                     with steps (1) up to (3),
>>>>>                     ... except that the place where the user
>>>>>                     consent is captured is not mentioned/indicated.
>>>>>
>>>>
>>>>                 This major question which is currently left
>>>>                 unanswered is where, when and how the user consent
>>>>                 is captured.
>>>>
>>>>
>>>>             When is covered, per the sequence. How and where are
>>>>             out of scope of what I drafted.
>>>
>>         "Consent" is present 5 times. The User consent is different
>>         from the RO consent (when/if it is required).
>>
>>             The server acquires consent and authorization from the
>>             user *and/**or resource owner **if required.*
>>
>>             User consent is *often required* at the GS. GNAP enables
>>             a Client and  GS to negotiate the interaction mode for
>>             the GS to obtain consent.
>>
>>             The GS *may *require explicit consent from the RO or User
>>             to provide these to the Client.
>>
>>         The User consent is not an alternative to the RO consent. So
>>         using "and/or" in the first sentence is incorrect.
>>
>>
>>     My language is sloppy there. Consent is always from the RO. The
>>     User may be the RO.
>
>     [Denis] No. Once again: The "/User consent/" is different from
>     what you call the "/RO consent/" (when/if it is required).
>>         Since the second sentence is using the wording "often
>>         required" there is no requirement to get the User consent.
>>
>>     User consent may not be required. There may not be a User. The
>>     consent may have been gathered previously.
>
>     [Denis] In order to follow the privacy principles, a "User
>     consent" phase is required. The User is a natural person.
>     A Client is called either by a User (i.e. a natural person) or by
>     a Client application.
>
>>         The second sentence does not consider the possibility to get
>>         the User consent in a place different from the GS.
>>
>>     Agreed. But we do agree that the GS gets the consent, either
>>     directly from the RO, or from the Client (in your example).
>
>     [Denis] No. I disagree. In an ACL based systems, the GS does not
>     need to ask or receive any consent.
>     The client selects the set of attributes that it wants to be
>     inserted into an access token.
>     If the GS has the requested attributes, then it provides them,
>     otherwise it returns an error to the Client.
>
>>>         I think the abstract sequence as proposed by Francis is a
>>>         great addition, and would clarify where consent is in the
>>>         sequence.
>>
>>         The current sketch does not illustrate the place the User
>>         Consent is captured, in particular by the Client.
>>
>       * For Capabilities, the current description is not clear since
>         the inputs and the outputs for this "consent" phase
>>>>                 Another important point to consider and to explain
>>>>                 is related to the assurances that the user can
>>>>                 obtain about
>>>>                 the respect of his choices. This point is currently
>>>>                 left unanswered in draft-hardt-xauth-protocol-13.
>>>>
>>>             This point is equally important: such assurance can only
>>>             be obtained if the access token returned to the client
>>>             the Client must also be in a position to
>>>             capture/memorize the "User consent and choice" of the
>>>             user in order to be able
>>>         We disagree on this being a requirement for all use cases.
>>>         It may be in some.
>>
>>         "access tokens returned to the client are not considered to
>>         be opaque to the client".
>>
>>
>>     For OAuth use cases, which GNAP supports, the access token is
>>     opaque to the Client. As you have noted, there are use cases
>>     where the access token is NOT opaque.
>
>     [Denis] Wait a second. There is no requirement to support all
>     OAuth use cases.
>     I believe that there is a requirement to support OAuth 2.0 ASs,
>     while the clients may be different
>     and hence GNAP clients do not need to inherit of the limitations
>     of OAuth 2.0 clients.
>
>>>>
>>>>>                 Good question. Perhaps you can expand on a use
>>>>>                 case where that would be useful?
>>>>
>>>             How could a GS know that "the User is the RO" ?  If "the
>>>             User is the RO", why does the GS needs to query the User ?
>>>
>>>
>>>         To get consent?
>>
>>     The GS needs consent from the RO. If the RO is the User, then
>>     consent from the RO is equivalent to consent from the User.
>
>     [Denis] See above.
>
>>
>>>>             If the RO is a separate entity, then the GS knows the
>>>>             RO from the RS being queried.
>>>
>>>              ... and this gives the ability for the GS to log/trace
>>>             all the RSs accessed by a given User and at which
>>>             instant of time the access token has been granted.
>>>
>>>>             asset where a workflow is started to gain approval, and
>>>>             an administrator or manager provides consent.
>>>
>>>             Thanks for this example. I finally understand what you
>>>             have in mind: you are considering using an access
>>>             control model to build a *workflow model*.
>>>             this should be considered as a *separate and different
>>>             work item*.
>>>
>>>
>>         I am glad you agree with this. But this means that your
>>         example was not appropriate to illustrate your point.
>>
>>
>>     party, and why the GS needs to query the RO, which was your
>>     question if I understood it correctly.
>
>     [Denis] Since the inputs and the outputs for this "RO consent"
>     phase are not currently described in the draft, the point is still
>     unsolved.
>
>>         As soon as there is a RO consent obtained at the GS, the
>>         major problem is that the GS is able to act as Big Brother.
>>         If a RO consent is performed at the RS, then the GS will not
>>         know who the RS is: it is then unable to act as Big Brother,
>     Do you mean that it is "normal" in an enterprise that a single
>     point of control is able to trace all their actions ?
>     I do hope that you have finally understood that, in my use case,
>     the RO is **not** the User.
>
>>     The GS knows the User is wanting to let a Client access
>>     something. If the access token is generic, and could be presented
>>     to any RS that provides a standardized function,
>>     then the GS does not know which RS is being accessed by a Client
>>     for the User. This seems to meet your privacy objectives. If not,
>>     what is wrong?
>
>     For security reasons, an access token needs to be targeted (which
>     does not necessarily mean that an identifier of the RS shall be
>     included into the access token).
>
>>>             What is needed is an access control model usable over
>>>             the Internet with millions of RSs and thousands of ASs/GSs.
>>>
>>             The flow starts with the steps (1) to (4) as illustrated
>>             by Francis, i.e. the flow starts with a contact with a RS.
>>
>     [Denis] The key point is that we first need to agree on the first
>     four exchanges. Do we ?
>
>>>>>                 Just like how the user authenticates to an AS, how
>>>>>                 the AS and RO communicate is out of scope.
>>>>
>>>>                 At the moment, the usefulness of a dialogue between
>>>>                 a GS and a RO has not been explained, nor demonstrated.
>>>>                 The question is about the functionality of that
>>>>                 dialogue in terms of input and output information
>>>>                 (and not about
>>>             Access  control has been defined a long time ago and the
>>>             last edition of the model has been confirmed in year
>>>             1996: ISO/IEC 10181-3: 1996.
>>>                 A specialized function that is part of the access
>>>                 path between an initiator and a target on each
>>>                 access request and enforces the decision made by the
>>>                 ADF.
>>>
>>>                 decisions by applying access control policy rules to
>>>                 an access request, ADI (of initiators, targets,
>>>                 access requests,
>>>                 or that retained from prior decisions), and the
>>>                 context in which the access request is made.
>>>
>>>             The role of the RO is to define the "access control
>>>             policy rules" at the RS according to thecontext in which
>>>             the access request is made.
>>>
>>>         I would say that the access control is happening at the RS.
>>>         The client presents a token when accessing an API.
>>         Fine. It looks like we are in agreement. Unfortunately, this
>>         is not the case just below.
>>
>>>         Here is flow:
>>>
>>         No. We are no more in agreement. This is different from the
>>         flow drawn by Francis.
>>
>>>         4) The Client presents the access token to the RS to show it
>>>         has been granted access.
>>
>>         No. The client presents a token when accessing an API. The RS
>>         uses the token, and any policy required, to make an access
>>         decision.
>>     The Client presents the access token to the RS, to show the RS
>>     that the Client has been granted access to a resource at the RS
>>     by the GS.
>
>>>         - the access token MAY be self contained so that the Client
>>>         does not need to query the GS on each access.
>>
>>     Darn: I clearly was not firing on all cylinders when I typed this
>>     out. Let me correct:
>>
>>>     - the access token MAY be self contained so that the RS does not
>>>     need to query the GS on each access to the RS by the Client.
>
>         - for each GS, the RS needs to locally manage which
>         operation(s) is/are allowed to it.
>
>         - the GS needs to establish a trusted communication channel or
>         an authentication mechanism with each RO
>         - the GS could play the role of the RO and hence be in a
>         position to issue any capability for any RS (without a "RO
>         consent").
>
>>>         I would not say that GNAP is an access control protocol, as
>>>         how the RS uses the token to determine access is out of scope.
>>
>>         This is where we have a major discrepancy: how the RS uses
>>         the token to determine access is *within* the scope.
>>
>>         The RS announces in advance to the client what it needs so
>>         that the client can perform a a given operation and if the
>>         client supplies the requested attributes
>>         obtained from some GS/AS(s) trusted by the RS, then access to
>>         that RS is granted by the RS. If the RS cannot perform the
>>         requested operation on its own,
>>         then the client should be informed about some requested
>>         attributes that need to be obtained from some GS/AS(s)
>>         trusted by the next RS(s) in a chain
>>         Chaining operations between RSs over the Internet is within
>>         the scope (... and may be achieved).
>>
>>>>>                 interaction is through a user interface, not a
>>>>>                 machine protocol.
>>>>
>>>>                 Wait a second. You wrote "the User is the RO". The
>>>>                 User is attempting to make an access to a RS by
>>>>                 using a Client.
>>             OAuth initially assumed a static relationship between
>>             client, authorization server and resource servers.  (...)
>>             by a dynamic establishment of the relationship between
>>             clients on one side and the authorization and
>>             This way, the same client could be used to access
>>             services of different providers (in case of standard APIs,
>>             such as e-mail or OpenID Connect) or serve as a frontend
>>             to a particular tenant in a multi-tenancy environment.
>>
>>
>>     This sentence does not mention the RO or the Client. I'm confused
>>     what we are talking about
>>
>>>>             A client application would like access to the user's
>>>>             photos at a photo sharing site. The resource is the
>>>>             user's photos. The user is the owner of that resource.
>>>
>>>             If the user has already pre established the access
>>>             control policy rules so that it can access to his own
>>>             photos
>>>         I don't understand what you are trying to say. The photo
>>>         sharing example was a driving use case for the creation of
>>>         OAuth.
>>
>>         We would need to revisit the original scenario and consider
>>         if it can be addressed in a different way than the original way.
>>

---

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

Hi Denis, comments inserted ...

On Fri, Jul 24, 2020 at 9:08 AM Denis <[email-masked]> wrote:

> Hi Dick,
>
> draft-hardt-xauth-protocol-13 describes a solution without clearly stating
> what the problem(s) to be solved is/are.
>

I agree that the problem description is not as crisp as I would like it to
be. A challenge is that there is a broad spectrum of use cases solved by
OAuth 2, and OpenID Connect, as well as the new use cases that are solved
by GNAP.

That is why I am suggesting we gather some use cases so we have a common
understanding of the problems that are in scope.

> it is no more up-to-date since the first data flow is now a contact with a
> RS. The reason(s) for the GS to contact a RO has still not

I have made no updates as we are in a quiet period prior to the WG meeting
next week when documents cannot be updated.

>
> Figure 4 shows only a single RS. Is the relaying of one operation by that
> RS to a second RS in the scope of this document ?

I view that as an advanced use case that would be covered in a separate
document.

> tokens from two GSs are needed by a RS ?

I don't know of a use case where two tokens would be needed by an RS. Would
you elaborate?
The RS being able to accept tokens from two different GSes is covered, but
the Client is only using a token from one GS at a time.

> data flows and a list of its properties/characteristics.

I disagree. The use cases describe the problems we are looking to solve.
The data flows are part of the solution. For example, from my understanding
of your use case, you don't want the GS to have visibility into the User's
activity. Am I correct that this is one of your requirements for your use
case?

> prior relationships with the GS ? What is the difference/implications when
> it has or it hasn't ?
>
> I have not listed all its properties/characteristics of that model, but I
> am pretty sure that you already have a flavour of it.
>
>    - the case of the relaying of one operation by one RS to a second RS
>    - the case where access tokens from two GSs are needed by one RS (if
See above

>    -
> After that, we can explore the different ways that your use case can be
> addressed.
>
> justification,
>> *Note *: a capability identifies a resource and an allowed operation
>>>> The support of the "User consent and choice" has strong implications
>>>> not only in the sequences of the exchanges
>>>> Thanks for this example. I finally understand what you have in mind:
>>>> you are considering using an access control model to build a *workflow
>>>> model*.
>> In an enterprise use case, the GS's knowledge of who is accessing which
>> RS is a feature.
>>
>>>> The model you propose may be suited for an enterprise environment but
>>>> is not scalable over the Internet.
>>>>
>>>> Access  control has been defined a long time ago and the last edition
>>>> of the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
ᐧ

---

From: Denis <[email-masked]>
Date: Fri, 24 Jul 2020 21:04:33 +0200

Hi Dick,

In order to send back a quick reply tonight, I will only respond to one 
of your questions:

    [Denis] How would be the data flow when access tokens from two GSs
    are needed by a RS ?

    [Dick] I don't know of a use case where two tokens would be needed
    by an RS. Would you elaborate?

I already described on the list the case of a student registering to a 
new University.

First, the student connects to the RS from the new University and opens 
an account
(at this time the student is using a pseudo and a private key to 
authenticate). He fills some forms
and indicate its citizenship, his home address and his graduation in his 
current university.

When he is finished, he indicates that he wants to perform a 
Registration operation.

 From the information gathered in the forms, the RS informs the client 
that it needs two access tokens:

  * one to demonstrate that his name and current home address are
    correct,and
  * another one to demonstrate that he got a graduation from its current
    University.

Depending upon the information captured in the forms, the RS also 
indicates which ASs/GSs are acceptable
and which kind of attributes are requested.

The user consent and choice is performed by the client and once approved 
by the student, two access tokens are separately requested.
Finally, two access tokens are presented to the RS while invoking a 
Registration operation.

Note that the start of the story is to open an account, e.g. using FIDO. 
The needs of the RS are only disclosed to the student once he has filled 
some forms
and indicated that he wanted to perform a Registration operation. Thus, 
the needs that are revealed by the RS are dependant both upon the operation
that the student is willing to perform and the information collected in 
the forms.

Denis

> On Fri, Jul 24, 2020 at 9:08 AM Denis <[email-masked] 
> I agree that the problem description is not as crisp as I would like 
> it to be. A challenge is that there is a broad spectrum of use cases 
> solved by OAuth 2, and OpenID Connect, as well as the new use cases 
> that are solved by GNAP.
>
> That is why I am suggesting we gather some use cases so we have a 
> common understanding of the problems that are in scope.
>
>
>     At the moment, draft-hardt-xauth-protocol-13 includes a single
>     figure on page 4 and from previous discussions I understood that
>     it is no more up-to-date since the first data flow is now a
>     contact with a RS. The reason(s) for the GS to contact a RO has
>     still not
>     been explained (since the inputs and outputs are not described).
>     The discovery information made available at various steps at the RS
>     is not described.
>
>
> I have made no updates as we are in a quiet period prior to the WG 
> meeting next week when documents cannot be updated.
>
>
>     Figure 4 shows only a single RS. Is the relaying of one operation
>     by that RS to a second RS in the scope of this document ?
> I view that as an advanced use case that would be covered in a 
> separate document.
>
>
>     Figure 4 shows only a single GS. How would be the data flow when
>     access tokens from two GSs are needed by a RS ?
>
>
> I don't know of a use case where two tokens would be needed by an RS. 
> Would you elaborate?
> The RS being able to accept tokens from two different GSes is covered, 
> but the Client is only using a token from one GS at a time.
>
>
>     What we need first is not a set of "use cases" but a clear model
>     with a data flows and a list of its properties/characteristics.
>
>
> I disagree. The use cases describe the problems we are looking to 
> solve. The data flows are part of the solution. For example, from my 
> understanding of your use case, you don't want the GS to have 
> visibility into the User's activity. Am I correct that this is one of 
> your requirements for your use case?
>
>     Then after, we can understand much better which use cases can/will
>     be supported. For example, shall a RS (or its RO) have
>     prior relationships with the GS ? What is the
>     difference/implications when it has or it hasn't ?
>
>     At the moment, the model I have described including the data flows
>     is clear. The discovery information made available by a RS is clear.
>     I have not listed all its properties/characteristics of that
>     model, but I am pretty sure that you already have a flavour of it.
>
>       * the case of the relaying of one operation by one RS to a
>         second RS (if it is in the scope of your document),
>       * the case where access tokens from two GSs are needed by one RS
>         (if it is in the scope of your document).
>
>
> See above
>
>      *
>
>
>     Denis
>
>>     Hi Denis
>>
>>     I think it would be useful to take a step back and for you to
>>     describe your use case.
>>     After that, we can explore the different ways that your use case
>>     can be addressed.
>>
>>     Looking at your previous communication, it describes the
>>     solution, and the justification,
>>         I have identified the reason of the major difference between
>>         our two approaches.
>>
>>         Access control may be performed using either ACLs (Access
>>         Control Lists) or Capabilities.
>>
>>         You are advocating a Capabilities approach while I am
>>         advocating an ACL approach.
>>
>>         The capabilities approach allows the GS to trace every
>>         operation performed by the users on any RS known by a GS.
>>         The management of these capabilities is made via the GS or at
>>         the GS by the various ROs. If the management is made
>>         ability to know all the capabilities of the users whether
>>         they are used or not. The less that can be said is that this
>>         model
>>         is not privacy friendly.
>>
>>         (ADF) at the RS is able to keep track from prior decisions.
>>         The GS is kept ignorant of the content of these ACLs and only
>>         delivers to its clients attributes that are placed into
>>         access tokens. Such a model may be privacy friendly.
>>
>>>>             On Tue, Jul 21, 2020 at 6:03 AM Denis
>>>>                     You are considering using an access control
>>>>                     model to build a**workflow model.
>>>>                     **
>>>>                     While it may be interesting to define a
>>>>                     workflow model, this should be considered
>>>>>>                         progress. We are now close to an
>>>>>                     unanswered is where, when and how the user
>>>>>                     consent is captured.
>>>>>
>>>>>
>>>>>                 When is covered, per the sequence. How and where
>>>>>                 are out of scope of what I drafted.
>>>>
>>>>                 It is clear that the "User consent and choice" is
>>>>                 not currently addressed in the draft, but it should.
>>>>                 The support of the "User consent and choice" has
>>>>                 strong implications not only in the sequences of
>>>>                 the exchanges
>>>             "Consent" is present 5 times. The User consent is
>>>             different from the RO consent (when/if it is required).
>>>
>>>                 The server acquires consent and authorization from
>>>                 the user *and/**or resource owner **if required.*
>>>
>>>                 User consent is *often required* at the GS. GNAP
>>>                 enables a Client and  GS to negotiate the
>>>                 interaction mode for the GS to obtain consent.
>>>
>>>                 The GS *may *require explicit consent from the RO or
>>>                 User to provide these to the Client.
>>>
>>>             The User consent is not an alternative to the RO
>>>             consent. So using "and/or" in the first sentence is
>>>             incorrect.
>>>
>>>
>>>         My language is sloppy there. Consent is always from the RO.
>>>         The User may be the RO.
>>
>>         [Denis] No. Once again: The "/User consent/" is different
>>         from what you call the "/RO consent/" (when/if it is required).
>>         The "RO consent" is not in fact a consent but the release of
>>         a capability to a client by one of the many R0s with which
>>>         User consent may not be required. There may not be a User.
>>>         The consent may have been gathered previously.
>>
>>         A Client is called either by a User (i.e. a natural person)
>>         or by a Client application.
>>
>>>             The second sentence does not consider the possibility to
>>>             get the User consent in a place different from the GS.
>>>
>>         [Denis] No. I disagree. In an ACL based systems, the GS does
>>         not need to ask or receive any consent.
>>         If the GS has the requested attributes, then it provides
>>         them, otherwise it returns an error to the Client.
>>
>>>             The information used to obtain the User consent should
>>>             be standardized (... and it can be standardized).
>>>
>>>>             I think the abstract sequence as proposed by Francis is
>>>>             a great addition, and would clarify where consent is in
>>>>             the sequence.
>>>
>>>             The current sketch does not illustrate the place the
>>>             User Consent is captured, in particular by the Client.
>>>
>>>         It is an abstraction. The GS receives the consent. How
>>>         consent is gathered is a detail that is dependent on the use
>>>         case.
>>
>>         [Denis] I really wonder whether there is really a "consent"
>>         to be received by the GS in both cases (i.e. ACLs or
>>         Capabilities).
>>
>>           * For Capabilities, the current description is not clear
>>             since the inputs and the outputs for this "consent" phase
>>>>>                     Another important point to consider and to
>>>>>                     explain is related to the assurances that the
>>>>>                     user can obtain about
>>>>                 This point is equally important: such assurance can
>>>>                 only be obtained if the access token returned to
>>>>                 the client
>>>>                 is not considered to be opaque to the client. This
>>>>                 is a necessary condition but not the single condition:
>>>>                 capture/memorize the "User consent and choice" of
>>>>                 the user in order to be able
>>>>             We disagree on this being a requirement for all use
>>>>             cases. It may be in some.
>>>
>>>             "access tokens returned to the client are not considered
>>>             to be opaque to the client".
>>>
>>>
>>>         For OAuth use cases, which GNAP supports, the access token
>>>         is opaque to the Client. As you have noted, there are use
>>>         cases where the access token is NOT opaque.
>>
>>         I believe that there is a requirement to support OAuth 2.0
>>         ASs, while the clients may be different
>>         and hence GNAP clients do not need to inherit of the
>>         limitations of OAuth 2.0 clients.
>>
>>>>>
>>>>>>                         If a RO needs to be involved and since a
>>>>>>                         RO is directly associated with a RS, why
>>>>>>                         can't it be directly queried
>>>>>>                     Good question. Perhaps you can expand on a
>>>>>>                     use case where that would be useful?
>>>>>
>>>>>                     Before I expand, would you be able to explain
>>>>>                     first under which circumstances a RO needs to
>>>>>                     be queried by a GS ?
>>>>                 How could a GS know that "the User is the RO" ?  If
>>>>                 "the User is the RO", why does the GS needs to
>>>>                 query the User ?
>>>>
>>>>
>>>>             To get consent?
>>>
>>>         The GS needs consent from the RO. If the RO is the User,
>>>         then consent from the RO is equivalent to consent from the User.
>>
>>         [Denis] See above.
>>
>>>
>>>>>                 If the RO is a separate entity, then the GS knows
>>>>>                 the RO from the RS being queried.
>>>>
>>>>                  ... and this gives the ability for the GS to
>>>>                 log/trace all the RSs accessed by a given User and
>>>>                 at which instant of time the access token has been
>>>>                 granted.
>>>>
>>>>>                 An example is a user would like access to an
>>>>>                 enterprise asset where a workflow is started to
>>>>>                 gain approval, and an administrator or manager
>>>>>                 provides consent.
>>>>
>>>>                 Thanks for this example. I finally understand what
>>>>                 you have in mind: you are considering using an
>>>>                 access control model to build a *workflow model*.
>>>>                 model, this should be considered as a *separate and
>>>>                 different work item*.
>>>>
>>>>
>>>         It illustrates a use case where the RO and User are not the
>>>         same party, and why the GS needs to query the RO, which was
>>>         your question if I understood it correctly.
>>
>>         [Denis] Since the inputs and the outputs for this "RO
>>         consent" phase are not currently described in the draft, the
>>         point is still unsolved.
>>
>>>             If a RO consent is performed at the RS, then the GS will
>>>             not know who the RS is: it is then unable to act as Big
>>>             Brother,
>>>         In an enterprise use case, the GS's knowledge of who is
>>>         accessing which RS is a feature.
>>
>>         Do you mean that it is "normal" in an enterprise that a
>>         single point of control is able to trace all their actions ?
>>         From a security point of view, a single point of failure will
>>         have dramatic consequences.
>>
>>         I do hope that you have finally understood that, in my use
>>         case, the RO is **not** the User.
>>
>>>         something. If the access token is generic, and could be
>>>         presented to any RS that provides a standardized function,
>>>         then the GS does not know which RS is being accessed by a
>>>         Client for the User. This seems to meet your privacy
>>>         objectives. If not, what is wrong?
>>
>>         For security reasons, an access token needs to be targeted
>>         (which does not necessarily mean that an identifier of the RS
>>         shall be included into the access token).
>>
>>>>                 The model you propose may be suited for an
>>>>                 enterprise environment but is not scalable over the
>>>>                 Internet.
>>>>
>>>>                 What is needed is an access control model usable
>>>>                 over the Internet with millions of RSs and
>>>>                 thousands of ASs/GSs.
>>>>
>>>                 The flow starts with the steps (1) to (4) as
>>>                 illustrated by Francis, i.e. the flow starts with a
>>>                 contact with a RS.
>>>
>>>             Furthermore, it is possible to prevent the GS to act as
>>>             Big Brother when the identity of the RS is not disclosed
>>>             to the GS.
>>>
>>>
>>         [Denis] The key point is that we first need to agree on the
>>         first four exchanges. Do we ?
>>
>>>>>>                     Just like how the user authenticates to an
>>>>>>                     AS, how the AS and RO communicate is out of
>>>>>>                     scope.
>>>>>
>>>>>                     At the moment, the usefulness of a dialogue
>>>>>                     between a GS and a RO has not been explained,
>>>>>                     nor demonstrated.
>>>>>                     The question is about the functionality of
>>>>>                     that dialogue in terms of input and output
>>>>>                     information (and not about
>>>>>                     the design of a protocol or of a user
>>>>>                     interface). Anyway, AFAIU a dialogue between a
>>>>>                     GS and a RO is optional.
>>>>>
>>>>>
>>>>                 Access control has been defined a long time ago and
>>>>                 the last edition of the model has been confirmed in
>>>>                 year 1996: ISO/IEC 10181-3: 1996.
>>>>                 "Information technology — Open Systems
>>>>                 Interconnection — Security frameworks for open
>>>>                 systems: Access control framework — Part 3".
>>>>
>>>>                 Two major functions have ben defined: an
>>>>                 AccessControl Enforcement Function (AEF) and an
>>>>                 AccessControl Decision Function(ADF).
>>>>
>>>>                     A specialized function that is part of the
>>>>                     access path between an initiator and a target
>>>>                     on each access request and enforces the
>>>>                     A specialized function that makes access
>>>>                     control decisions by applying access control
>>>>                     policy rules to an access request, ADI (of
>>>>                 policy rules" at the RS according to thecontext in
>>>>             I would say that the access control is happening at the
>>>>             RS. The client presents a token when accessing an API.
>>>             Fine. It looks like we are in agreement. Unfortunately,
>>>             this is not the case just below.
>>>
>>>>             Here is flow:
>>>>
>>>             No. We are no more in agreement. This is different from
>>>             the flow drawn by Francis.
>>>
>>>>             4) The Client presents the access token to the RS to
>>>>             show it has been granted access.
>>>
>>>             No. The client presents a token when accessing an API.
>>>             The token never contains an information like "Please
>>>             grant an access to the holder of this token".
>>>
>>>         The Client presents the access token to the RS, to show the
>>>         RS that the Client has been granted access to a resource at
>>>         the RS by the GS.
>>
>>         [Denis] This time, please consider both the ACLs approach and
>>         the Capabilities approach.
>>
>>>>             - the access token MAY be self contained so that the
>>>>             Client does not need to query the GS on each access.
>>>
>>>         Darn: I clearly was not firing on all cylinders when I typed
>>>         this out. Let me correct:
>>>
>>>>         - the access token MAY be self contained so that the RS
>>>>         does not need to query the GS on each access to the RS by
>>>>         the Client.
>>
>>             - the GS needs to establish a trusted communication
>>             channel or an authentication mechanism with each RO
>>             position to issue any capability for any RS (without a
>>             "RO consent").
>>
>>>>             I would not say that GNAP is an access control
>>>>             protocol, as how the RS uses the token to determine
>>>>             access is out of scope.
>>>
>>>             This is where we have a major discrepancy: how the RS
>>>             uses the token to determine access is *within* the scope.
>>>
>>>             The RS announces in advance to the client what it needs
>>>             so that the client can perform a a given operation and
>>>             if the client supplies the requested attributes
>>>             obtained from some GS/AS(s) trusted by the RS, then
>>>             access to that RS is granted by the RS. If the RS cannot
>>>             perform the requested operation on its own,
>>>             for subsequent operations. The User consent should also
>>>             be obtained before performing the chaining operation.
>>>
>>>             Chaining operations between RSs over the Internet is
>>>             within the scope (... and may be achieved).
>>>
>>>>>>                     For many use cases, the User is the RO, and
>>>>>                     Wait a second. You wrote "the User is the RO".
>>>>>                     The User is attempting to make an access to a
>>>>>                     RS by using a Client.
>>>                 OAuth initially assumed a static relationship
>>>                 between client, authorization server and resource
>>>                 servers.  (...)
>>>                 With the increasing adoption of OAuth, this simple
>>>                 model dissolved and, in several scenarios, was replaced
>>>                 by a dynamic establishment of the relationship
>>>                 between clients on one side and the authorization and
>>>                 such as e-mail or OpenID Connect) or serve as a
>>>                 frontend to a particular tenant in a multi-tenancy
>>>                 environment.
>>>
>>>
>>>         This sentence does not mention the RO or the Client. I'm
>>>         confused what we are talking about
>>>
>>>>>                 A client application would like access to the
>>>>>                 user's photos at a photo sharing site. The
>>>>>                 resource is the user's photos. The user is the
>>>>>                 owner of that resource.
>>>>
>>>>                 control policy rules so that it can access to his
>>>>                 own photos
>>>>             I don't understand what you are trying to say. The
>>>>             photo sharing example was a driving use case for the
>>>>             creation of OAuth.
>>>
>>>             We would need to revisit the original scenario and
>>>             consider if it can be addressed in a different way than
>>>             the original way.
>>>

---

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

Hi Denis

I would think in your example below, that the University's registration
system is the Client, not a Resource Server.

Have a good night's sleep!

On Fri, Jul 24, 2020 at 12:04 PM Denis <[email-masked]> wrote:

> Hi Dick,
>
> In order to send back a quick reply tonight, I will only respond to one of
> your questions:
>
> [Denis] How would be the data flow when access tokens from two GSs are
> needed by a RS ?
>
> [Dick] I don't know of a use case where two tokens would be needed by an
> RS. Would you elaborate?
>
> I already described on the list the case of a student registering to a new
> University.
>
> First, the student connects to the RS from the new University and opens an
> account
> When he is finished, he indicates that he wants to perform a Registration
> operation.
>
> From the information gathered in the forms, the RS informs the client that
> it needs two access tokens:
>
>    - one to demonstrate that his name and current home address are
>    correct,and
>    - another one to demonstrate that he got a graduation from its current
>    University.
>
>>>>>> the respect of his choices. This point is currently left unanswered
>>>>>> in draft-hardt-xauth-protocol-13.
>>>>>>
>>>>> This point is equally important: such assurance can only be obtained
>>>>> if the access token returned to the client
>>>> "access tokens returned to the client are not considered to be opaque
>>>> to the client".
>>>>
>>>
>>> the access token is generic, and could be presented to any RS that provides
>>> a standardized function,
>>>> Furthermore, it is possible to prevent the GS to act as Big Brother
>>>> when the identity of the RS is not disclosed to the GS.
>>>>
>>>
>>>> This is where we have a major discrepancy: how the RS uses the token
>>>> to determine access is *within* the scope.
>>>>
>>>> obtained from some GS/AS(s) trusted by the RS, then access to that RS
>>>> is granted by the RS. If the RS cannot perform the requested operation on
>>>> its own,
>>>> We would need to revisit the original scenario and consider if it can
>>>> be addressed in a different way than the original way.
>>>>

---

From: Denis <[email-masked]>
Date: Mon, 27 Jul 2020 09:49:21 +0200

Hi Dick,

The floor is yours.

Would you explain how you would handle the use case of a student 
registering to a new University ?

Would you also elaborate why in my explanations below, you think that 
"the University's registration system is the Client, not a Resource 
Server" ?

Denis

> Hi Denis
>
> I would think in your example below, that the 
> University's registration system is the Client, not a Resource Server.
>
> On Fri, Jul 24, 2020 at 12:04 PM Denis <[email-masked] 
>     In order to send back a quick reply tonight, I will only respond
>     to one of your questions:
>
>         [Denis] How would be the data flow when access tokens from two
>         GSs are needed by a RS ?
>
>         [Dick] I don't know of a use case where two tokens would be
>         needed by an RS. Would you elaborate?
>
>     I already described on the list the case of a student registering
>     to a new University.
>
>     First, the student connects to the RS from the new University and
>     opens an account
>     and indicate its citizenship, his home address and his graduation
>     in his current university.
>
>     From the information gathered in the forms, the RS informs the
>     client that it needs two access tokens:
>
>       * another one to demonstrate that he got a graduation from its
>         current University.
>
>     The user consent and choice is performed by the client and once
>     approved by the student, two access tokens are separately requested.
>     Finally, two access tokens are presented to the RS while invoking
>     a Registration operation.
>
>     Note that the start of the story is to open an account, e.g. using
>     FIDO. The needs of the RS are only disclosed to the student once
>     he has filled some forms
>     and indicated that he wanted to perform a Registration operation.
>     Thus, the needs that are revealed by the RS are dependant both
>     upon the operation
>     that the student is willing to perform and the information
>     collected in the forms.
>
>     Denis
>
>>         draft-hardt-xauth-protocol-13 describes a solution without
>>         clearly stating what the problem(s) to be solved is/are.
>>
>>
>>     I agree that the problem description is not as crisp as I would
>>     like it to be. A challenge is that there is a broad spectrum of
>>     use cases solved by OAuth 2, and OpenID Connect, as well as the
>>     new use cases that are solved by GNAP.
>>
>>         At the moment, draft-hardt-xauth-protocol-13 includes a
>>         single figure on page 4 and from previous discussions I
>>         understood that
>>         contact with a RS. The reason(s) for the GS to contact a RO
>>         has still not
>>         been explained (since the inputs and outputs are not
>>         described). The discovery information made available at
>>         various steps at the RS
>>         is not described.
>>
>>
>>     I have made no updates as we are in a quiet period prior to the
>>     WG meeting next week when documents cannot be updated.
>>
>>
>>         Figure 4 shows only a single RS. Is the relaying of one
>>         operation by that RS to a second RS in the scope of this
>>         document ?
>>         Figure 4 shows only a single GS. How would be the data flow
>>         when access tokens from two GSs are needed by a RS ?
>>
>>
>>     I don't know of a use case where two tokens would be needed by an
>>     RS. Would you elaborate?
>>     The RS being able to accept tokens from two different GSes is
>>     covered, but the Client is only using a token from one GS at a time.
>>
>>
>>         What we need first is not a set of "use cases" but a clear
>>         model with a data flows and a list of its
>>     solve. The data flows are part of the solution. For example, from
>>     my understanding of your use case, you don't want the GS to have
>>     visibility into the User's activity. Am I correct that this is
>>     one of your requirements for your use case?
>>
>>         Then after, we can understand much better which use cases
>>         can/will be supported. For example, shall a RS (or its RO) have
>>         In order to have a fair comparison, we should try to list
>>         model properties/characteristics.
>>
>>         At the moment, the model I have described including the data
>>         flows is clear. The discovery information made available by a
>>         RS is clear.
>>           * the case where access tokens from two GSs are needed by
>>             one RS (if it is in the scope of your document).
>>
>>
>>     See above
>>
>>          *
>>
>>
>>         Denis
>>
>>>         Hi Denis
>>>
>>>         I think it would be useful to take a step back and for you
>>>         to describe your use case.
>>>         After that, we can explore the different ways that your use
>>>         case can be addressed.
>>>
>>>             I have identified the reason of the major difference
>>>             between our two approaches.
>>>
>>>             Access control may be performed using either ACLs
>>>             (Access Control Lists) or Capabilities.
>>>
>>>             _Note _: a capability identifies a resource and an
>>>             allowed operation that can be performed on that resource.
>>>
>>>             The management of these capabilities is made via the GS
>>>             or at the GS by the various ROs. If the management is made
>>>             via the GS, then a trusted communication channel needs
>>>             to be established with every RO. If the management is made
>>>             ability to know all the capabilities of the users
>>>             whether they are used or not. The less that can be said
>>>             is that this model
>>>             is not privacy friendly.
>>>
>>>             With the ACL approach, a RO directly manages an ACL
>>>             placed in front of each RS. The AccessControl Decision
>>>             Function
>>>             (ADF) at the RS is able to keep track from prior
>>>             decisions. The GS is kept ignorant of the content of
>>>             these ACLs and only
>>>>             On Tue, Jul 21, 2020 at 11:26 AM Denis
>>>>>                         You are considering using an access
>>>>>                         control model to build a**workflow model.
>>>>>                         **
>>>>>>                         This major question which is currently
>>>>>>                         left unanswered is where, when and how
>>>>>>                         the user consent is captured.
>>>>>>
>>>>>>
>>>>>>                     When is covered, per the sequence. How and
>>>>>>                     where are out of scope of what I drafted.
>>>>>
>>>>>                     It is clear that the "User consent and choice"
>>>>>                     is not currently addressed in the draft, but
>>>>>                     it should.
>>>>>                     The support of the "User consent and choice"
>>>>>                     has strong implications not only in the
>>>>>                     sequences of the exchanges
>>>>                     The server acquires consent and authorization
>>>>                     from the user *and/**or resource owner **if
>>>>                     required.*
>>>>
>>>>                     User consent is *often required* at the GS.
>>>>                     GNAP enables a Client and GS to negotiate the
>>>>                     The GS *may *require explicit consent from the
>>>>                     RO or User to provide these to the Client.
>>>>
>>>>             My language is sloppy there. Consent is always from the
>>>>             RO. The User may be the RO.
>>>
>>>             [Denis] No. Once again: The "/User consent/" is
>>>             different from what you call the "/RO consent/" (when/if
>>>             it is required).
>>>             The "RO consent" is not in fact a consent but the
>>>             release of a capability to a client by one of the many
>>>             R0s with which
>>>>                 Since the second sentence is using the wording
>>>>                 "often required" there is no requirement to get the
>>>>                 User consent.
>>>>
>>>>             User consent may not be required. There may not be a
>>>>             User. The consent may have been gathered previously.
>>>
>>>             [Denis] In order to follow the privacy principles, a
>>>             "User consent" phase is required. The User is a natural
>>>             person.
>>>             A Client is called either by a User (i.e. a natural
>>>             person) or by a Client application.
>>>
>>>>                 The second sentence does not consider the
>>>>                 possibility to get the User consent in a place
>>>>                 different from the GS.
>>>>
>>>>             Agreed. But we do agree that the GS gets the consent,
>>>>             either directly from the RO, or from the Client (in
>>>>             your example).
>>>
>>>             [Denis] No. I disagree. In an ACL based systems, the GS
>>>             does not need to ask or receive any consent.
>>>             The client selects the set of attributes that it wants
>>>             to be inserted into an access token.
>>>>                 The information used to obtain the User consent
>>>>                 should be standardized (... and it can be
>>>>                 standardized).
>>>>
>>>>>                 I think the abstract sequence as proposed by
>>>>>                 Francis is a great addition, and would clarify
>>>>>                 where consent is in the sequence.
>>>>
>>>>                 The current sketch does not illustrate the place
>>>>                 the User Consent is captured, in particular by the
>>>>                 Client.
>>>>
>>>>             consent is gathered is a detail that is dependent on
>>>>             the use case.
>>>
>>>             [Denis] I really wonder whether there is really a
>>>             "consent" to be received by the GS in both cases (i.e.
>>>             ACLs or Capabilities).
>>>
>>>               * For Capabilities, the current description is not
>>>                 clear since the inputs and the outputs for this
>>>                 "consent" phase
>>>>>>                         Another important point to consider and
>>>>>>                         to explain is related to the assurances
>>>>>>                         that the user can obtain about
>>>>>                     This point is equally important: such
>>>>>                     assurance can only be obtained if the access
>>>>>                     token returned to the client
>>>>>                     is not considered to be opaque to the client.
>>>>>                     This is a necessary condition but not the
>>>>>                     single condition:
>>>>>                     capture/memorize the "User consent and choice"
>>>>>                     of the user in order to be able
>>>>>                 We disagree on this being a requirement for all
>>>>>                 use cases. It may be in some.
>>>>
>>>>                 "access tokens returned to the client are not
>>>>                 considered to be opaque to the client".
>>>>
>>>>
>>>>             For OAuth use cases, which GNAP supports, the access
>>>>             token is opaque to the Client. As you have noted, there
>>>>             are use cases where the access token is NOT opaque.
>>>
>>>             [Denis] Wait a second. There is no requirement to
>>>             support all OAuth use cases.
>>>             I believe that there is a requirement to support OAuth
>>>             2.0 ASs, while the clients may be different
>>>>>>>                         Good question. Perhaps you can expand on
>>>>>>>                         a use case where that would be useful?
>>>>>>
>>>>>>                         Before I expand, would you be able to
>>>>>>                         explain first under which circumstances a
>>>>>>                         RO needs to be queried by a GS ?
>>>>>                     How could a GS know that "the User is the RO"
>>>>>                     ? If "the User is the RO", why does the GS
>>>>>                     needs to query the User ?
>>>>>
>>>>>
>>>>>                 To get consent?
>>>>
>>>>             The GS needs consent from the RO. If the RO is the
>>>>             User, then consent from the RO is equivalent to consent
>>>>             from the User.
>>>
>>>             [Denis] See above.
>>>
>>>>
>>>>>>                     If the RO is a separate entity, then the GS
>>>>>>                     knows the RO from the RS being queried.
>>>>>
>>>>>                     log/trace all the RSs accessed by a given User
>>>>>                     and at which instant of time the access token
>>>>>                     has been granted.
>>>>>
>>>>>>                     enterprise asset where a workflow is started
>>>>>>                     to gain approval, and an administrator or
>>>>>                     Thanks for this example. I finally understand
>>>>>                     what you have in mind: you are considering
>>>>>                     using an access control model to build a
>>>>>                     *workflow model*.
>>>>>                     workflow model, this should be considered as a
>>>>>                     *separate and different work item*.
>>>>>
>>>>>
>>>>                 I am glad you agree with this. But this means that
>>>>                 your example was not appropriate to illustrate your
>>>>                 point.
>>>>
>>>>
>>>>             It illustrates a use case where the RO and User are not
>>>>             the same party, and why the GS needs to query the RO,
>>>>             which was your question if I understood it correctly.
>>>
>>>             consent" phase are not currently described in the draft,
>>>             the point is still unsolved.
>>>
>>>>                 As soon as there is a RO consent obtained at the
>>>>                 GS, the major problem is that the GS is able to act
>>>>                 as Big Brother.
>>>>                 If a RO consent is performed at the RS, then the GS
>>>>                 will not know who the RS is: it is then unable to
>>>>                 act as Big Brother,
>>>             From a security point of view, a single point of failure
>>>             will have dramatic consequences.
>>>
>>>             I do hope that you have finally understood that, in my
>>>             use case, the RO is **not** the User.
>>>
>>>>             then the GS does not know which RS is being accessed by
>>>>             a Client for the User. This seems to meet your privacy
>>>             For security reasons, an access token needs to be
>>>             targeted (which does not necessarily mean that an
>>>             identifier of the RS shall be included into the access
>>>             token).
>>>
>>>>>                     enterprise environment but is not scalable
>>>>>                     over the Internet.
>>>>>
>>>>>                     What is needed is an access control model
>>>>>                     usable over the Internet with millions of RSs
>>>>>                     and thousands of ASs/GSs.
>>>>>
>>>>                     illustrated by Francis, i.e. the flow starts
>>>>                     with a contact with a RS.
>>>>
>>>>                 Furthermore, it is possible to prevent the GS to
>>>>                 act as Big Brother when the identity of the RS is
>>>>                 not disclosed to the GS.
>>>>
>>>>
>>>             [Denis] The key point is that we first need to agree on
>>>             the first four exchanges. Do we ?
>>>
>>>>>>>                         Just like how the user authenticates to
>>>>>>>                         an AS, how the AS and RO communicate is
>>>>>>>                         out of scope.
>>>>>>
>>>>>>                         The question is about the functionality
>>>>>>                         of that dialogue in terms of input and
>>>>>>                         output information (and not about
>>>>>>                         interface). Anyway, AFAIU a dialogue
>>>>>                     Access control has been defined a long time
>>>>>                     ago and the last edition of the model has been
>>>>>                     confirmed in year 1996: ISO/IEC 10181-3: 1996.
>>>>>                     AccessControl Enforcement Function (AEF) and
>>>>>                     an AccessControl Decision Function(ADF).
>>>>>
>>>>>                         access path between an initiator and a
>>>>>                         target on each access request and enforces
>>>>>                         control decisions by applying access
>>>>>                         control policy rules to an access request,
>>>>>                         ADI (of initiators, targets, access requests,
>>>>>                         or that retained from prior decisions),
>>>>>                         and the context in which the access
>>>>>                         request is made.
>>>>>
>>>>>                     The role of the RO is to define the "access
>>>>>                     control policy rules" at the RS according to
>>>>>                     thecontext in which the access request is made.
>>>>>
>>>>>                 I would say that the access control is happening
>>>>>                 at the RS. The client presents a token when
>>>>>                 accessing an API.
>>>>                 Fine. It looks like we are in agreement.
>>>>                 Unfortunately, this is not the case just below.
>>>>
>>>>>                 Here is flow:
>>>>>
>>>>                 No. We are no more in agreement. This is different
>>>>                 from the flow drawn by Francis.
>>>>
>>>>>                 3) If access is granted, the GS creates an access
>>>>>                 token representing the granted access, and returns
>>>>>                 it to the Client.
>>>>
>>>>>                 4) The Client presents the access token to the RS
>>>>>                 to show it has been granted access.
>>>>
>>>>                 No. The client presents a token when accessing an
>>>>                 API. The RS uses the token, and any policy
>>>>                 required, to make an access decision.
>>>>                 The token never contains an information like
>>>>                 "Please grant an access to the holder of this token".
>>>>
>>>>             The Client presents the access token to the RS, to show
>>>>             the RS that the Client has been granted access to a
>>>>             resource at the RS by the GS.
>>>
>>>             [Denis] This time, please consider both the ACLs
>>>             approach and the Capabilities approach.
>>>
>>>>>                 - the access token MAY be self contained so that
>>>>>                 the Client does not need to query the GS on each
>>>>>                 access.
>>>>
>>>>             Darn: I clearly was not firing on all cylinders when I
>>>>             typed this out. Let me correct:
>>>>
>>>>>             RS does not need to query the GS on each access to the
>>>>>             RS by the Client.
>>>
>>>                 - the GS could play the role of the RO and hence be
>>>                 in a position to issue any capability for any RS
>>>                 (without a "RO consent").
>>>
>>>>>                 protocol, as how the RS uses the token to
>>>>>                 determine access is out of scope.
>>>>
>>>>                 This is where we have a major discrepancy: how the
>>>>                 RS uses the token to determine access is *within*
>>>>                 the scope.
>>>>
>>>>                 The RS announces in advance to the client what it
>>>>                 needs so that the client can perform a a given
>>>>                 operation and if the client supplies the requested
>>>>                 attributes
>>>>                 access to that RS is granted by the RS. If the RS
>>>>                 cannot perform the requested operation on its own,
>>>>                 then the client should be informed about some
>>>>                 requested attributes that need to be obtained from
>>>>                 some GS/AS(s) trusted by the next RS(s) in a chain
>>>>                 for subsequent operations. The User consent should
>>>>                 also be obtained before performing the chaining
>>>>                 operation.
>>>>
>>>>                 Chaining operations between RSs over the Internet
>>>>                 is within the scope (... and may be achieved).
>>>>
>>>>>>>                         For many use cases, the User is the RO,
>>>>>>>                         and the interaction is through a user
>>>>>>>                         interface, not a machine protocol.
>>>>>>
>>>>>>                         Wait a second. You wrote "the User is the
>>>>>>                         RO". The User is attempting to make an
>>>>>>                         access to a RS by using a Client.
>>>>                     between client, authorization server and
>>>>                     resource servers.  (...)
>>>>                     With the increasing adoption of OAuth, this
>>>>                     simple model dissolved and, in several
>>>>                     scenarios, was replaced
>>>>                     This way, the same client could be used to
>>>>                     access services of different providers (in case
>>>>                     of standard APIs,
>>>>                     frontend to a particular tenant in a
>>>>                     multi-tenancy environment.
>>>>
>>>>
>>>>             This sentence does not mention the RO or the Client.
>>>>             I'm confused what we are talking about
>>>>
>>>>>>                     resource is the user's photos. The user is
>>>>>>                     the owner of that resource.
>>>>>
>>>>>                     If the user has already pre established the
>>>>>                     access control policy rules so that it can
>>>>>                     access to his own photos
>>>>>                 photo sharing example was a driving use case for
>>>>>                 the creation of OAuth.
>>>>
>>>>                 consider if it can be addressed in a different way
>>>>                 than the original way.
>>>>

---

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

Hi Denis

The student (User) goes to the registration page of the University (the
Client)

Similar to your example, the Client has a list of GS that it are
acceptable, or RS that may be acceptable.

If the User selects a GS, then the Client starts a GNAP flow with the GS.

If the User selects an RS, then the Client can call the RS to determine
which GSes to offer the User to use to get access to the RS.

In summary, the University wants to consume Claims about the User, so it is
the Client.

/Dick

On Mon, Jul 27, 2020 at 12:49 AM Denis <[email-masked]> wrote:

> Would you also elaborate why in my explanations below, you think that "the
> University's registration system is the Client, not a Resource Server" ?
>
> Denis
>
> Hi Denis
>
>>    - another one to demonstrate that he got a graduation from its
>>    current University.
>>
>> I agree that the problem description is not as crisp as I would like it
>> to be. A challenge is that there is a broad spectrum of use cases solved by
>>>> at the GS, then an authentication mechanism needs to be established
>>>> with every RO. In the last case, the GS has the
>>>>> "Consent" is present 5 times. The User consent is different from the
>>>>> RO consent (when/if it is required).
>>>>>
>>>> [Denis] No. Once again: The "*User consent*" is different from what
>>>> you call the "*RO consent*" (when/if it is required).
>>>> Since the second sentence is using the wording "often required" there
>>>>> is no requirement to get the User consent.
>>>>>
>>>> [Denis] No. I disagree. In an ACL based systems, the GS does not need
>>>> to ask or receive any consent.
>>>>>> be considered as a *separate and different work item*.
>>>>>>
>>>>>
>>>>> I am glad you agree with this. But this means that your example was
>>>>> not appropriate to illustrate your point.
>>>>>
>>>>
>>>> [Denis] Since the inputs and the outputs for this "RO consent" phase
>>>> are not currently described in the draft, the point is still unsolved.
>>>>
>>>> the User. This seems to meet your privacy objectives. If not, what is wrong?
>>>>
>>>>> Fine. It looks like we are in agreement. Unfortunately, this is not
>>>>> the case just below.
>>>>>
>>>>> Here is flow:
>>>>>
>>>>> The token never contains an information like "Please grant an access
>>>>> to the holder of this token".
>>>>>
>>>>> that need to be obtained from some GS/AS(s) trusted by the next RS(s) in a
>>>>> chain
>>>>>> photo sharing site. The resource is the user's photos. The user is the
>>>>>> owner of that resource.
>>>>>>

---

From: Denis <[email-masked]>
Date: Tue, 28 Jul 2020 16:12:23 +0200

Hi Dick,

I am puzzled by your response. Your are the editor and a co-editor of 
the two following RFCs which state:

RFC 6749:    In the traditional client-server authentication model, the 
client requests an access-restricted resource
                      (protected resource) on the server by 
authenticating with the server (...)

RFC 6750 : The client uses the access token to access the protected 
resources hosted by the resource server.

                     The following two steps are specified within this 
document:

                                (E)  The client requests the protected 
resource from the resource server and authenticates
                                        by presenting the access token.

                               (F)  The resource server validates the 
access token, and if valid, serves the request.

In my use case, the student connects to the University server (i.e. a 
RS) as a client. The University server cannot be a Client.
If you change/twist that basic vocabulary, we will not be able to 
understand each other any more.

BTW, my first question still remains: Would you explain how you would 
handle the use case of a student registering to a new University ?

Denis

> Hi Denis
>
> The student (User) goes to the registration page of the University 
> (the Client)
>
> If the User selects an RS, then the Client can call the RS to 
> determine which GSes to offer the User to use to get access to the RS.
>
> In summary, the University wants to consume Claims about the User, so 
> it is the Client.
>
> /Dick
>
>
>
> On Mon, Jul 27, 2020 at 12:49 AM Denis <[email-masked] 
>     Would you also elaborate why in my explanations below, you think
>     that "the University's registration system is the Client, not a
>     Resource Server" ?
>
>     Denis
>
>>     Hi Denis
>>
>>         In order to send back a quick reply tonight, I will only
>>         respond to one of your questions:
>>
>>             [Denis] How would be the data flow when access tokens
>>             from two GSs are needed by a RS ?
>>
>>             [Dick] I don't know of a use case where two tokens would
>>             be needed by an RS. Would you elaborate?
>>
>>         I already described on the list the case of a student
>>         registering to a new University.
>>
>>         First, the student connects to the RS from the new University
>>         and opens an account
>>         (at this time the student is using a pseudo and a private key
>>         to authenticate). He fills some forms
>>         and indicate its citizenship, his home address and his
>>         graduation in his current university.
>>
>>         From the information gathered in the forms, the RS informs
>>         the client that it needs two access tokens:
>>
>>           * one to demonstrate that his name and current home address
>>             are correct,and
>>           * another one to demonstrate that he got a graduation from
>>             its current University.
>>
>>         Depending upon the information captured in the forms, the RS
>>         also indicates which ASs/GSs are acceptable
>>         The user consent and choice is performed by the client and
>>         once approved by the student, two access tokens are
>>         separately requested.
>>         Finally, two access tokens are presented to the RS while
>>         invoking a Registration operation.
>>
>>         Note that the start of the story is to open an account, e.g.
>>         using FIDO. The needs of the RS are only disclosed to the
>>         student once he has filled some forms
>>         and indicated that he wanted to perform a Registration
>>         operation. Thus, the needs that are revealed by the RS are
>>         dependant both upon the operation
>>>             draft-hardt-xauth-protocol-13 describes a solution
>>>             without clearly stating what the problem(s) to be solved
>>>             is/are.
>>>
>>>
>>>         I agree that the problem description is not as crisp as I
>>>         would like it to be. A challenge is that there is a broad
>>>         spectrum of use cases solved by OAuth 2, and OpenID Connect,
>>>         as well as the new use cases that are solved by GNAP.
>>>
>>>         That is why I am suggesting we gather some use cases so we
>>>         have a common understanding of the problems that are in scope.
>>>
>>>
>>>             it is no more up-to-date since the first data flow is
>>>             now a contact with a RS. The reason(s) for the GS to
>>>             contact a RO has still not
>>>         I have made no updates as we are in a quiet period prior to
>>>         the WG meeting next week when documents cannot be updated.
>>>
>>>
>>>         I view that as an advanced use case that would be covered in
>>>         a separate document.
>>>
>>>
>>>             Figure 4 shows only a single GS. How would be the data
>>>             flow when access tokens from two GSs are needed by a RS ?
>>>
>>>
>>>         I don't know of a use case where two tokens would be needed
>>>         The RS being able to accept tokens from two different GSes
>>>         is covered, but the Client is only using a token from one GS
>>>         at a time.
>>>
>>>
>>>             What we need first is not a set of "use cases" but a
>>>             clear model with a data flows and a list of its
>>>         I disagree. The use cases describe the problems we are
>>>         looking to solve. The data flows are part of the solution.
>>>         For example, from my understanding of your use case, you
>>>         don't want the GS to have visibility into the User's
>>>         activity. Am I correct that this is one of your requirements
>>>         for your use case?
>>>
>>>             Then after, we can understand much better which use
>>>             cases can/will be supported. For example, shall a RS (or
>>>             its RO) have
>>>             In order to have a fair comparison, we should try to
>>>             list model properties/characteristics.
>>>
>>>             At the moment, the model I have described including the
>>>             data flows is clear. The discovery information made
>>>             available by a RS is clear.
>>>             I have not listed all its properties/characteristics of
>>>             that model, but I am pretty sure that you already have a
>>>             flavour of it.
>>>
>>>               * the case of the relaying of one operation by one RS
>>>                 to a second RS (if it is in the scope of your document),
>>>               * the case where access tokens from two GSs are needed
>>>                 by one RS (if it is in the scope of your document).
>>>
>>>
>>>         See above
>>>
>>>              *
>>>
>>>
>>>             Denis
>>>
>>>>             Hi Denis
>>>>
>>>>             I think it would be useful to take a step back and for
>>>>             you to describe your use case.
>>>>             After that, we can explore the different ways that your
>>>>             use case can be addressed.
>>>>
>>>>             Looking at your previous communication, it describes
>>>>             the solution, and the justification,
>>>>             On Wed, Jul 22, 2020 at 9:34 AM Denis
>>>>                 I have identified the reason of the major
>>>>                 difference between our two approaches.
>>>>
>>>>                 You are advocating a Capabilities approach while I
>>>>                 am advocating an ACL approach.
>>>>
>>>>                 The capabilities approach allows the GS to trace
>>>>                 every operation performed by the users on any RS
>>>>                 known by a GS.
>>>>                 The management of these capabilities is made via
>>>>                 the GS or at the GS by the various ROs. If the
>>>>                 management is made
>>>>                 via the GS, then a trusted communication channel
>>>>                 needs to be established with every RO. If the
>>>>                 management is made
>>>>                 at the GS, then an authentication mechanism needs
>>>>                 to be established with every RO. In the last case,
>>>>                 the GS has the
>>>>                 whether they are used or not. The less that can be
>>>>                 said is that this model
>>>>                 is not privacy friendly.
>>>>
>>>>                 placed in front of each RS. The AccessControl
>>>>                 Decision Function
>>>>                 decisions. The GS is kept ignorant of the content
>>>>                 of these ACLs and only
>>>>                 delivers to its clients attributes that are placed
>>>>                 into access tokens. Such a model may be privacy
>>>>                 friendly.
>>>>
>>>>>>                         It is clear that the "User consent and
>>>>>>                         choice" is not currently addressed in the
>>>>>>                         draft, but it should.
>>>>>>                         The support of the "User consent and
>>>>>>                         choice" has strong implications not only
>>>>>>                         in the sequences of the exchanges
>>>>>                     "Consent" is present 5 times. The User consent
>>>>>                     is different from the RO consent (when/if it
>>>>>                     is required).
>>>>>
>>>>>                         User consent is *often required* at the
>>>>>                         GS. GNAP enables a Client and  GS to
>>>>>                         negotiate the interaction mode for the GS
>>>>>                         to obtain consent.
>>>>>
>>>>>                         The GS *may *require explicit consent from
>>>>>                         the RO or User to provide these to the Client.
>>>>>
>>>>>                     The User consent is not an alternative to the
>>>>>                     RO consent. So using "and/or" in the first
>>>>>                     sentence is incorrect.
>>>>>
>>>>>
>>>>>                 My language is sloppy there. Consent is always
>>>>>                 from the RO. The User may be the RO.
>>>>
>>>>                 different from what you call the "/RO consent/"
>>>>                 (when/if it is required).
>>>>                 release of a capability to a client by one of the
>>>>                 many R0s with which
>>>>>                     "often required" there is no requirement to
>>>>>                     get the User consent.
>>>>>
>>>>>                 User consent may not be required. There may not be
>>>>>                 a User. The consent may have been gathered previously.
>>>>
>>>>                 [Denis] In order to follow the privacy principles,
>>>>                 a "User consent" phase is required. The User is a
>>>>                 natural person.
>>>>>                 Agreed. But we do agree that the GS gets the
>>>>>                 consent, either directly from the RO, or from the
>>>>>                 Client (in your example).
>>>>
>>>>                 [Denis] No. I disagree. In an ACL based systems,
>>>>                 the GS does not need to ask or receive any consent.
>>>>                 The client selects the set of attributes that it
>>>>                 wants to be inserted into an access token.
>>>>                 If the GS has the requested attributes, then it
>>>>                 provides them, otherwise it returns an error to the
>>>>                 Client.
>>>>
>>>>>                     The information used to obtain the User
>>>>>                     consent should be standardized (... and it can
>>>>>                     be standardized).
>>>>>
>>>>>>                     Francis is a great addition, and would
>>>>>>                     clarify where consent is in the sequence.
>>>>>
>>>>>                     The current sketch does not illustrate the
>>>>>                     place the User Consent is captured, in
>>>>>                     particular by the Client.
>>>>>
>>>>>                 It is an abstraction. The GS receives the consent.
>>>>>                 How consent is gathered is a detail that is
>>>>>                 dependent on the use case.
>>>>
>>>>                 "consent" to be received by the GS in both cases
>>>>                 (i.e. ACLs or Capabilities).
>>>>
>>>>                   * For Capabilities, the current description is
>>>>                     not clear since the inputs and the outputs for
>>>>                     this "consent" phase
>>>>>>                         assurance can only be obtained if the
>>>>>>                         access token returned to the client
>>>>>>                         is not considered to be opaque to the
>>>>>>                         client. This is a necessary condition but
>>>>>>                         not the single condition:
>>>>>>                         capture/memorize the "User consent and
>>>>>>                         choice" of the user in order to be able
>>>>>>                     We disagree on this being a requirement for
>>>>>>                     all use cases. It may be in some.
>>>>>
>>>>>                 For OAuth use cases, which GNAP supports, the
>>>>>                 access token is opaque to the Client. As you have
>>>>>                 noted, there are use cases where the access token
>>>>>                 is NOT opaque.
>>>>
>>>>                 I believe that there is a requirement to support
>>>>                 OAuth 2.0 ASs, while the clients may be different
>>>>                 and hence GNAP clients do not need to inherit of
>>>>                 the limitations of OAuth 2.0 clients.
>>>>
>>>>>>>
>>>>>>                         How could a GS know that "the User is the
>>>>>>                         RO" ?  If "the User is the RO", why does
>>>>>>                         the GS needs to query the User ?
>>>>>>
>>>>>>
>>>>>>                     To get consent?
>>>>>
>>>>>                 User, then consent from the RO is equivalent to
>>>>>                 consent from the User.
>>>>
>>>>                 [Denis] See above.
>>>>
>>>>>
>>>>>>>                         If the RO is a separate entity, then the
>>>>>>>                         GS knows the RO from the RS being queried.
>>>>>>
>>>>>>                          ... and this gives the ability for the
>>>>>>                         GS to log/trace all the RSs accessed by a
>>>>>>                         given User and at which instant of time
>>>>>>>                         An example is a user would like access
>>>>>>>                         to an enterprise asset where a workflow
>>>>>>>                         is started to gain approval, and an
>>>>>>                         Thanks for this example. I finally
>>>>>>                         understand what you have in mind: you are
>>>>>>                         considering using an access control model
>>>>>>                         to build a *workflow model*.
>>>>>>                         as a *separate and different work item*.
>>>>>>
>>>>>>
>>>>>                     I am glad you agree with this. But this means
>>>>>                     that your example was not appropriate to
>>>>>                     illustrate your point.
>>>>>
>>>>>
>>>>>                 It illustrates a use case where the RO and User
>>>>>                 are not the same party, and why the GS needs to
>>>>>                 query the RO, which was your question if I
>>>>>                 understood it correctly.
>>>>
>>>>                 [Denis] Since the inputs and the outputs for this
>>>>                 "RO consent" phase are not currently described in
>>>>                 the draft, the point is still unsolved.
>>>>
>>>>>                     As soon as there is a RO consent obtained at
>>>>>                     the GS, the major problem is that the GS is
>>>>>                     able to act as Big Brother.
>>>>>                     If a RO consent is performed at the RS, then
>>>>>                     the GS will not know who the RS is: it is then
>>>>>                     unable to act as Big Brother,
>>>>>                 In an enterprise use case, the GS's knowledge of
>>>>>                 who is accessing which RS is a feature.
>>>>
>>>>                 Do you mean that it is "normal" in an enterprise
>>>>                 that a single point of control is able to trace all
>>>>                 their actions ?
>>>>                 From a security point of view, a single point of
>>>>                 failure will have dramatic consequences.
>>>>
>>>>                 I do hope that you have finally understood that, in
>>>>                 my use case, the RO is **not** the User.
>>>>
>>>>>                 The GS knows the User is wanting to let a Client
>>>>>                 access something. If the access token is generic,
>>>>>                 and could be presented to any RS that provides a
>>>>>                 standardized function,
>>>>>                 then the GS does not know which RS is being
>>>>>                 accessed by a Client for the User. This seems to
>>>>>                 meet your privacy objectives. If not, what is wrong?
>>>>
>>>>                 identifier of the RS shall be included into the
>>>>                 access token).
>>>>
>>>>>>                         The model you propose may be suited for
>>>>>>                         an enterprise environment but is not
>>>>>>                         scalable over the Internet.
>>>>>>
>>>>>>                         usable over the Internet with millions of
>>>>>>                         RSs and thousands of ASs/GSs.
>>>>>>
>>>>>                         The flow starts with the steps (1) to (4)
>>>>>                         as illustrated by Francis, i.e. the flow
>>>>>                         starts with a contact with a RS.
>>>>>
>>>>>                     Furthermore, it is possible to prevent the GS
>>>>>                     to act as Big Brother when the identity of the
>>>>>                     RS is not disclosed to the GS.
>>>>>
>>>>>
>>>>                 [Denis] The key point is that we first need to
>>>>                 agree on the first four exchanges. Do we ?
>>>>
>>>>>>                         Access control has been defined a long
>>>>>>                         time ago and the last edition of the
>>>>>>                         model has been confirmed in year 1996:
>>>>>>                         ISO/IEC 10181-3: 1996.
>>>>>>                         Interconnection — Security frameworks for
>>>>>>                         open systems: Access control framework —
>>>>>>                         Part 3".
>>>>>>
>>>>>>                         AccessControl Enforcement Function (AEF)
>>>>>>                         and an AccessControl Decision Function(ADF).
>>>>>>
>>>>>>                             or that retained from prior
>>>>>>                             decisions), and the context in which
>>>>>>                         The role of the RO is to define the
>>>>>>                         "access control policy rules" at the RS
>>>>>>                         according to thecontext in which the
>>>>>>                         access request is made.
>>>>>>
>>>>>>                     I would say that the access control is
>>>>>>                     happening at the RS. The client presents a
>>>>>>                     token when accessing an API.
>>>>>                     No. We are no more in agreement. This is
>>>>>                     different from the flow drawn by Francis.
>>>>>
>>>>>>                     3) If access is granted, the GS creates an
>>>>>>                     access token representing the granted access,
>>>>>>                     and returns it to the Client.
>>>>>
>>>>>>                     4) The Client presents the access token to
>>>>>>                     the RS to show it has been granted access.
>>>>>
>>>>>                     No. The client presents a token when accessing
>>>>>                     an API. The RS uses the token, and any policy
>>>>>                 The Client presents the access token to the RS, to
>>>>>                 show the RS that the Client has been granted
>>>>>                 access to a resource at the RS by the GS.
>>>>
>>>>>>                     - the access token MAY be self contained so
>>>>>>                     that the Client does not need to query the GS
>>>>>>                     on each access.
>>>>>
>>>>>                 Darn: I clearly was not firing on all cylinders
>>>>>                 when I typed this out. Let me correct:
>>>>>
>>>>>>                 the RS does not need to query the GS on each
>>>>>>                 access to the RS by the Client.
>>>>
>>>>                     - for each GS, the RS needs to locally manage
>>>>                     which operation(s) is/are allowed to it.
>>>>
>>>>                     - the GS needs to establish a trusted
>>>>                     communication channel or an authentication
>>>>                     mechanism with each RO
>>>>                     - the GS could play the role of the RO and
>>>>                     hence be in a position to issue any capability
>>>>                     for any RS (without a "RO consent").
>>>>
>>>>>>                     I would not say that GNAP is an access
>>>>>>                     control protocol, as how the RS uses the
>>>>>>                     token to determine access is out of scope.
>>>>>
>>>>>                     This is where we have a major discrepancy: how
>>>>>                     the RS uses the token to determine access is
>>>>>                     *within* the scope.
>>>>>
>>>>>                     The RS announces in advance to the client what
>>>>>                     it needs so that the client can perform a a
>>>>>                     given operation and if the client supplies the
>>>>>                     requested attributes
>>>>>                     obtained from some GS/AS(s) trusted by the RS,
>>>>>                     then access to that RS is granted by the RS.
>>>>>                     If the RS cannot perform the requested
>>>>>                     operation on its own,
>>>>>                     requested attributes that need to be obtained
>>>>>                     from some GS/AS(s) trusted by the next RS(s)
>>>>>                     in a chain
>>>>>                     for subsequent operations. The User consent
>>>>>                     should also be obtained before performing the
>>>>>                     chaining operation.
>>>>>
>>>>>                     Chaining operations between RSs over the
>>>>>                     Internet is within the scope (... and may be
>>>>>                     achieved).
>>>>>
>>>>>                         OAuth initially assumed a static
>>>>>                         relationship between client, authorization
>>>>>                         server and resource servers. (...)
>>>>>                         access services of different providers (in
>>>>>                         case of standard APIs,
>>>>>                         such as e-mail or OpenID Connect) or serve
>>>>>                         as a frontend to a particular tenant in a
>>>>>                 This sentence does not mention the RO or the
>>>>>                 Client. I'm confused what we are talking about
>>>>>
>>>>>>>                         A client application would like access
>>>>>>>                         to the user's photos at a photo sharing
>>>>>>>                         site. The resource is the user's photos.
>>>>>>                         If the user has already pre established
>>>>>>                         the access control policy rules so that
>>>>>>                         it can access to his own photos
>>>>>>                     I don't understand what you are trying to
>>>>>>                     say. The photo sharing example was a driving
>>>>>>                     use case for the creation of OAuth.
>>>>>
>>>>>                     We would need to revisit the original scenario
>>>>>                     and consider if it can be addressed in a
>>>>>                     different way than the original way.
>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Jul 2020 09:59:51 -0700

Hi Denis

I did answer your question. The student is the User. The student is not the
Client.

ᐧ

On Tue, Jul 28, 2020 at 7:12 AM Denis <[email-masked]> wrote:

> Hi Dick,
>
> I am puzzled by your response. Your are the editor and a co-editor of the
> two following RFCs which state:
>
>                      (protected resource) on the server by authenticating
> with the server (...)
>
> In my use case, the student connects to the University server (i.e. a RS)
> as a client. The University server cannot be a Client.
> In summary, the University wants to consume Claims about the User, so it
> is the Client.
>
> /Dick
>
>
>
>> "the University's registration system is the Client, not a Resource Server"
>> ?
>>
>> Denis
>>
>> Hi Denis
>>
>>>> At the moment, draft-hardt-xauth-protocol-13 includes a single figure
>>>> on page 4 and from previous discussions I understood that
>>>> it is no more up-to-date since the first data flow is now a contact
>>>> with a RS. The reason(s) for the GS to contact a RO has still not
>>>>    - the case of the relaying of one operation by one RS to a second
>>>>    RS (if it is in the scope of your document),
>>>>    - the case where access tokens from two GSs are needed by one RS
>>>>> You are advocating a Capabilities approach while I am advocating an
>>>>> ACL approach.
>>>>>
>>>>> The management of these capabilities is made via the GS or at the GS
>>>>> by the various ROs. If the management is made
>>>>> [Denis] Wait a second. There is no requirement to support all OAuth
>>>>> use cases.
>>>>>>> An example is a user would like access to an enterprise asset where
>>>>>>> a workflow is started to gain approval, and an administrator or manager
>>>>>>> provides consent.
>>>>>>>
>>>>> party, and why the GS needs to query the RO, which was your question if I
>>>>> understood it correctly.
>>>>>
>>>>> Do you mean that it is "normal" in an enterprise that a single point
>>>>> of control is able to trace all their actions ?
>>>>> I do hope that you have finally understood that, in my use case, the
>>>>> RO is **not** the User.
>>>>>
>>>>>>> edition of the model has been confirmed in year 1996: ISO/IEC 10181-3:
>>>>>>> 1996.
>>>>>>> at the RS according to the context in which the access request is
>>>>>>> made.
>>>>>>>

---

From: Denis <[email-masked]>
Date: Tue, 28 Jul 2020 19:09:08 +0200

Hi Dick,

OK. I should have written that in my example: the student connects to 
the University server (i.e. a RS) *using* a client.

A client is a piece of software (supported by some hardware) that the 
user uses to interact with RS(s) and AS(s).

In a Client / Server model, the University Server cannot be a client: it 
is a server.

Nevertheless, my first question still remains: Would you explain how 
*you* would handle the use case of a student registering to a new 
University ?

Denis

> Hi Denis
>
> I did answer your question. The student is the User. The student is 
> not the Client.
>
> ᐧ
>
> On Tue, Jul 28, 2020 at 7:12 AM Denis <[email-masked] 
>     I am puzzled by your response. Your are the editor and a co-editor
>     of the two following RFCs which state:
>
>     RFC 6749:    In the traditional client-server authentication
>     model, the client requests an access-restricted resource
>     RFC 6750 : The client uses the access token to access the
>     protected resources hosted by the resource server.
>
>                         The following two steps are specified within
>     this document:
>
>                                    (E)  The client requests the
>     protected resource from the resource server and authenticates
>                                   (F)  The resource server validates
>     the access token, and if valid, serves the request.
>
>     In my use case, the student connects to the University server
>     (i.e. a RS) as a client. The University server cannot be a Client.
>     BTW, my first question still remains: Would you explain how you
>     would handle the use case of a student registering to a new
>     University ?
>
>     Denis
>
>>     Hi Denis
>>
>>     The student (User) goes to the registration page of the
>>     University (the Client)
>>
>>     In summary, the University wants to consume Claims about the
>>     User, so it is the Client.
>>
>>     /Dick
>>
>>
>>
>>         Would you explain how you would handle the use case of a
>>         student registering to a new University ?
>>
>>         Would you also elaborate why in my explanations below, you
>>         think that "the University's registration system is the
>>         Client, not a Resource Server" ?
>>
>>         Denis
>>
>>>         Hi Denis
>>>
>>>                 [Denis] How would be the data flow when access
>>>                 [Dick] I don't know of a use case where two tokens
>>>                 would be needed by an RS. Would you elaborate?
>>>
>>>             First, the student connects to the RS from the new
>>>             University and opens an account
>>>             (at this time the student is using a pseudo and a
>>>             private key to authenticate). He fills some forms
>>>             When he is finished, he indicates that he wants to
>>>             perform a Registration operation.
>>>
>>>             From the information gathered in the forms, the RS
>>>             informs the client that it needs two access tokens:
>>>
>>>               * one to demonstrate that his name and current home
>>>                 address are correct,and
>>>               * another one to demonstrate that he got a graduation
>>>                 from its current University.
>>>
>>>             Depending upon the information captured in the forms,
>>>             the RS also indicates which ASs/GSs are acceptable
>>>             The user consent and choice is performed by the client
>>>             and once approved by the student, two access tokens are
>>>             separately requested.
>>>             Note that the start of the story is to open an account,
>>>             e.g. using FIDO. The needs of the RS are only disclosed
>>>             to the student once he has filled some forms
>>>             operation. Thus, the needs that are revealed by the RS
>>>             are dependant both upon the operation
>>>             that the student is willing to perform and the
>>>             information collected in the forms.
>>>
>>>             Denis
>>>
>>>>             On Fri, Jul 24, 2020 at 9:08 AM Denis
>>>>                 without clearly stating what the problem(s) to be
>>>>                 solved is/are.
>>>>
>>>>
>>>>             I agree that the problem description is not as crisp as
>>>>             I would like it to be. A challenge is that there is a
>>>>             broad spectrum of use cases solved by OAuth 2, and
>>>>             OpenID Connect, as well as the new use cases that are
>>>>             solved by GNAP.
>>>>
>>>>             That is why I am suggesting we gather some use cases so
>>>>             we have a common understanding of the problems that are
>>>>             in scope.
>>>>
>>>>
>>>>                 At the moment, draft-hardt-xauth-protocol-13
>>>>                 includes a single figure on page 4 and from
>>>>                 previous discussions I understood that
>>>>                 it is no more up-to-date since the first data flow
>>>>                 is now a contact with a RS. The reason(s) for the
>>>>                 GS to contact a RO has still not
>>>>                 been explained (since the inputs and outputs are
>>>>                 not described). The discovery information made
>>>>                 available at various steps at the RS
>>>>                 is not described.
>>>>
>>>>
>>>>             I have made no updates as we are in a quiet period
>>>>             prior to the WG meeting next week when documents cannot
>>>>             be updated.
>>>>
>>>>
>>>>                 Figure 4 shows only a single RS. Is the relaying of
>>>>                 one operation by that RS to a second RS in the
>>>>                 scope of this document ?
>>>>             I view that as an advanced use case that would be
>>>>             covered in a separate document.
>>>>
>>>>
>>>>                 Figure 4 shows only a single GS. How would be the
>>>>                 data flow when access tokens from two GSs are
>>>>                 needed by a RS ?
>>>>
>>>>
>>>>             I don't know of a use case where two tokens would be
>>>>             The RS being able to accept tokens from two different
>>>>             GSes is covered, but the Client is only using a token
>>>>             from one GS at a time.
>>>>
>>>>
>>>>                 What we need first is not a set of "use cases" but
>>>>                 a clear model with a data flows and a list of its
>>>>             looking to solve. The data flows are part of the
>>>>             solution. For example, from my understanding of your
>>>>             use case, you don't want the GS to have visibility into
>>>>             the User's activity. Am I correct that this is one of
>>>>                 cases can/will be supported. For example, shall a
>>>>                 RS (or its RO) have
>>>>                 In order to have a fair comparison, we should try
>>>>                 to list model properties/characteristics.
>>>>
>>>>                 At the moment, the model I have described including
>>>>                 the data flows is clear. The discovery information
>>>>                 made available by a RS is clear.
>>>>                 I have not listed all its
>>>>                 properties/characteristics of that model, but I am
>>>>                 pretty sure that you already have a flavour of it.
>>>>
>>>>                   * the case of the relaying of one operation by
>>>>                     one RS to a second RS (if it is in the scope of
>>>>                     your document),
>>>>                   * the case where access tokens from two GSs are
>>>>                     needed by one RS (if it is in the scope of your
>>>>                     document).
>>>>
>>>>
>>>>             See above
>>>>
>>>>                  *
>>>>
>>>>
>>>>                 Denis
>>>>
>>>>>                 Hi Denis
>>>>>
>>>>>                 I think it would be useful to take a step back and
>>>>>                 for you to describe your use case.
>>>>>                 After that, we can explore the different ways that
>>>>>                 your use case can be addressed.
>>>>>
>>>>>                 Looking at your previous communication, it
>>>>>                 describes the solution, and the justification,
>>>>>                     Access control may be performed using either
>>>>>                     ACLs (Access Control Lists) or Capabilities.
>>>>>
>>>>>                     _Note _: a capability identifies a resource
>>>>>                     and an allowed operation that can be performed
>>>>>                     on that resource.
>>>>>
>>>>>                     You are advocating a Capabilities approach
>>>>>                     while I am advocating an ACL approach.
>>>>>
>>>>>                     The capabilities approach allows the GS to
>>>>>                     trace every operation performed by the users
>>>>>                     on any RS known by a GS.
>>>>>                     The management of these capabilities is made
>>>>>                     via the GS or at the GS by the various ROs. If
>>>>>                     the management is made
>>>>>                     via the GS, then a trusted communication
>>>>>                     channel needs to be established with every RO.
>>>>>                     If the management is made
>>>>>                     at the GS, then an authentication mechanism
>>>>>                     needs to be established with every RO. In the
>>>>>                     last case, the GS has the
>>>>>                     ability to know all the capabilities of the
>>>>>                     users whether they are used or not. The less
>>>>>                     that can be said is that this model
>>>>>                     is not privacy friendly.
>>>>>
>>>>>                     With the ACL approach, a RO directly manages
>>>>>                     an ACL placed in front of each RS. The
>>>>>                     AccessControl Decision Function
>>>>>                     (ADF) at the RS is able to keep track from
>>>>>                     prior decisions. The GS is kept ignorant of
>>>>>                     the content of these ACLs and only
>>>>>                     delivers to its clients attributes that are
>>>>>                     placed into access tokens. Such a model may be
>>>>>                     privacy friendly.
>>>>>
>>>>>>>>>                                     We are now close to an
>>>>>>>                             choice" has strong implications not
>>>>>>                         "Consent" is present 5 times. The User
>>>>>>                         consent is different from the RO consent
>>>>>>                             The GS *may *require explicit consent
>>>>>>                             from the RO or User to provide these
>>>>>>                             to the Client.
>>>>>>
>>>>>>                         The User consent is not an alternative to
>>>>>>                         the RO consent. So using "and/or" in the
>>>>>>                         first sentence is incorrect.
>>>>>>
>>>>>>
>>>>>>                     My language is sloppy there. Consent is
>>>>>>                     always from the RO. The User may be the RO.
>>>>>
>>>>>                     [Denis] No. Once again: The "/User consent/"
>>>>>                     is different from what you call the "/RO
>>>>>                     consent/" (when/if it is required).
>>>>>                     The "RO consent" is not in fact a consent but
>>>>>                     the release of a capability to a client by one
>>>>>                     of the many R0s with which
>>>>>>                         Since the second sentence is using the
>>>>>>                         wording "often required" there is no
>>>>>>                         requirement to get the User consent.
>>>>>>
>>>>>>                     User consent may not be required. There may
>>>>>>                     not be a User. The consent may have been
>>>>>>                     gathered previously.
>>>>>
>>>>>                     [Denis] In order to follow the privacy
>>>>>                     principles, a "User consent" phase is
>>>>>                     required. The User is a natural person.
>>>>>                     A Client is called either by a User (i.e. a
>>>>>                     natural person) or by a Client application.
>>>>>
>>>>>>                         possibility to get the User consent in a
>>>>>>                         place different from the GS.
>>>>>>
>>>>>>                     consent, either directly from the RO, or from
>>>>>>                     the Client (in your example).
>>>>>
>>>>>                     [Denis] No. I disagree. In an ACL based
>>>>>                     systems, the GS does not need to ask or
>>>>>                     receive any consent.
>>>>>                     The client selects the set of attributes that
>>>>>                     it wants to be inserted into an access token.
>>>>>                     If the GS has the requested attributes, then
>>>>>                     it provides them, otherwise it returns an
>>>>>                     error to the Client.
>>>>>
>>>>>>                         consent should be standardized (... and
>>>>>>                         it can be standardized).
>>>>>>
>>>>>>                         The current sketch does not illustrate
>>>>>>                         the place the User Consent is captured,
>>>>>>                         in particular by the Client.
>>>>>>
>>>>>>                     It is an abstraction. The GS receives the
>>>>>>                     consent. How consent is gathered is a detail
>>>>>>                     that is dependent on the use case.
>>>>>
>>>>>                     [Denis] I really wonder whether there is
>>>>>                     really a "consent" to be received by the GS in
>>>>>                     both cases (i.e. ACLs or Capabilities).
>>>>>
>>>>>                       * For Capabilities, the current description
>>>>>                         is not clear since the inputs and the
>>>>>                         outputs for this "consent" phase
>>>>>>>                         We disagree on this being a requirement
>>>>>>>                         for all use cases. It may be in some.
>>>>>>
>>>>>>                         "access tokens returned to the client are
>>>>>>                         not considered to be opaque to the client".
>>>>>>
>>>>>>
>>>>>>                     access token is opaque to the Client. As you
>>>>>>                     have noted, there are use cases where the
>>>>>>                     access token is NOT opaque.
>>>>>
>>>>>                     [Denis] Wait a second. There is no requirement
>>>>>                     to support all OAuth use cases.
>>>>>                     I believe that there is a requirement to
>>>>>                     support OAuth 2.0 ASs, while the clients may
>>>>>                     be different
>>>>>                     and hence GNAP clients do not need to inherit
>>>>>                     of the limitations of OAuth 2.0 clients.
>>>>>
>>>>>>>>
>>>>>>>>>                                     If a RO needs to be
>>>>>>                     The GS needs consent from the RO. If the RO
>>>>>>                     is the User, then consent from the RO is
>>>>>>                     equivalent to consent from the User.
>>>>>
>>>>>                     [Denis] See above.
>>>>>
>>>>>>
>>>>>>>                             accessed by a given User and at
>>>>>>>                             which instant of time the access
>>>>>>>                             token has been granted.
>>>>>>>
>>>>>>>>                             a workflow is started to gain
>>>>>>>>                             approval, and an administrator or
>>>>>>>                             understand what you have in mind:
>>>>>>                     It illustrates a use case where the RO and
>>>>>>                     User are not the same party, and why the GS
>>>>>>                     needs to query the RO, which was your
>>>>>                     [Denis] Since the inputs and the outputs for
>>>>>                     this "RO consent" phase are not currently
>>>>>                     described in the draft, the point is still
>>>>>                     unsolved.
>>>>>
>>>>>>                         As soon as there is a RO consent obtained
>>>>>>                         at the GS, the major problem is that the
>>>>>>                         GS is able to act as Big Brother.
>>>>>>                         If a RO consent is performed at the RS,
>>>>>>                         then the GS will not know who the RS is:
>>>>>>                         it is then unable to act as Big Brother,
>>>>>>                     In an enterprise use case, the GS's knowledge
>>>>>>                     of who is accessing which RS is a feature.
>>>>>
>>>>>                     Do you mean that it is "normal" in an
>>>>>                     enterprise that a single point of control is
>>>>>                     able to trace all their actions ?
>>>>>                     From a security point of view, a single point
>>>>>                     of failure will have dramatic consequences.
>>>>>
>>>>>                     I do hope that you have finally understood
>>>>>                     that, in my use case, the RO is **not** the User.
>>>>>
>>>>>>                     The GS knows the User is wanting to let a
>>>>>>                     Client access something. If the access token
>>>>>>                     is generic, and could be presented to any RS
>>>>>>                     that provides a standardized function,
>>>>>>                     accessed by a Client for the User. This seems
>>>>>>                     to meet your privacy objectives. If not, what
>>>>>>                     is wrong?
>>>>>
>>>>>                     For security reasons, an access token needs to
>>>>>                     be targeted (which does not necessarily mean
>>>>>                     that an identifier of the RS shall be included
>>>>>                     into the access token).
>>>>>
>>>>>>                         Furthermore, it is possible to prevent
>>>>>>                         the GS to act as Big Brother when the
>>>>>>                         identity of the RS is not disclosed to
>>>>>>                         the GS.
>>>>>>
>>>>>>
>>>>>>>>>                                     Which information is
>>>>>>>>>                                     supposed to be presented
>>>>>>>>>                                     to the RO ?
>>>>>>>>>                                     Which information is
>>>>>>>>>                                     supposed to be returned by
>>>>>>>>>                                     the RO ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                 Just like how the user
>>>>>>>                             Enforcement Function (AEF) and an
>>>>>>>                                 A specialized function that
>>>>>>>                                 makes access control decisions
>>>>>>>                                 by applying access control
>>>>>>>                                 policy rules to an access
>>>>>>>                                 request, ADI (of initiators,
>>>>>>>                                 decisions), and the context in
>>>>>>>                             "access control policy rules" at the
>>>>>>>                         happening at the RS. The client presents
>>>>>>>                         a token when accessing an API.
>>>>>>>                         3) If access is granted, the GS creates
>>>>>>>                         an access token representing the granted
>>>>>>>                         access, and returns it to the Client.
>>>>>>
>>>>>>>                         4) The Client presents the access token
>>>>>>>                         to the RS to show it has been granted
>>>>>>>                         access.
>>>>>>
>>>>>>                         No. The client presents a token when
>>>>>>                         accessing an API. The RS uses the token,
>>>>>>                         and any policy required, to make an
>>>>>>                         access decision.
>>>>>>                         The token never contains an information
>>>>>>                         like "Please grant an access to the
>>>>>>                         holder of this token".
>>>>>>
>>>>>>                     The Client presents the access token to the
>>>>>>                     RS, to show the RS that the Client has been
>>>>>>                     granted access to a resource at the RS by the GS.
>>>>>
>>>>>                     [Denis] This time, please consider both the
>>>>>                     ACLs approach and the Capabilities approach.
>>>>>
>>>>>>>                         - the access token MAY be self contained
>>>>>>>                         so that the Client does not need to
>>>>>>>                         query the GS on each access.
>>>>>>
>>>>>>                     Darn: I clearly was not firing on all
>>>>>>                     cylinders when I typed this out. Let me correct:
>>>>>>
>>>>>>>                     that the RS does not need to query the GS on
>>>>>>>                     each access to the RS by the Client.
>>>>>
>>>>>                         - for each GS, the RS needs to locally
>>>>>                         manage which operation(s) is/are allowed
>>>>>                         to it.
>>>>>
>>>>>                         hence be in a position to issue any
>>>>>                         capability for any RS (without a "RO
>>>>>                         consent").
>>>>>
>>>>>>                         This is where we have a major
>>>>>>                         discrepancy: how the RS uses the token to
>>>>>>                         The RS announces in advance to the client
>>>>>>                         what it needs so that the client can
>>>>>>                         perform a a given operation and if the
>>>>>>                         obtained from some GS/AS(s) trusted by
>>>>>>                         the RS, then access to that RS is granted
>>>>>>                         by the RS. If the RS cannot perform the
>>>>>>                         then the client should be informed about
>>>>>>                         some requested attributes that need to be
>>>>>>                         obtained from some GS/AS(s) trusted by
>>>>>>                         the next RS(s) in a chain
>>>>>>                         Internet is within the scope (... and may
>>>>>>                         be achieved).
>>>>>>
>>>>>>                             relationship between client,
>>>>>>>                         I don't understand what you are trying
>>>>>>>                         to say. The photo sharing example was a
>>>>>>>                         driving use case for the creation of OAuth.
>>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Jul 2020 14:08:10 -0700

Hi Denis

The Client / Server concept in GNAP (which it inherits from OAuth) is that
the Client is the thing that wants a resource, and the Server is the thing
that has the resource. Access to the resource is managed by the GS/AS.

So a web server that wants data from another server, is a Client.

*I* would solve the use case as I described (details on the RS / GS are
vague in the problem, so are vague in my solution)

On Tue, Jul 28, 2020 at 10:09 AM Denis <[email-masked]> wrote:

> Hi Dick,
>
> OK. I should have written that in my example: the student connects to the
> University server (i.e. a RS) *using* a client.
>
> A client is a piece of software (supported by some hardware) that the user
> uses to interact with RS(s) and AS(s).
>
> Nevertheless, my first question still remains: Would you explain how *you*
> would handle the use case of a student registering to a new University ?
>
> Denis
>
> Hi Denis
>
> I did answer your question. The student is the User. The student is not
> the Client.
>
> ᐧ
>
>>>> [Dick] I don't know of a use case where two tokens would be needed by
>>>> an RS. Would you elaborate?
>>>>
>>>> and indicate its citizenship, his home address and his graduation in
>>>> his current university.
>>>>
>>>> FIDO. The needs of the RS are only disclosed to the student once he has
>>>> filled some forms
>>>>> What we need first is not a set of "use cases" but a clear model with
>>>>> a data flows and a list of its properties/characteristics.
>>>>>
>>>>
>>>> understanding of your use case, you don't want the GS to have visibility
>>>> into the User's activity. Am I correct that this is one of your
>>>> requirements for your use case?
>>>>
>>>>
>>>>
>>>>> I have not listed all its properties/characteristics of that model,
>>>>> but I am pretty sure that you already have a flavour of it.
>>>>>
>>>>>> With the ACL approach, a RO directly manages an ACL placed in front
>>>>>> of each RS. The Access Control Decision Function
>>>>>>    - For Capabilities, the current description is not clear since
>>>>>>>> mind: you are considering using an access control model to build a *workflow
>>>>>>>> model*.
>>>>>> does not necessarily mean that an identifier of the RS shall be included
>>>>>> into the access token).
>>>>>>
>>>>>>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS
>>>>>>> |  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request     |
>>>>>>>> or that retained from prior decisions), and the context in which
>>>>>> I would not say that GNAP is an access control protocol, as how the
>>>>>>> RS uses the token to determine access is out of scope.
>>>>>>>
>>>>>>> RS is granted by the RS. If the RS cannot perform the requested operation
>>>>>>> on its own,