Subject: [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

From: Denis <[email-masked]>
Date: Mon, 3 Aug 2020 09:35:51 +0200

Hello Dick,

This is a follow-up of the thread: "Reviewing 
draft-hardt-xauth-protocol-11".

Hereafter are three exchanges between you and me which triggered this 
new thread:

    [Dick]    The photo sharing example was a driving use case for the
    creation of OAuth.
    [Denis]  We would need to revisit the original scenario and consider
    if it can be addressed in a different way than the original way.
    [Dick]   The use case is the same. Is there a different solution you
    are proposing ?

My response is : Yes indeed, I have a different solution to address the 
same use case.

RFC 6749 and draft-ietf-oauth-v2-1-00 both state:

    For example, an end-user (resource owner) can grant a printing
    service (client) access to her protected photos stored at
    a photo-sharing service (resource server), without sharing her
    username and password with the printing service. Instead,
    she authenticates directly with a server trusted by the
    photo-sharing service (authorization server), which issues the printing
    service delegation-specific credentials (access token).

There are no further explanations.

Which information will be disclosed by the resource owner to the 
authorization server to get "the printing service delegation-specific 
credentials"
is not described. It is a private agreement between the AS and the RS. 
It is more than likely that the authorization server will learn information
about which operation the resource owner is wishing to perform and 
where. Since in OAuth, the access token is supposed to be opaque to the 
Client,
the user will be unable to make sure that her instructions have been 
carefully followed.

RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do 
not contain a "Privacy Considerations" section.
Thus, the leakage of information to the AS is not discussed.

It is possible to revisit the original scenario by applying "Privacy by 
design" principles.

The scenario can be solved by using an old data transfer method that has 
been first described 32 years ago under the name
"Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years 
later in ISO/IEC 10740-2:1993.

RDT allows two servers to directly exchange large amounts of data under 
the supervision of a client by communicating, through the client,
a reference generated by one server to the other server. RDT does not 
use any Authorization Server (AS). This means that no AS is able
to act as Big Brother and this solves a major privacy concern.
*
The three entities involved
*
The Client supporting a User (was the Resource Owner).
The Photo-sharing service (was the Resource Server) : RS1.
The Printing service (was the client): RS2.
*
*

*Flow of operations with the Photo-sharing service (RS1)

*The Client first connects to the photo-sharing service (RS1) and the 
User authenticates to the photo-sharing service (RS1).

RS1 to User: "Please select the operation to be performed".
Operation selected: "Print pictures using a third party printing service".

RS1 to User: "Please select a set of pictures to be printed".
The User selects the pictures.

RS 1 User consent: "Do you agree RS1 to communicate your selection of 
pictures to a third party printing service" ?
If the User consents, RS1 to Client: "Here is the reference to be used 
by your printing service to get the selected pictures".
*
Flow of operations with the Printing service* (*RS2)
*
The Client connects to the printing service (RS2) and the User 
authenticates to the printing service (RS2).

_Note_: This allows to make sure that the user has an account on RS2 so 
that further operations can be charged to this account
                       and that the prints can be sent to a known address.

RS2 to User: "Please select the operation to be performed".
Operation : "Print pictures to be received from a photo-sharing service ".
RS2 to User: "Please indicate your photo-sharing service".
The User responds: RS1.

"Please enter the reference to be used by RS2 to receive the set of 
pictures from RS1".
The Client (or the User) enters the reference generated by RS1.

RS2 contacts RS1 using that reference in order to get the 
characteristics and the thumbnails of the pictures to be printed (i.e. 
not yet the whole pictures).

RS2 to client: What are your printing preferences for each picture (e.g. 
number of prints, size, quality of the paper, resolution, margins, 
colours, etc... ) ?
The User responds to all these questions.

RS 2 User consent: This operation will be charged XX € ? Do you agree ?
If the payment needs to be done on-line, then a payment phase is inserted.
*
Continuation of the flow of operations

*Final message from RS1 to the Client: "Your selection of pictures will 
be soon transmitted to RS2".
Final message from RS2 to the Client: "Your prints will be soon on their 
way".

RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to 
this reference.
*
Some of the advantages of RDT*

 1. An end-user can grant a printing service (RS2) access to her
    protected photos stored at a photo-sharing service (RS1),
    without sharing her username and password with the printing service.
 2. Neither RS1, nor RS2 need to use or to trust any AS. This solves the
    Big Brother privacy issue.
 3. Any authentication method supported by RS1 or RS2 can be used by the
    User.
 4. The User can use any photo-sharing service (RS1) with any printing
    service (RS2), as long as they both support RDT.
 5. The User consent is first performed with the photo-sharing service
    (RS1) and then after with the printing service (RS2).
 6. The reference generated by RS1 will only be accepted by RS1 during a
    time period.
 7. The reference generated by RS1 allows RS2 to query first the
    thumbnails and then after the pictures selected by the User at RS1.
 8. The data transfer of the pictures selected at RS1 by the User is
    performed asynchronously from RS1 to RS2 as a back-office operation.

*Questions*: What would be the full scenario of this use case using 
OAuth ? What about Privacy Considerations ?

Denis

---

From: Dick Hardt <[email-masked]>
Date: Mon, 3 Aug 2020 10:14:52 -0700

Hi Denis

In your proposed flow, how does RS2 know who the user is that it is dealing
with? In OAuth, the AS authenticates the User for the RS. In the photo
sharing example, the AS and RS are from the same organization, so the AS
knowing what the RS was doing was not an issue.

What you call a Client is not an OAuth Client, but is more of an agent for
the User. Microsoft InfoCards comes to mind as a comparable architecture,
and it seems aligned with what Tom is asking for.

On Mon, Aug 3, 2020 at 12:35 AM Denis <[email-masked]> wrote:

> Hereafter are three exchanges between you and me which triggered this new
> thread:
>
> [Denis]  We would need to revisit the original scenario and consider if it
> can be addressed in a different way than the original way.
> [Dick]   The use case is the same. Is there a different solution you are
> proposing ?
>
> For example, an end-user (resource owner) can grant a printing service
> (client) access to her protected photos stored at
> a photo-sharing service (resource server), without sharing her username
> and password with the printing service. Instead,
> she authenticates directly with a server trusted by the photo-sharing
> service (authorization server), which issues the printing
> is not described. It is a private agreement between the AS and the RS. It
> is more than likely that the authorization server will learn information
> about which operation the resource owner is wishing to perform and where.
> Since in OAuth, the access token is supposed to be opaque to the Client,
> "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later
> in ISO/IEC 10740-2:1993.
>
> a reference generated by one server to the other server. RDT does not use
> any Authorization Server (AS). This means that no AS is able
> * The three entities involved *
> *Flow of operations with the Photo-sharing service (RS1) *The Client
> first connects to the photo-sharing service (RS1) and the User
> authenticates to the photo-sharing service (RS1).
>
> If the User consents, RS1 to Client: "Here is the reference to be used by
> your printing service to get the selected pictures".
>
> * Flow of operations with the Printing service* (
> *RS2) *
>             *Note*: This allows to make sure that the user has an account
> on RS2 so that further operations can be charged to this account
> RS2 contacts RS1 using that reference in order to get the characteristics
> and the thumbnails of the pictures to be printed (i.e. not yet the whole
> pictures).
>
> number of prints, size, quality of the paper, resolution, margins, colours,
> etc... ) ?
> * Continuation of the flow of operations *Final message from RS1 to the
> Client: "Your selection of pictures will be soon transmitted to RS2".
> * Some of the advantages of RDT*
>
>    2. Neither RS1, nor RS2 need to use or to trust any AS. This solves
>    the Big Brother privacy issue.
>    3. Any authentication method supported by RS1 or RS2 can be used by
>    the User.
>    6. The reference generated by RS1 will only be accepted by RS1 during
>    a time period.
> *Questions*: What would be the full scenario of this use case using OAuth
> ? What about Privacy Considerations ?
>
> Denis
>
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 3 Aug 2020 15:02:11 -0400

Hi Denis,

I think there’s still a problem with the terminology in use here. What you describe as RS2, which might in fact be an RS unto itself, is a “Client” in OAuth parlance because it is a client of RS1. What you call a “client” has no analogue in the OAuth world, but it is not at all the same as an OAuth client. I appreciate your mapping of the entities below, but it makes it difficult to hold a discussion if we aren’t using the same terms.

The good news is that this isn’t OAuth, and as a new WG we can define our own terms. The bad news is that this is really hard to do.

In GNAP, we shouldn’t just re-use existing terms with new definitions, but we’ve got a chance to be more precise with how we define things. This could mean splitting up things into multiple roles, or defining new roles for aspects that weren’t in consideration in the protocol previously. Perhaps what you’re calling a client below could potentially be considered the “interaction component” or “consent gatherer”, which was previously a portion of the AS. 

I’ve never been a fan of the term “client” in OAuth because it’s too generic and confusing to a lot of developers, especially the web programmers that OAuth is aimed at. “User Agent” would be similarly unsuitable for the same reasons — both “client” and “user agent” are taken to mean “browser” in many circles. I’d love for us to come up with a new term for this, but apart from the “Resource Client (RC)” that I proposed in the XYZ Draft, I don’t have an answer.

 — Justin

> On Aug 3, 2020, at 3:35 AM, Denis <[email-masked]> wrote:
> 
> Hello Dick,
> 
> 
> This is a follow-up of the thread: "Reviewing draft-hardt-xauth-protocol-11".
> 
> Hereafter are three exchanges between you and me which triggered this new thread:
> 
> [Dick]    The photo sharing example was a driving use case for the creation of OAuth.
> [Denis]  We would need to revisit the original scenario and consider if it can be addressed in a different way than the original way.
> [Dick]   The use case is the same. Is there a different solution you are proposing ?
> 
> My response is : Yes indeed, I have a different solution to address the same use case.
> 
> For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at 
> a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead, 
> she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing 
> Which information will be disclosed by the resource owner to the authorization server to get "the printing service delegation-specific credentials" 
> is not described. It is a private agreement between the AS and the RS. It is more than likely that the authorization server will learn information 
> about which operation the resource owner is wishing to perform and where. Since in OAuth, the access token is supposed to be opaque to the Client, 
> the user will be unable to make sure that her instructions have been carefully followed.  
> 
> RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they do not contain a "Privacy Considerations" section. 
> It is possible to revisit the original scenario by applying "Privacy by design" principles. 
> 
> The scenario can be solved by using an old data transfer method that has been first described 32 years ago under the name 
> "Referenced Data Transfer (RDT)" in ECMA-131 (1988) and a few years later in ISO/IEC 10740-2:1993.
> 
> RDT allows two servers to directly exchange large amounts of data under the supervision of a client by communicating, through the client, 
> a reference generated by one server to the other server. RDT does not use any Authorization Server (AS). This means that no AS is able 
> Flow of operations with the Photo-sharing service (RS1)
> 
> The Client first connects to the photo-sharing service (RS1) and the User authenticates to the photo-sharing service (RS1).
> 
> RS 1 User consent: "Do you agree RS1 to communicate your selection of pictures to a third party printing service" ?
> If the User consents, RS1 to Client: "Here is the reference to be used by your printing service to get the selected pictures".
> 
> Flow of operations with the Printing service (RS2)
> 
> The Client connects to the printing service (RS2) and the User authenticates to the printing service (RS2).
> 
>             Note: This allows to make sure that the user has an account on RS2 so that further operations can be charged to this account 
> "Please enter the reference to be used by RS2 to receive the set of pictures from RS1".
> RS2 contacts RS1 using that reference in order to get the characteristics and the thumbnails of the pictures to be printed (i.e. not yet the whole pictures). 
> 
> RS2 to client: What are your printing preferences for each picture (e.g. number of prints, size, quality of the paper, resolution, margins, colours, etc... ) ?
> Final message from RS1 to the Client: "Your selection of pictures will be soon transmitted to RS2".
> Final message from RS2 to the Client: "Your prints will be soon on their way".
> 
> RS2 to RS1 (asynchronous): transmit the set of pictures corresponding to this reference.
> 
> Some of the advantages of RDT
> 
> An end-user can grant a printing service (RS2) access to her protected photos stored at a photo-sharing service (RS1),
> Neither RS1, nor RS2 need to use or to trust any AS. This solves the Big Brother privacy issue.
> Any authentication method supported by RS1 or RS2 can be used by the User.
> The User can use any photo-sharing service (RS1) with any printing service (RS2), as long as they both support RDT.
> The User consent is first performed with the photo-sharing service (RS1) and then after with the printing service (RS2).
> The reference generated by RS1 will only be accepted by RS1 during a time period.
> The reference generated by RS1 allows RS2 to query first the thumbnails and then after the pictures selected by the User at RS1.
> The data transfer of the pictures selected at RS1 by the User is performed asynchronously from RS1 to RS2 as a back-office operation.
> Questions: What would be the full scenario of this use case using OAuth ? What about Privacy Considerations ?
> 
> Denis
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Tom Jones <[email-masked]>
Date: Mon, 3 Aug 2020 14:16:24 -0700

In our use cases the client and rs are indistinguishable other than one is
a source and the other a sink of data. They can reverse roles rapidly. I
agree that client is not a helpful name.
Peace ..tom

On Mon, Aug 3, 2020 at 12:02 PM Justin Richer <[email-masked]> wrote:

> Hi Denis,
>
> I think there’s still a problem with the terminology in use here. What you
> describe as RS2, which might in fact be an RS unto itself, is a “Client” in
> OAuth parlance because it is *a client of RS1*. What you call a “client”
> has no analogue in the OAuth world, but it is not at all the same as an
> OAuth client. I appreciate your mapping of the entities below, but it makes
> it difficult to hold a discussion if we aren’t using the same terms.
>
> The good news is that this isn’t OAuth, and as a new WG we can define our
> own terms. The bad news is that this is really hard to do.
>
> In GNAP, we shouldn’t just re-use existing terms with new definitions, but
> we’ve got a chance to be more precise with how we define things. This could
> mean splitting up things into multiple roles, or defining new roles for
> aspects that weren’t in consideration in the protocol previously. Perhaps
> what you’re calling a client below could potentially be considered the
> “interaction component” or “consent gatherer”, which was previously a
> portion of the AS.
>
> I’ve never been a fan of the term “client” in OAuth because it’s too
> generic and confusing to a lot of developers, especially the web
> programmers that OAuth is aimed at. “User Agent” would be similarly
> unsuitable for the same reasons — both “client” and “user agent” are taken
> to mean “browser” in many circles. I’d love for us to come up with a new
> term for this, but apart from the “Resource Client (RC)” that I proposed in
> the XYZ Draft, I don’t have an answer.
>
>  — Justin
>

---

From: Denis <[email-masked]>
Date: Tue, 4 Aug 2020 11:28:03 +0200

Hi Dick,

> Hi Denis
>
> In your proposed flow, how does RS2 know who the user is that it is 
> dealing with?

The response is in the text: "The Client connects to the printing 
service (RS2) and the User authenticates to the printing service (RS2)".

> In OAuth, the AS authenticates the User for the RS. In the photo 
> sharing example, the AS and RS are from the same organization, so the 
> AS knowing what the RS was doing was not an issue.

Nevertheless, a full description is still missing and might help to 
better understand the privacy issues.

> What you call a Client is not an OAuth Client, but is more of an agent 
> for the User.

RFC 6749 states:

    In OAuth, the client requests access to resources controlled by the
    resource owner and hosted by the resource server,
    and is issued a different set of credentials than those of the
    resource owner.

This is how I use the term client which fits with the Client-Server model.

However, RFC 6749 also states in section 1.1 (Roles) :

    client
           An application making protected resource requests on behalf
    of the resource owner and with its authorization.

This is clearly not how I use the term client.

The term "User Agent" might grasp the concept, but I clearly like better 
the term "Client",
as long as we define the use of this term in the context of GNAP.

Denis

> Microsoft InfoCards comes to mind as a comparable architecture, and it 
> seems aligned with what Tom is asking for.
>
>
>
>
>
> On Mon, Aug 3, 2020 at 12:35 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello Dick,
>
>         [Denis]  We would need to revisit the original scenario and
>         consider if it can be addressed in a different way than the
>         original way.
>     authorization server to get "the printing service
>     delegation-specific credentials"
>     is not described. It is a private agreement between the AS and the
>     RS. It is more than likely that the authorization server will
>     learn information
>     where. Since in OAuth, the access token is supposed to be opaque
>     to the Client,
>     RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point:
>     they do not contain a "Privacy Considerations" section.
>     The scenario can be solved by using an old data transfer method
>     that has been first described 32 years ago under the name
>     RDT allows two servers to directly exchange large amounts of data
>     under the supervision of a client by communicating, through the
>     client,
>     a reference generated by one server to the other server. RDT does
>     not use any Authorization Server (AS). This means that no AS is able
>     *The Client first connects to the photo-sharing service (RS1) and
>     the User authenticates to the photo-sharing service (RS1).
>
>     RS 1 User consent: "Do you agree RS1 to communicate your selection
>     of pictures to a third party printing service" ?
>     If the User consents, RS1 to Client: "Here is the reference to be
>     used by your printing service to get the selected pictures".
>     *
>     _Note_: This allows to make sure that the user has an account on
>     RS2 so that further operations can be charged to this account
>     characteristics and the thumbnails of the pictures to be printed
>     (i.e. not yet the whole pictures).
>
>     RS2 to client: What are your printing preferences for each picture
>     (e.g. number of prints, size, quality of the paper, resolution,
>     margins, colours, etc... ) ?
>     *Final message from RS1 to the Client: "Your selection of pictures
>     will be soon transmitted to RS2".
>      2. Neither RS1, nor RS2 need to use or to trust any AS. This
>         solves the Big Brother privacy issue.
>      3. Any authentication method supported by RS1 or RS2 can be used
>         by the User.
>      4. The User can use any photo-sharing service (RS1) with any
>         printing service (RS2), as long as they both support RDT.
>      5. The User consent is first performed with the photo-sharing
>         service (RS1) and then after with the printing service (RS2).
>      6. The reference generated by RS1 will only be accepted by RS1
>         during a time period.
>      8. The data transfer of the pictures selected at RS1 by the User
>         is performed asynchronously from RS1 to RS2 as a back-office
>         operation.
>
>     *Questions*: What would be the full scenario of this use case
>     using OAuth ? What about Privacy Considerations ?
>
>     Denis
>

---

From: Denis <[email-masked]>
Date: Tue, 4 Aug 2020 11:31:34 +0200

Hi Justin,

Since you replied in parallel, I will make a response similar to the one 
I sent to Dick.

> Hi Denis,
>
> I think there’s still a problem with the terminology in use here. What 
> you describe as RS2, which might in fact be an RS unto itself, is a 
> “Client” in OAuth parlance because it is /a client of RS1/. What you 
> call a “client” has no analogue in the OAuth world, but it is not at 
> all the same as an OAuth client. I appreciate your mapping of the 
> entities below, but it makes it difficult to hold a discussion if we 
> aren’t using the same terms.
>
> The good news is that this isn’t OAuth, and as a new WG we can define 
> our own terms. The bad news is that this is really hard to do.
>
> In GNAP, we shouldn’t just re-use existing terms with new definitions, 
> but we’ve got a chance to be more precise with how we define things.

In the ISO context, each document must define its own terminology. The 
boiler plate for RFCs does not mandate a terminology or definitions section
but does not prevent it either. The vocabulary is limited and as long as 
we clearly define what our terms are meaning, we can re-use a term already
used in another RFC. This is also the ISO approach.

> This could mean splitting up things into multiple roles, or defining 
> new roles for aspects that weren’t in consideration in the protocol 
> previously.
> Perhaps what you’re calling a client below could potentially be 
> considered the “interaction component” or “consent gatherer”, which 
> was previously a portion of the AS.
>
> programmers that OAuth is aimed at.

If the term “client” in OAuth should be understood as defined in in 
section 1.1 (Roles) from RFC 6749, i.e.:

    client : An application making protected resource requests on behalf
    of the resource owner and with its authorization.

then this term is clearly not compatible with the term client from the 
Client-Server model.

> “User Agent” would be similarly unsuitable for the same reasons — both 
> “client” and “user agent” are taken to mean “browser” in many circles.

Maybe, but it is not my understanding.

> I’d love for us to come up with a new term for this, but apart from 
> the “Resource Client (RC)” that I proposed in the XYZ Draft, I don’t 
> have an answer.

By best answer is to use the term Client for what it means in the 
context of a Client-Server model.

Hereafter are two ISO definitions:

    client : entity that requests a service from a server (ISO/IEC
    14776-414:2009, 3.1.16)

    client application: software application that accesses a remote
    service usually on another computer system (ISO 24619:2011, 3.3.5)

Denis

>
>  — Justin
>
>> On Aug 3, 2020, at 3:35 AM, Denis <[email-masked] 
>> RS. It is more than likely that the authorization server will learn 
>> information
>> where. Since in OAuth, the access token is supposed to be opaque to 
>> the Client,
>> RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common point: they 
>> do not contain a "Privacy Considerations" section.
>> The scenario can be solved by using an old data transfer method that 
>> has been first described 32 years ago under the name
>> under the supervision of a client by communicating, through the client,
>> _Note_: This allows to make sure that the user has an account on RS2 
>> so that further operations can be charged to this account
>> [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Tue, 4 Aug 2020 11:51:45 -0400

That’s exactly why “client” and “RS” need to be thought of as a “role” and not an “entity”. An entity can have several roles, and they’re all about context.

The “client” role is always the “client” regardless of whether the entity being the “client” can also be an “RS” in another context milliseconds later.

 — Justin

> On Aug 3, 2020, at 5:16 PM, Tom Jones <[email-masked]> wrote:
> 
> In our use cases the client and rs are indistinguishable other than one is a source and the other a sink of data. They can reverse roles rapidly. I agree that client is not a helpful name.
> Peace ..tom
> 
> 
> On Mon, Aug 3, 2020 at 12:02 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Denis,
> 
>> On Aug 3, 2020, at 3:35 AM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello Dick,
>> 
>> 
>> RS2 to User: "Please indicate your photo-sharing service"..
>> The User responds: RS1.
>> 
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> Txauth mailing list
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Tue, 4 Aug 2020 10:30:50 -0700

+1 to Client and RS being the roles they are playing in the protocol.
ᐧ

On Tue, Aug 4, 2020 at 8:51 AM Justin Richer <[email-masked]> wrote:

> That’s exactly why “client” and “RS” need to be thought of as a “role” and
> not an “entity”. An entity can have several roles, and they’re all about
> context.
>
> The “client” role is always the “client” regardless of whether the entity
> being the “client” can also be an “RS” in another context milliseconds
> later.
>
>  — Justin
>
>> “Client” in OAuth parlance because it is *a client of RS1*. What you
>> call a “client” has no analogue in the OAuth world, but it is not at all
>> the same as an OAuth client. I appreciate your mapping of the entities
>> below, but it makes it difficult to hold a discussion if we aren’t using
>> the same terms.
>>
>> but we’ve got a chance to be more precise with how we define things. This
>> could mean splitting up things into multiple roles, or defining new roles
>> for aspects that weren’t in consideration in the protocol previously.
>> Perhaps what you’re calling a client below could potentially be considered
>> the “interaction component” or “consent gatherer”, which was previously a
>> portion of the AS.
>>
>> [Denis]  We would need to revisit the original scenario and consider if
>> it can be addressed in a different way than the original way.
>>             *Note*: This allows to make sure that the user has an
>> account on RS2 so that further operations can be charged to this account

---

From: Dick Hardt <[email-masked]>
Date: Tue, 4 Aug 2020 10:34:38 -0700

Denis

I don't think it is productive to redefine terms that are well understood.

"The Client connects to the printing service (RS2) and the User
authenticates to the printing service (RS2)"

Does not answer the question of how the User authenticates to the RS. This
implies the user has an account at RS2. If that is the case, it is not just
acting in the role of a resource server.

/Dick

ᐧ

On Tue, Aug 4, 2020 at 2:28 AM Denis <[email-masked]> wrote:

> The response is in the text: "The Client connects to the printing service
> (RS2) and the User authenticates to the printing service (RS2)".
>
> In OAuth, the AS authenticates the User for the RS. In the photo sharing
> example, the AS and RS are from the same organization, so the AS
> Nevertheless, a full description is still missing and might help to better
> understand the privacy issues.
>
> and is issued a different set of credentials than those of the resource
> owner.
>
>       An application making protected resource requests on behalf of the
> resource owner and with its authorization.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 Aug 2020 11:53:13 -0700

Hi Denis,

> used in another RFC. This is also the ISO approach.

Just because we can do something does not necessarily mean that it is a
good idea to do so.  We are clear that we are producing a protocol that is
conceptually (if not more strongly) related to OAuth 2.0, and reusing terms
from OAuth 2.0 but with different definitions may lead to unnecessary
confusion.  If I understand correctly, a similar reasoning prompted Dick to
use the term "GS" in XAuth, picking a name that was not already used in
OAuth 2.0.

-Ben

---

From: Warren Parad <[email-masked]>
Date: Tue, 4 Aug 2020 21:32:34 +0200

I think that is fundamentally part of the question:

> We are clear that we are producing a protocol that is
> confusion

If we say that this document assumes OAuth2.0 terminology, then we should
not change the meanings of any definition. If we are saying this supersedes
or replaces what OAuth 2.0 creates, then we should pick the best word for
the job and ignore conflicting meanings from OAuth 2.0. I have a lot of
first hand experience of industries "ruining words", and attempting to
side-step the problem rather than redefining the word just confuses
everyone as everyone forgets the original meaning as new documents come
out, but the confusion with the use of a non-obvious word continues.

Food for thought.
- Warren

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 5 Aug 2020 01:15:37 +0200

+1 on making necessary changes. Keeping the status quo is a good idea only
if it fits with the new purpose of the work. Based on what we learned from
years of experience, I think we should be open to revising the terminology.

Fabien

---

From: Denis <[email-masked]>
Date: Wed, 5 Aug 2020 11:26:21 +0200

Hello Dick,
> I don't think it is productive to redefine terms that are well understood.

 From the discussion, it is obvious that the terms we want to use are 
not well defined, hence they can't be well understood.

If we were drafting an ISO standard, we would need to apply the ISO 
rules from the ISO/IEC Directives Part 2 [1] ,
called "Part 2 : Rules for the structure and drafting of International 
Standards".

    16.5.6    Definitions

    The definition shall be written in such a form that it can replace
    the term in its context.
    It shall not start with an article (“the”, “a”) nor end with a full
    stop.
    A definition shall not take the form of, or contain, a requirement.

For OAuth, the word "client" is used in section 1.1 (Roles) from RFC 
6749 with the following explanation.

    client
           An application making protected resource requests on behalf
    of the resource owner and with its authorization.
           [Other explanations follow ... ]

This explanation may be adequate in the context of OAuth but is clearly 
not compatible with the meaning of a client role
in a client-server model, since it relates to a "resource owner" which 
is a concept that does not necessarily exist in a
client-server model.

Since we want to focus on a User that is using a client application to 
interact with the outside elements of the model, hereafter
are two proposals:

    client application: application by means of which a user interacts
    with RS(s) and AS(s)

    user agent: application by means of which a user interactswith RS(s)
    and AS(s)

Note: I don't like that much "Resource Client" since it concatenates two 
contradictory terms.

> Does not answer the question of how the User authenticates to the RS. 
> This implies the user has an account at RS2.

It does answer to the question. As clearly explained, the User must have 
or must create an account at RS2: "This allows to make
sure that the user has an account on RS2 so that further operations can 
be charged to this account and that the prints can be sent
to a known address". As also clearly mentioned :"Any authentication 
method supported by RS1 or RS2 can be used by the User".

> If that is the case, it is not just acting in the role of a resource 
> server.

Your sentence does not allow to understand what you mean by "it".

You will notice that I answered to all your questions. However, I raised 
the two following questions which were left answered:

**Questions: What would be the full scenario of this use case using 
OAuth ? What about Privacy Considerations ?

Maybe you should take these questions in a more general sense:

    How would you solve the photo sharing example now ? What would be
    the full scenario ?
    What about the Privacy Considerations for such a solution ?

Denis

[1] https://www.iso.org/sites/directives/current/part2/index.xhtml

>
> /Dick
>
> ᐧ
>
> On Tue, Aug 4, 2020 at 2:28 AM Denis <[email-masked] 
>>     In your proposed flow, how does RS2 know who the user is that it
>>     is dealing with?
>
>>     sharing example, the AS and RS are from the same organization, so
>>     the AS knowing what the RS was doing was not an issue.
>
>     Nevertheless, a full description is still missing and might help
>     to better understand the privacy issues.
>
>>     What you call a Client is not an OAuth Client, but is more of an
>>     agent for the User.
>
>     RFC 6749 states:
>
>         In OAuth, the client requests access to resources controlled
>         by the resource owner and hosted by the resource server,
>               An application making protected resource requests on
>         behalf of the resource owner and with its authorization.
>
>     The term "User Agent" might grasp the concept, but I clearly like
>     better the term "Client",
>>     Microsoft InfoCards comes to mind as a comparable architecture,
>>             [Denis]  We would need to revisit the original scenario
>>             and consider if it can be addressed in a different way
>>             than the original way.
>>             For example, an end-user (resource owner) can grant a
>>             printing service (client) access to her protected photos
>>             stored at
>>             a photo-sharing service (resource server), without
>>             sharing her username and password with the printing
>>             service. Instead,
>>         Which information will be disclosed by the resource owner to
>>         the authorization server to get "the printing service
>>         is not described. It is a private agreement between the AS
>>         and the RS. It is more than likely that the authorization
>>         server will learn information
>>         about which operation the resource owner is wishing to
>>         perform and where. Since in OAuth, the access token is
>>         supposed to be opaque to the Client,
>>         RFC 6749 and draft-ietf-oauth-v2-1-00 both share a common
>>         point: they do not contain a "Privacy Considerations" section.
>>         The scenario can be solved by using an old data transfer
>>         method that has been first described 32 years ago under the name
>>         RDT allows two servers to directly exchange large amounts of
>>         data under the supervision of a client by communicating,
>>         through the client,
>>         a reference generated by one server to the other server. RDT
>>         does not use any Authorization Server (AS). This means that
>>         no AS is able
>>         *The Client first connects to the photo-sharing service (RS1)
>>         and the User authenticates to the photo-sharing service (RS1).
>>
>>         RS 1 User consent: "Do you agree RS1 to communicate your
>>         selection of pictures to a third party printing service" ?
>>         If the User consents, RS1 to Client: "Here is the reference
>>         to be used by your printing service to get the selected
>>         pictures".
>>         *
>>         The Client connects to the printing service (RS2) and the
>>         User authenticates to the printing service (RS2).
>>
>>         _Note_: This allows to make sure that the user has an account
>>         characteristics and the thumbnails of the pictures to be
>>         printed (i.e. not yet the whole pictures).
>>
>>         RS2 to client: What are your printing preferences for each
>>         picture (e.g. number of prints, size, quality of the paper,
>>         resolution, margins, colours, etc... ) ?
>>         *Final message from RS1 to the Client: "Your selection of
>>         pictures will be soon transmitted to RS2".
>>          1. An end-user can grant a printing service (RS2) access to
>>             her protected photos stored at a photo-sharing service (RS1),
>>          3. Any authentication method supported by RS1 or RS2 can be
>>             used by the User.
>>          5. The User consent is first performed with the
>>             photo-sharing service (RS1) and then after with the
>>             printing service (RS2).
>>          6. The reference generated by RS1 will only be accepted by
>>             RS1 during a time period.
>>          7. The reference generated by RS1 allows RS2 to query first
>>             the thumbnails and then after the pictures selected by
>>             the User at RS1.
>>          8. The data transfer of the pictures selected at RS1 by the
>>             User is performed asynchronously from RS1 to RS2 as a
>>             back-office operation.
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 5 Aug 2020 11:20:13 -0400

I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

GNAP can do something similar, in my opinion. But what we can’t do is ignore the fact that GNAP is going to be coming up in a world that is already permeated  by OAuth 2 and its terminology. We don’t have a blank slate to work with, but neither are we bound to use the same terms and constructs as before. It’s going to be a delicate balance!

 — Justin

> On Aug 4, 2020, at 3:32 PM, Warren Parad <[email-masked]> wrote:
> 
> If we say that this document assumes OAuth2.0 terminology, then we should not change the meanings of any definition. If we are saying this supersedes or replaces what OAuth 2.0 creates, then we should pick the best word for the job and ignore conflicting meanings from OAuth 2.0. I have a lot of first hand experience of industries "ruining words", and attempting to side-step the problem rather than redefining the word just confuses everyone as everyone forgets the original meaning as new documents come out, but the confusion with the use of a non-obvious word continues.
> 
> Food for thought.
> - Warren
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>.
> 
> 
> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Denis,
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 5 Aug 2020 17:59:03 -0700

Hi Denis

Thanks for the clarification. Please note that the terms Client, AS, RS are
the roles an entity plays. It is confusing when you say the User
authenticates at RS2, as that is not an action that a RS performs. I'd
suggest just using the entity and say what it does initially, and then we
can indicate when an entity changes roles.

Using OAuth 2.0 terms, the photo printing site is the Client, and the
photo storage site is both the RS and the AS.

You are adding a new role, which you are calling "Client", but it is not
the OAuth Client role. It seems to be an "agent" of some kind that acts on
behalf of the User to coordinate / orchestrate sharing information.

It is unclear what value the "agent" plays in the flow you are proposing.

ᐧ

On Wed, Aug 5, 2020 at 2:26 AM Denis <[email-masked]> wrote:

> From the discussion, it is obvious that the terms we want to use are not
> well defined, hence they can't be well understood.
>
> If we were drafting an ISO standard, we would need to apply the ISO rules
> from the ISO/IEC Directives Part 2 [1] ,
> The definition shall be written in such a form that it can replace the
> term in its context.
> It shall not start with an article (“the”, “a”) nor end with a full stop.
> For OAuth, the word "client" is used in section 1.1 (Roles) from RFC 6749
> with the following explanation.
>
> client
> in a client-server model, since it relates to a "resource owner" which is
> a concept that does not necessarily exist in a
> client-server model.
>
> client application: application by means of which a user interacts with
> RS(s) and AS(s)
>
> user agent: application by means of which a user interacts with RS(s) and
> AS(s)
>
> Note: I don't like that much "Resource Client" since it concatenates two contradictory
> terms.
>
> implies the user has an account at RS2.
>
> sure that the user has an account on RS2 so that further operations can be
> charged to this account and that the prints can be sent
> to a known address". As also clearly mentioned :"Any authentication method
> supported by RS1 or RS2 can be used by the User".
>
>         Questions: What would be the full scenario of this use case using
> How would you solve the photo sharing example now ? What would be the
> full scenario ?

---

From: Dick Hardt <[email-masked]>
Date: Wed, 5 Aug 2020 18:05:02 -0700

I agree with Justin. Redefining well used terms will lead to significant
confusion. If we have a different role than what we have had in the past,
then that role should have a name not being used already in OAuth or OIDC.

Given what we have learned, and my own experience explaining what a Client
is, and is not, improving the definition for Client could prove useful. I
am not suggesting the term be redefined, but clarified.

For example, clarifying that a Client is a role an entity plays in the
protocol, and that the same entity may play other roles at other times, or
some other language to help differentiate between "role" and "entity".

/Dick
ᐧ

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <[email-masked]> wrote:

> I’m in favor of coming up with a new term that’s a better fit, but I’m not
> really in favor of taking an existing term and applying a completely new
> definition to it. In other words, I would sooner stop using “client” and
> come up with a new, more specific and accurate term for the role than to
> define “client” as meaning something completely different. We did this in
> going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing
> “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all,
> nor does it use “server” on its own but instead always qualifies it with
> “Authorization Server” and “Resource Server”.
>
> GNAP can do something similar, in my opinion. But what we can’t do is
> ignore the fact that GNAP is going to be coming up in a world that is
> already permeated  by OAuth 2 and its terminology. We don’t have a blank
> slate to work with, but neither are we bound to use the same terms and
> constructs as before. It’s going to be a delicate balance!
>
>  — Justin
>
> TXAuth mailing list
> [email-masked]

---

From: Denis <[email-masked]>
Date: Thu, 6 Aug 2020 12:59:54 +0200

Justin and Dick,

[Was:  "Revisiting the photo sharing example (a driving use case for the 
creation of OAuth)"]

So let us attempt to define new terms:

    *initiating application (IA)*: application by means of which a user
    initiates interactions with RS(s) and AS(s)

In the same way, we should get rid of the term Resource Owner (RO), 
which is currently defined as:

    Resource Owner (RO): entity capable of granting access to a
    protected resource

I propose to replace it with Resource Manager (RM):

    *Resource Manager (RM)* : application or user that manages an access
    decision function of a Resource Server

Denis

> I agree with Justin. Redefining well used terms will lead to 
> significant confusion. If we have a different role than what we have 
> had in the past, then that role should have a name not being used 
> already in OAuth or OIDC.
>
> Given what we have learned, and my own experience explaining what a 
> Client is, and is not, improving the definition for Client could prove 
> useful. I am not suggesting the term be redefined, but clarified.
>
> protocol, and that the same entity may play other roles at other 
> times, or some other language to help differentiate between "role" and 
> "entity".
>
> /Dick
> ᐧ
>
> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I’m in favor of coming up with a new term that’s a better fit, but
>     I’m not really in favor of taking an existing term and applying a
>     completely new definition to it. In other words, I would sooner
>     stop using “client” and come up with a new, more specific and
>     accurate term for the role than to define “client” as meaning
>     something completely different. We did this in going from OAuth 1
>     to OAuth 2 already, moving from the even-more-confusing “consumer”
>     to “client”, but OAuth 2 doesn’t use the term “consumer” at all,
>     nor does it use “server” on its own but instead always qualifies
>     it with “Authorization Server” and “Resource Server”.
>
>     GNAP can do something similar, in my opinion. But what we can’t do
>     is ignore the fact that GNAP is going to be coming up in a world
>     that is already permeated  by OAuth 2 and its terminology. We
>     don’t have a blank slate to work with, but neither are we bound to
>     use the same terms and constructs as before. It’s going to be a
>     delicate balance!
>
>      — Justin
>
>>     On Aug 4, 2020, at 3:32 PM, Warren Parad <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     If we say that this document assumes OAuth2.0 terminology, then
>>     we should not change the meanings of any definition. If we are
>>     saying this supersedes or replaces what OAuth 2.0 creates, then
>>     we should pick the best word for the job and ignore conflicting
>>     meanings from OAuth 2.0. I have a lot of first hand experience of
>>     industries "ruining words", and attempting to side-step the
>>     problem rather than redefining the word just confuses everyone as
>>     everyone forgets the original meaning as new documents come out,
>>     but the confusion with the use of a non-obvious word continues.
>>
>>     Food for thought.
>>     - Warren
>>
>>     	
>>     Warren Parad
>>     Founder, CTO
>>
>>     Secure your user data and complete your authorization
>>     architecture. Implement Authress <https://bit.ly/37SSO1p>.
>>
>>
>     [email-masked] <mailto:[email-masked]>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 6 Aug 2020 13:48:51 +0200

Hi,

To me, client has always been a strange word in the context of OAuth, as it
has a meaning well defined both in everyday life (this client is a good
customer) and in computer science (client-server interaction). Thus I
always have to make the mental translation to the OAuth world before any
discussion... And any teaching experience shows that it does make the
concepts hard to grasp for a majority of (clever) people.

As for the RO, previous discussions suggested Resource
Controller (RC) also, which may be a bit more specific than manager.

Fabien

On Thu, Aug 6, 2020 at 1:00 PM Denis <[email-masked]> wrote:

> In the same way, we should get rid of the term Resource Owner (RO), which
> is currently defined as:
>
> Resource Owner (RO): entity capable of granting access to a protected
> resource
>
>> I’m in favor of coming up with a new term that’s a better fit, but I’m
>> not really in favor of taking an existing term and applying a completely
>> new definition to it. In other words, I would sooner stop using “client”
>> and come up with a new, more specific and accurate term for the role than
>> to define “client” as meaning something completely different. We did this
>> in going from OAuth 1 to OAuth 2 already, moving from the
>> even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the
>> term “consumer” at all, nor does it use “server” on its own but instead
>> always qualifies it with “Authorization Server” and “Resource Server”.
>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 6 Aug 2020 09:53:14 -0700

The term client in OAuth came from the computer science definition of
client-server interaction.

The client is getting an access token so it can call a server,
specifically, a resource server (to differentiate it from the authorization
server).

The confusion in my experience usually stems from people working with
software that is acting in multiple roles. IE, the software that is acting
as a client in once context, is also acting as an RS in other contexts, or
even acting as an AS. The other confusion is that people view clients as
being the software the user is using -- although it may not be acting as a
client in the oauth context.

ᐧ

On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <[email-masked]>
wrote:

> Hi,
>
> To me, client has always been a strange word in the context of OAuth, as
> it has a meaning well defined both in everyday life (this client is a good
>>> If we say that this document assumes OAuth2.0 terminology, then we
>>> should not change the meanings of any definition. If we are saying this
>>> supersedes or replaces what OAuth 2.0 creates, then we should pick the best
>>> word for the job and ignore conflicting meanings from OAuth 2.0. I have a
>>> lot of first hand experience of industries "ruining words", and attempting
>>> to side-step the problem rather than redefining the word just confuses

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Aug 2020 15:50:17 -0400

On Aug 6, 2020, at 12:53 PM, Dick Hardt <[email-masked]> wrote:
> 
> The term client in OAuth came from the computer science definition of client-server interaction.

This, I would argue, is exactly why it’s a bad label for something that’s distinctly more specific in this context, and I would love to see GNAP adopt a more specific label for the role that we traditionally called “client” in OAuth.

 — Justin

> 
> The client is getting an access token so it can call a server, specifically, a resource server (to differentiate it from the authorization server).
> 
> The confusion in my experience usually stems from people working with software that is acting in multiple roles. IE, the software that is acting as a client in once context, is also acting as an RS in other contexts, or even acting as an AS. The other confusion is that people view clients as being the software the user is using -- although it may not be acting as a client in the oauth context.
> 
> 
> 
> ᐧ
> 
> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, 
> 
> To me, client has always been a strange word in the context of OAuth, as it has a meaning well defined both in everyday life (this client is a good customer) and in computer science (client-server interaction). Thus I always have to make the mental translation to the OAuth world before any discussion... And any teaching experience shows that it does make the concepts hard to grasp for a majority of (clever) people.
> 
> As for the RO, previous discussions suggested Resource Controller (RC) also, which may be a bit more specific than manager. 
> 
> Fabien 
> 
> On Thu, Aug 6, 2020 at 1:00 PM Denis <[email-masked] <mailto:[email-masked]>> wrote:
> Justin and Dick,
> 
> [Was:  "Revisiting the photo sharing example (a driving use case for the creation of OAuth)"]
> 
> initiating application (IA): application by means of which a user initiates interactions with RS(s) and AS(s)
> In the same way, we should get rid of the term Resource Owner (RO), which is currently defined as:
> Resource Owner (RO): entity capable of granting access to a protected resource
> Resource Manager (RM) : application or user that manages an access decision function of a Resource Server
> Denis
> 
>> I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.
>> 
>> Given what we have learned, and my own experience explaining what a Client is, and is not, improving the definition for Client could prove useful. I am not suggesting the term be redefined, but clarified. 
>> 
>> For example, clarifying that a Client is a role an entity plays in the protocol, and that the same entity may play other roles at other times, or some other language to help differentiate between "role" and "entity".
>> 
>> /Dick
>> ᐧ
>> 
>> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Aug 4, 2020, at 3:32 PM, Warren Parad <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 6 Aug 2020 15:35:52 -0700

I still think that client was the right name in OAuth 2, as the client
wanted to do a client-server interaction, so the client used OAuth 2 to get
an access token to interact with the "server".

I do agree that it is not the best term in GNAP. Primarily because GNAP is
a combination of the client from OAuth 2, and the relying party from OIDC.

/Dick
ᐧ

On Thu, Aug 6, 2020 at 12:50 PM Justin Richer <[email-masked]> wrote:

> This, I would argue, is exactly why it’s a bad label for something that’s
> distinctly more specific in this context, and I would love to see GNAP
> adopt a more specific label for the role that we traditionally called
> “client” in OAuth.
>
>  — Justin
>
>

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 10 Aug 2020 22:16:56 -0400

Hello Denis, Justin, Dick, Fabien,

In this post (
https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/)
i suggested we use the word "Orchestrator" to designate the piece of
software that orchestrate interaction between "Requestor" (a.k.a. User), AS
and RS to obtain the protected resource.

We are turning around the same topic. As soon as we go beyond the original
oAuth protocol, the word 'Client' becomes confusing.

In the same response, I suggest we talk about "roles" and not "entities".

Best regards.
/Francis

On Thu, Aug 6, 2020 at 6:36 PM Dick Hardt <[email-masked]> wrote:

>>>> significant confusion. If we have a different role than what we have had
>>>> in the past, then that role should have a name not being used already in
>>>> OAuth or OIDC.
>>>>

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

---

From: Francis Pouatcha <[email-masked]>
Date: Mon, 10 Aug 2020 23:04:13 -0400

In this context, I suggest we pick some words to work with, and sharpen
them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (
https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/),
I replaced the words:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |<---------->|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge)     |
  |                       |------------------->|                |
  |                       |            |       |(4) ConsentRequest:Grant
  |                       |            |       |<-------------->|
  |                       |(5) GrantAccess(AuthZ)               |
  |                       |<-------------------|                |
  |                       |            |       |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse
  |                       |<---------->|       |                |
  |(7) ServiceResponse    |            |       |                |
  |<----------------------|            |       |                |
  +                       +            +       +                +

The purpose of the GNAP protocol is to help negotiate access to a protected
resource. It starts with a requestor delegating activity to an
orchestrator. These are all roles, no entities. Let focus on mapping the
use cases to the protocol roles and interactions so wwe can discover what
is missing.

It seems cumbersome to use it in discussions as it is impossible to give
the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or whatever
word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis

On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <[email-masked]> wrote:

> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu
> <[email-masked]>> wrote:
>
>> Implement Authress <https://bit..ly/37SSO1p>.
>>
>>

---

From: Fabien Imbault <[email-masked]>
Date: Tue, 11 Aug 2020 07:52:15 +0200

Hi Francis,

I like your proposal, seems much more intuitive.

Fabien

Le mar. 11 août 2020 à 04:17, Francis Pouatcha <[email-masked]> a écrit :

>> I do agree that it is not the best term in GNAP. Primarily because GNAP
>> is a combination of the client from OAuth 2, and the relying party from
>> OIDC.
>>
>> /Dick
>> ᐧ
>>
>>> This, I would argue, is exactly why it’s a bad label for something
>>> that’s distinctly more specific in this context, and I would love to see
>>> GNAP adopt a more specific label for the role that we traditionally called
>>> “client” in OAuth.
>>>
>>>  — Justin
>>>
>>>
>>>> To me, client has always been a strange word in the context of OAuth,
>>>> as it has a meaning well defined both in everyday life (this client is a
>>>> good customer) and in computer science (client-server interaction). Thus I
>>>>>> completely new definition to it. In other words, I would sooner stop using
>>>>>> “client” and come up with a new, more specific and accurate term for the
>>>>>> role than to define “client” as meaning something completely different. We
>>>>>> did this in going from OAuth 1 to OAuth 2 already, moving from the

---

From: Dave Tonge <[email-masked]>
Date: Tue, 11 Aug 2020 10:42:28 +0200

Hi all

I agree that "client" can be confusing. I would be in support of
alternative terminology.
We can always have some wording that explains that an "Orchestrator" in
GNAP plays a similar role to "Client" in OAuth.

Dave

On Tue, 11 Aug 2020 at 07:52, Fabien Imbault <[email-masked]>
wrote:

>> We are turning around the same topic. As soon as we go beyond the
>> original oAuth protocol, the word 'Client' becomes confusing.
>>
>>>>>> For example, clarifying that a Client is a role an entity plays in
>>>>>> the protocol, and that the same entity may play other roles at other times,
>>>>>> or some other language to help differentiate between "role" and "entity".
>>>>>>
>>>>>> /Dick
>>>>>> ᐧ
>>>>>>
>>>>>>> is ignore the fact that GNAP is going to be coming up in a world that is

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: Tom Jones <[email-masked]>
Date: Tue, 11 Aug 2020 08:44:12 -0700

the term "orchestator" does not match any use case i have.
Let's be clear that there are four entities to a single transaction in the
real world sense of things. (and others that support the  transaction.)
Then we can focus on the end point roles. I will focus on the data privacy
issues, API's have the same parties with different terminology.
1. the subject of the data to be transferred.
2. the user of a grant from the subject to act as delegate. (see
https://wiki.idesg.org/wiki/index.php/Delegation for how to enable the user)
3. the site that has a repository of user data with legal obligations to
protect that data (the GDPR) (role resource server.)
4 the site that wants either access to the data, or some privacy preserving
statement about the existence and content of the data. (role of client,
vendor, PISP, etc.)
5. some sorts of facilitator sites for allowing access (roles like
authenticator, idp, verifier, csp, RA, etc etc. etc. ) these have been left
out of OAUTH for good reason.

This is a note supporting the separation of roles from legal entities.
BTW, I firmly believe that the legal entity also needs to be ID'd by the
transaction.
Peace ..tom

On Tue, Aug 11, 2020 at 1:42 AM Dave Tonge <[email-masked]> wrote:

>>>>> On Thu, Aug 6, 2020 at 4:49 AM Fabien Imbault <
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> *Resource Manager (RM)* : application or user that manages an
>>>>>>> access decision function of a Resource Server
>>>>>>>
>>>>>>> Denis
>>>>>>>
> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772. Moneyhub Financial Technology Limited 2020 ©
> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1
> 6EA.
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company may
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>
> --
> TXAuth mailing list
> [email-masked]

---

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

Hi Francis

The user is an entity, not a role in the protocol in how I am defining
roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of
the core protocol.

On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <[email-masked]> wrote:

> The purpose of the GNAP protocol is to help negotiate access to a
> protected resource. It starts with a requestor delegating activity to an

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 11 Aug 2020 18:37:13 -0400

Hello Dick,

> roles, so steps (1) and (7) are confusing to me on what is happening.
"Requestor" is the role (*was* User). So the UML participant refers to the
role "Requestor"

> I also think that (2) could be an extension to GNAP, rather than part of
If you make it an extension, you hide. It shall rather be an optional,
integral part of the protocol. If the "Orchestrator/Negotiator/Client" can
translate the service request into a resource request, then there will be
no need to invoke (2).

When we move beyond identity management, cases become complex and it makes
sense to explicitly display this possibility in the protocol flow.

In some open banking designs,
- the "Orchestrator/Negotiator/Client" will not know the AS to talk to
unless the call (2).
- the request (2) might result in an exemption, meaning no need for further
authorization, allowing to skip (3, 4, 5) and even (6).

/Francis

>> We can mention in the final document, that the "Orchestrator" (or
>> whatever word we finally use) plays the same role as the "Client" in oAuth2.
>>
>> Best regards.
>> /Francis
>>
>>
>>
>>
>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 11 Aug 2020 16:37:34 -0700

Hi Francis, responses inline ...

On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha <[email-masked]> wrote:

> "Requestor" is the role (*was* User). So the UML participant refers to
> the role "Requestor"
>

I still don't understand what is happening in (1) and (7)

> integral part of the protocol.
>

Most deployments today accomplish (2) by the developer reading RS
documentation.

I'm in favor of showing that step in an abstract diagram. But it is not
clear to me what the requirements for (2), and they may vary radically
across use cases, so putting it in the core document seems to be getting
ahead of ourselves.

> - the "Orchestrator/Negotiator/Client" will not know the AS to talk to

Have you put these use cases in the wiki?

> - the request (2) might result in an exemption, meaning no need for
> further authorization, allowing to skip (3, 4, 5) and even (6).
>

Agreed.

---

From: Justin Richer <[email-masked]>
Date: Tue, 11 Aug 2020 23:38:08 +0000

If defined as the party operating the client software, then the user is a role. I believe this is more accurate and inclusive than the definition you have proposed with the user as an entity. 

 - Justin
________________________________________
From: Dick Hardt [[email-masked]]
Sent: Tuesday, August 11, 2020 6:21 PM
To: Francis Pouatcha
Cc: Justin Richer; Denis; Benjamin James Kaduk; [email-masked]
Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a driving use case for the creation of OAuth)

Hi Francis

The user is an entity, not a role in the protocol in how I am defining roles, so steps (1) and (7) are confusing to me on what is happening.

I also think that (2) could be an extension to GNAP, rather than part of the core protocol.

On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <[email-masked]<mailto:[email-masked]>> wrote:
In this context, I suggest we pick some words to work with, and sharpen them as we move on, discover and map new use cases to the protocol.

In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/), I replaced the words:

The purpose of the GNAP protocol is to help negotiate access to a protected resource. It starts with a requestor delegating activity to an orchestrator. These are all roles, no entities. Let focus on mapping the use cases to the protocol roles and interactions so wwe can discover what is missing.

It seems cumbersome to use it in discussions as it is impossible to give the word "Client" a clear definition.

We can mention in the final document, that the "Orchestrator" (or whatever word we finally use) plays the same role as the "Client" in oAuth2.

Best regards.
/Francis

On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Justin. Redefining well used terms will lead to significant confusion. If we have a different role than what we have had in the past, then that role should have a name not being used already in OAuth or OIDC.

/Dick
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ

On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:[email-masked]>> wrote:
I’m in favor of coming up with a new term that’s a better fit, but I’m not really in favor of taking an existing term and applying a completely new definition to it. In other words, I would sooner stop using “client” and come up with a new, more specific and accurate term for the role than to define “client” as meaning something completely different. We did this in going from OAuth 1 to OAuth 2 already, moving from the even-more-confusing “consumer” to “client”, but OAuth 2 doesn’t use the term “consumer” at all, nor does it use “server” on its own but instead always qualifies it with “Authorization Server” and “Resource Server”.

 — Justin

On Aug 4, 2020, at 3:32 PM, Warren Parad <[email-masked]<mailto:[email-masked]>> wrote:

Food for thought.
- Warren

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad
Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit..ly/37SSO1p>.

On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Denis,

-Ben

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

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 11 Aug 2020 22:14:41 -0400

Hello Dick,

I will use the university registration use case as an example to illustrate
steps (1) and (7).

+-----------+      +--------------+  +-----------+  +----+
 +---------------------+
| Requestor |      | Orchestrator |  | RS        |  | GS |  | Resource
Controller |
| is UNIV-1 |      |  is UNIV-1   |  | is UNIV-0 |  | or |  |         is
      |
|   Staff   |      | Registr. App |  | Server    |  | AS |  |       Student
     |
+-----------+      +--------------+  +-----------+  +----+
 +---------------------+
  |(1) RegisterStudent(StudentId)          |           |                |
  |---------------------->|                |           |                |
  |                       |(2) RequestRecordIntent(RecordType,StudentId,
  |                       |     OrchestratorId):AuthRequest[RecordType,
StudentId]
  |                       |<-------------->|           |                |
  |                       |                |           |                |
  |                       |(3) AuthZRequest(RecordType,StudentId
,OrchestratorId)
  |                       |--------------------------->|                |
  |                       |                |           |(4)
ConsentRequest(RecordType,
  |                       |                |           |
 OrchestratorId):Consent
  |                       |                |           |<-------------->|
  |                       |(5) AuthZ[RecordType,StudentId,OrchestratorId]
  |                       |<---------------------------|                |
  |                       |                |           |                |
  |                       |(2) RequestRecord(RecordType,StudentId
,OrchestratorId)
  |                       |     :RecordOf[StudentId]   |                |
  |                       |<-------------->|           |                |
  |(7) Registered         |                |           |                |
  |<----------------------|                |           |                |
  +                       +                +           +                +

Step (1) is the initial service request "RegisterStudent" sent by
the university staff to the University registration application.

Step (7) is the response to step (1), the notification of the university
staff that the registration was successful.

Best regards
/Francis

---

From: Dick Hardt <[email-masked]>
Date: Tue, 11 Aug 2020 20:39:16 -0700

Thanks Francis

(I'm assuming your second (2) should have been a (6) )

Am I correct that 1, 4, & 7 are human interactions, and 2, 3, 5, & 6 are
part of the protocol?

ᐧ

On Tue, Aug 11, 2020 at 7:14 PM Francis Pouatcha <[email-masked]> wrote:

> Hello Dick,
>
> I will use the university registration use case as an example to
> illustrate steps (1) and (7).
>
> |   Staff   |      | Registr. App |  | Server    |  | AS |  |
> Student       |

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 12 Aug 2020 07:57:48 -0400

> (I'm assuming your second (2) should have been a (6) )
Yes. Typo

>
> Am I correct that 1, 4, & 7 are human interactions,
>
Yes in the university use case. They might not be human interaction in
other use cases. They are not part of the protocol, but help for use
case mapping.

> and 2, 3, 5, & 6 are part of the protocol?
>
Yes.

---

From: Denis <[email-masked]>
Date: Wed, 12 Aug 2020 16:14:10 +0200

Hi Dick,

> On Tue, Aug 11, 2020 at 3:37 PM Francis Pouatcha <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello Dick,
>
>     On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi Francis
>
>         The user is an entity, not a role in the protocol in how I am
>         defining roles, so steps (1) and (7) are confusing to me on
>         what is happening.
>
>     "Requestor" is the role (*was* User). So the UML participant
>     refers to the role "Requestor"
>
>
>     If you make it an extension, you hide. It shall rather be an
>     optional, integral part of the protocol.
>
>
> documentation. I'm in favor of showing that step in an abstract diagram.

[Denis] Really by reading RS documentation ? Non capisco l'italiano. Jag 
förstår inte svenska. Jeg forstår ikke norsk.

One of the goals is for any Client to access any RS without the need to 
read any documentation.

> But it is not clear to me what the requirements for (2), and they may 
> vary radically across use cases, so putting it in the core document 
> seems to be getting ahead of ourselves.

[Denis] I can only reinsist on earlier explanations given about the 
Client-server use cases built along "Privacy by Design" since they are 
fundamental.

    Taking into consideration both the "data minimization" principle and
    the "user participation" principle when a user first authenticates
    to a RS leads to the following:

    1) When accessing a RS for the first time, the user should be
    informed of the authentication means proposed by the RS. The user
    should be able to use a dialog box
    where some choices are presented by the RS. The user should be able
    to locally make his own choices and to indicate his consent to its
    Client.

    2) When a user chooses to perform one operation on a RS, the RS
    should limit the data to be collected from the user to only what is
    strictly necessary
    to perform that operation. That data consists of specific types of
    attributes that need to be guaranteed by one or more ASs. The user
    should be able
    to use a dialog box where some ASs choices are proposed by the RS.
    The user should be able to locally make his own choices and to indicate
    his consent to its Client.

    It is important to notice that the choices that will be proposed to
    a user may depend upon previous personal information voluntarily
    released by that user.
    This means that the choices proposed by the RS may be tailored for
    the user. Furthermore, the proposed choices may only be disclosed to
    already authenticated users.

Denis

>     - the "Orchestrator/Negotiator/Client" will not know the AS to
>     talk to unless the call (2).
>
>
>     - the request (2) might result in an exemption, meaning no need
>     for further authorization, allowing to skip (3, 4, 5) and even (6).
>
>
> Agreed.
>
> ᐧ

---

From: Justin Richer <[email-masked]>
Date: Wed, 12 Aug 2020 11:38:04 -0400

+1 to this. I think that the core protocol needs to be designed to allow this kind of action, but I also think it is possible that the details of this could end up in an extension to the main document. I’ve put a flag in the ground for this in XYZ in sections 10.3 and 10.4, which is adapted from UMA2’s distributed authorization protocol:

https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.3 <https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.3>

The important detail here, in XYZ’s design, is that the RS has a clear way to communicate to the client what will be needed to fulfill the request, and the client/orchestrator/whatever has a clear way to incorporate that into the main protocol. The details of (2) using the XYZ pattern are:

+-----------+      +--------------+  +----+  +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  | GS |  | Resource Controller |
|   was     |      |     was      |  | RS |  | or |  |         was         |
|  User     |      |   Client     |  |    |  | AS |  |    Resource Owner   |
+-----------+      +--------------+  +----+  +----+  +---------------------+
  |(1) ServiceRequest     |            |       |                |
  |---------------------->|            |       |                |
  |                       |(2) ServiceIntent:AuthZChallenge     |
  |                       |----------->|       |                |
  |                       |            |       |                |
  |                       |            |(2a) Register resource set
  |                       |            |------>|                |
  |                       |            |       |                |
  |                       |            |(2b) Return resource reference handle
  |                       |            |<------|                |
  |                       |            |       |                |
  |                       |(2c) Return AS URL and resource reference handle
  |                       |<-----------|       |                |
  |                       |            |       |                |
  |                       |(3) AuthZRequest(AuthZChallenge, include resource handle)
  |                       |------------------->|                |

Note that the client can ALSO request additional resources on top of what the RS returned in (2b), since this is passed simply as one element of the array. 

 — Justin

> On Aug 11, 2020, at 6:37 PM, Francis Pouatcha <[email-masked]> wrote:
> 
> Hello Dick,
> 
> On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Francis
> 
> "Requestor" is the role (was User). So the UML participant refers to the role "Requestor"
> 
> 
> If you make it an extension, you hide. It shall rather be an optional, integral part of the protocol. If the "Orchestrator/Negotiator/Client" can translate the service request into a resource request, then there will be no need to invoke (2).
> 
> When we move beyond identity management, cases become complex and it makes sense to explicitly display this possibility in the protocol flow.
> 
> - the "Orchestrator/Negotiator/Client" will not know the AS to talk to unless the call (2).
> - the request (2) might result in an exemption, meaning no need for further authorization, allowing to skip (3, 4, 5) and even (6).
> 
> /Francis
> 
> 
> 
> 
> 
> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <[email-masked] <mailto:[email-masked]>> wrote:
> In this diagram from the original thread (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/ <https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/>), I replaced the words:
> 
> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu <mailto:[email-masked]>> wrote:
>> Secure your user data and complete your authorization architecture. Implement Authress <https://bit..ly/37SSO1p>.
>> 
>> 
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>
> 
> -- 
> Francis Pouatcha
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>

---

From: Denis <[email-masked]>
Date: Wed, 12 Aug 2020 18:02:24 +0200

Justin,

A soon as the RS needs to talk to the GS (step 2a) , it is a "Big 
Brother by Design" architecture.
Do you want to mandate it ?

Denis

> +1 to this. I think that the core protocol needs to be designed to 
> allow this kind of action, but I also think it is possible that the 
> details of this could end up in an extension to the main document. 
> I’ve put a flag in the ground for this in XYZ in sections 10.3 and 
> 10.4, which is adapted from UMA2’s distributed authorization protocol:
>
> https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.3
>
> The important detail here, in XYZ’s design, is that the RS has a clear 
> way to communicate to the client what will be needed to fulfill the 
> request, and the client/orchestrator/whatever has a clear way to 
> incorporate that into the main protocol. The details of (2) using the 
> XYZ pattern are:
>
> Note that the client can ALSO request additional resources on top of 
> what the RS returned in (2b), since this is passed simply as one 
> element of the array.
>
>  — Justin
>
>> On Aug 11, 2020, at 6:37 PM, Francis Pouatcha <[email-masked] 
>>     defining roles, so steps (1) and (7) are confusing to me on what
>>     is happening.
>>
>> optional, integral part of the protocol. If the 
>> "Orchestrator/Negotiator/Client" can translate the service request 
>> into a resource request, then there will be no need to invoke (2).
>>
>> When we move beyond identity management, cases become complex and it 
>> makes sense to explicitly display this possibility in the protocol flow.
>>
>>         In this context, I suggest we pick some words to work with,
>>         and sharpen them as we move on, discover and map new use
>>         cases to the protocol.
>>
>>         In this diagram from the original thread
>>         (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/),
>>         I replaced the words:
>>
>>         ConsentRequest:Grant
>>         The purpose of the GNAP protocol is to help negotiate access
>>         to a protected resource. It starts with a requestor
>>         delegating activity to an orchestrator. These are all roles,
>>         no entities. Let focus on mapping the use cases to the
>>         protocol roles and interactions so wwe can discover what is
>>         missing.
>>
>>         It seems cumbersome to use it in discussions as it is
>>         impossible to give the word "Client" a clear definition.
>>
>>         We can mention in the final document, that the "Orchestrator"
>>         (or whatever word we finally use) plays the same role as the
>>         "Client" in oAuth2.
>>
>>         Best regards.
>>         /Francis
>>
>>
>>
>>
>>
>>         On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>             I agree with Justin. Redefining well used terms will lead
>>             to significant confusion. If we have a different role
>>             than what we have had in the past, then that role should
>>             have a name not being used already in OAuth or OIDC.
>>
>>             Given what we have learned, and my own experience
>>             explaining what a Client is, and is not, improving the
>>             definition for Client could prove useful. I am not
>>             suggesting the term be redefined, but clarified.
>>
>>             For example, clarifying that a Client is a role an entity
>>             plays in the protocol, and that the same entity may play
>>             other roles at other times, or some other language to
>>             help differentiate between "role" and "entity".
>>
>>             /Dick
>>             ᐧ
>>
>>             On Wed, Aug 5, 2020 at 8:20 AM Justin Richer
>>             <jricher@mit..edu <mailto:[email-masked]>> wrote:
>>
>>                 I’m in favor of coming up with a new term that’s a
>>                 better fit, but I’m not really in favor of taking an
>>                 existing term and applying a completely new
>>                 definition to it. In other words, I would sooner stop
>>                 using “client” and come up with a new, more specific
>>                 and accurate term for the role than to define
>>                 “client” as meaning something completely different.
>>                 We did this in going from OAuth 1 to OAuth 2 already,
>>                 moving from the even-more-confusing “consumer” to
>>                 “client”, but OAuth 2 doesn’t use the term “consumer”
>>                 at all, nor does it use “server” on its own but
>>                 instead always qualifies it with “Authorization
>>                 Server” and “Resource Server”.
>>
>>                 GNAP can do something similar, in my opinion. But
>>                 what we can’t do is ignore the fact that GNAP is
>>                 going to be coming up in a world that is already
>>                 permeated  by OAuth 2 and its terminology. We don’t
>>                 have a blank slate to work with, but neither are we
>>                 bound to use the same terms and constructs as before.
>>                 It’s going to be a delicate balance!
>>
>>                  — Justin
>>
>>>                 On Aug 4, 2020, at 3:32 PM, Warren Parad
>>>                 <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>                 If we say that this document assumes OAuth2.0
>>>                 terminology, then we should not change the meanings
>>>                 of any definition. If we are saying this supersedes
>>>                 or replaces what OAuth 2.0 creates, then we should
>>>                 pick the best word for the job and ignore
>>>                 conflicting meanings from OAuth 2.0. I have a lot of
>>>                 first hand experience of industries "ruining words",
>>>                 and attempting to side-step the problem rather than
>>>                 redefining the word just confuses everyone as
>>>                 everyone forgets the original meaning as new
>>>                 documents come out, but the confusion with the use
>>>                 of a non-obvious word continues.
>>>
>>>                 Food for thought.
>>>                 - Warren
>>>
>>>                 	
>>>                 Warren Parad
>>>                 Founder, CTO
>>>
>>>                 Secure your user data and complete your
>>>                 authorization architecture. Implement Authress
>>>                 <https://bit..ly/37SSO1p>.
>>>
>>>
>>>                 On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk
>>>                 <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>                     Hi Denis,
>>>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 12 Aug 2020 09:54:32 -0700

comments inline ...

> I still don't understand what is happening in (1) and (7)
Would you provide more explanation?

> One of the goals is for any Client to access any RS without the need to

That is impractical. Most RSes today have resource specific APIs. The
Client is either reading a standard API doc, or the resource specific API
doc.

> But it is not clear to me what the requirements for (2), and they may vary
> radically across use cases, so putting it in the core document seems to be
> getting ahead of ourselves.
>
I agree with the principle of "Privacy by Design". There are LOTS of
details in how to do what you outline below, and I expect they will be
radically different across use cases, which is why I don't think it fits
into the core document, but I do agree with calling it out in the abstract.
When I publish an updated draft, let me know what you think then.

>
> Taking into consideration both the "data minimization" principle and the
> "user participation" principle when a user first authenticates to a RS
> leads to the following:
>
> 1) When accessing a RS for the first time, the user should be informed of
> the authentication means proposed by the RS. The user should be able to use
> a dialog box
> where some choices are presented by the RS. The user should be able to
> locally make his own choices and to indicate his consent to its Client.
>
> 2) When a user chooses to perform one operation on a RS, the RS should
> limit the data to be collected from the user to only what is strictly
> necessary
> attributes that need to be guaranteed by one or more ASs. The user should
> be able
> to use a dialog box where some ASs choices are proposed by the RS. The
> user should be able to locally make his own choices and to indicate
> It is important to notice that the choices that will be proposed to a user
> may depend upon previous personal information voluntarily released by that
> user.
> This means that the choices proposed by the RS may be tailored for the
> user. Furthermore, the proposed choices may only be disclosed to already
> authenticated users.
>
> Denis
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 12 Aug 2020 12:55:36 -0400

Denis,

This isn’t mandated, this is one optional flow for the cases where the RS :wants: to talk to the AS. 

 — Justin

> On Aug 12, 2020, at 12:02 PM, Denis <[email-masked]> wrote:
> 
> Justin,
> 
> A soon as the RS needs to talk to the GS (step 2a) , it is a "Big Brother by Design" architecture. 
>>> On Aug 11, 2020, at 6:37 PM, Francis Pouatcha <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hello Dick,
>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 12 Aug 2020 13:39:36 -0400

Do you need more?

---

From: Denis <[email-masked]>
Date: Thu, 13 Aug 2020 15:47:43 +0200

Dick,

I first jump on the following exchanges:

    [Dick] Most deployments today accomplish (2) by the developer
    reading RS documentation. I'm in favor of showing that step in an
    abstract diagram.

    [Denis] Really by reading RS documentation ? Non capisco l'italiano.
    Jag förstår inte svenska. Jeg forstår ikke norsk.
    One of the goals is for any Client to access any RS without the need
    to read any documentation.

    [Dick]That is impractical. Most RSes today have resource specific
    APIs. The Client is either reading a standard API doc, or the
    resource specific API doc.

I am not so sure that it is impractical.

In 2012, Geert Jansen considered the possibility for complete 
auto-discovery by the API user, so that the API can be used by a human 
with a web browser,
without any reference to external documentation. See the "Form 
Definition Language" in 
:https://restful-api-design.readthedocs.io/en/latest/forms.html

In his view, forms need to specify three pieces of information:

    1.    How to contact the target and format the input.
    2.    A list of all available input fields.
    3.    A list of constraints with which the input fields must comply.

Hence, in his view, the form consists of 3 parts: form metadata, field 
definitions, and constraints.

What do you think ?

The second point on which I would like to insist is about the use of a 
"dialog box" for user interaction. This wording is used in RFC 6973.

In OAuth 2.0, the user consent is performed by the AS using an authorize 
endpoint where the user consent is solicited and captured.

Since a user, with no prior experience, shall first connect to a RS to 
perform an operation, the user consent shall be performed by the RS,
instead of the AS. This means that we should define a "consent" endpoint 
at the RS.

Denis

> comments inline ...
>
> On Wed, Aug 12, 2020 at 7:14 AM Denis <[email-masked] 
>>         On Tue, Aug 11, 2020 at 6:22 PM Dick Hardt
>>             The user is an entity, not a role in the protocol in how
>>             I am defining roles, so steps (1) and (7) are confusing
>>             to me on what is happening.
>>
>     [Denis] Really by reading RS documentation ? Non capisco
>     l'italiano. Jag förstår inte svenska. Jeg forstår ikke norsk.
>
>     One of the goals is for any Client to access any RS without the
>     need to read any documentation.
>
>
> Client is either reading a standard API doc, or the resource specific 
> API doc.
>
>>     But it is not clear to me what the requirements for (2), and they
>>     may vary radically across use cases, so putting it in the core
>>     document seems to be getting ahead of ourselves.
>
>     [Denis] I can only reinsist on earlier explanations given about
>     the Client-server use cases built along "Privacy by Design" since
>     they are fundamental.
>
> radically different across use cases, which is why I don't think it 
> fits into the core document, but I do agree with calling it out in the 
> abstract. When I publish an updated draft, let me know what you think 
> then.
>
>
>         Taking into consideration both the "data minimization"
>         principle and the "user participation" principle when a user
>         first authenticates to a RS leads to the following:
>
>         informed of the authentication means proposed by the RS. The
>         user should be able to use a dialog box
>         where some choices are presented by the RS. The user should be
>         able to locally make his own choices and to indicate his
>         consent to its Client.
>
>         2) When a user chooses to perform one operation on a RS, the
>         RS should limit the data to be collected from the user to only
>         what is strictly necessary
>         to perform that operation. That data consists of specific
>         types of attributes that need to be guaranteed by one or more
>         ASs. The user should be able
>         to use a dialog box where some ASs choices are proposed by the
>         RS. The user should be able to locally make his own choices
>         and to indicate
>         It is important to notice that the choices that will be
>         proposed to a user may depend upon previous personal
>         information voluntarily released by that user.
>         This means that the choices proposed by the RS may be tailored
>         for the user. Furthermore, the proposed choices may only be
>         disclosed to already authenticated users.
>
>     Denis
>
>>         - the request (2) might result in an exemption, meaning no
>>         need for further authorization, allowing to skip (3, 4, 5)
>>         and even (6).
>>
>>
>>     Agreed.
>>
>>     ᐧ
>
>
> ᐧ

---

From: Denis <[email-masked]>
Date: Thu, 13 Aug 2020 15:49:19 +0200

Justin,

> RS :wants: to talk to the AS.

It is good to know. But what will be the rational(s) for it ? Token 
introspection ?
If this is the single case, since token transparency is needed for 
privacy reasons, it is doubtful that it would still be needed.

If flows can be made simpler, let us make them simpler.

Denis

>
>  — Justin
>
>> On Aug 12, 2020, at 12:02 PM, Denis <[email-masked] 
>>> The important detail here, in XYZ’s design, is that the RS has a 
>>> clear way to communicate to the client what will be needed to 
>>> fulfill the request, and the client/orchestrator/whatever has a 
>>> clear way to incorporate that into the main protocol. The details of 
>>> (2) using the XYZ pattern are:
>>>
>>>> When we move beyond identity management, cases become complex and 
>>>> it makes sense to explicitly display this possibility in the 
>>>> protocol flow.
>>>>
>>>>     On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha
>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>         The purpose of the GNAP protocol is to help negotiate
>>>>         access to a protected resource. It starts with a requestor
>>>>         delegating activity to an orchestrator. These are all
>>>>         roles, no entities. Let focus on mapping the use cases to
>>>>         the protocol roles and interactions so wwe can discover
>>>>         what is missing.
>>>>
>>>>         We can mention in the final document, that the
>>>>         "Orchestrator" (or whatever word we finally use) plays the
>>>>         same role as the "Client" in oAuth2.
>>>>
>>>>         Best regards.
>>>>         /Francis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>             I agree with Justin. Redefining well used terms will
>>>>             lead to significant confusion. If we have a different
>>>>             role than what we have had in the past, then that role
>>>>             should have a name not being used already in OAuth or
>>>>             OIDC.
>>>>
>>>>             For example, clarifying that a Client is a role an
>>>>             entity plays in the protocol, and that the same entity
>>>>             may play other roles at other times, or some other
>>>>             language to help differentiate between "role" and "entity".
>>>>
>>>>             /Dick
>>>>             ᐧ
>>>>
>>>>                 better fit, but I’m not really in favor of taking
>>>>                 an existing term and applying a completely new
>>>>                 definition to it. In other words, I would sooner
>>>>                 stop using “client” and come up with a new, more
>>>>                 specific and accurate term for the role than to
>>>>                 define “client” as meaning something completely
>>>>                 different. We did this in going from OAuth 1 to
>>>>                 OAuth 2 already, moving from the
>>>>                 even-more-confusing “consumer” to “client”, but
>>>>                 OAuth 2 doesn’t use the term “consumer” at all, nor
>>>>                 does it use “server” on its own but instead always
>>>>                 qualifies it with “Authorization Server” and
>>>>                 “Resource Server”.
>>>>
>>>>                 bound to use the same terms and constructs as
>>>>                 before. It’s going to be a delicate balance!
>>>>
>>>>                  — Justin
>>>>
>>>>>                 terminology, then we should not change the
>>>>>                 meanings of any definition. If we are saying this
>>>>>                 supersedes or replaces what OAuth 2.0 creates,
>>>>>                 then we should pick the best word for the job and
>>>>>                 ignore conflicting meanings from OAuth 2.0. I have
>>>>>                 a lot of first hand experience of industries
>>>>>                 "ruining words", and attempting to side-step the
>>>>>                 problem rather than redefining the word just
>>>>>                 confuses everyone as everyone forgets the original
>>>>>                 meaning as new documents come out, but the
>>>>>                 confusion with the use of a non-obvious word
>>>>>                 continues.
>>>>>
>>>>>                 Food for thought.
>>>>>                 - Warren
>>>>>
>>>>>                 	
>>>>>                 Warren Parad
>>>>>                 Founder, CTO
>>>>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Aug 2020 06:54:59 -0700

The Client is not a person, it is software created by a developer. The
developer of the client is going to read the documentation for the RS to
program the Client.

On Thu, Aug 13, 2020 at 6:47 AM Denis <[email-masked]> wrote:

>
>
>
>
>
>
>
>
>
>
> Dick,
>
>
>
>
>
>
>
> I first jump on the
>
> following exchanges:
>
>
>
>
>
>
> [Dick] Most deployments today accomplish
>
> (2) by the developer reading RS documentation. I'm in favor
>
> of showing that step in an abstract diagram.
>
>
> One of the goals is for any Client to access any
>
> RS without the need to read any documentation.
>
>
> [Dick]That is
>
> impractical. Most RSes today have resource specific APIs.
>
> The Client is either reading a standard API doc, or the
>
> I am not so sure
> that it is impractical.
> In 2012, Geert
> Jansen considered the possibility for complete auto-discovery
>
> by the API user, so that the API can be used by a human with a
>
> web browser,
>
>
> Definition Language" in :
>
> https://restful-api-design.readthedocs.io/en/latest/forms.html
>
>
>
>
>
>
>
>
> In his view, forms
>
> need to specify three pieces of information:
>
>
>
>
> 1.    How to contact the target
>
> and format the input.
>
>
> 3.    A list of constraints with which the input fields must
>
> comply.
>
>
>
>
> Hence,
>
> in his view, the
>
> form consists of 3 parts: form metadata, field definitions,
>
> and constraints.
>
>
>
>
>
>
>
> What do you think ?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The second point on
>
> which I would like to insist is about the use of a "dialog
>
> box" for user interaction. This wording is used in RFC 6973.
>
>
>
>
>
>
>
> In OAuth 2.0, the user
>
> consent is performed by the AS using an authorize endpoint
>
> where the user consent is solicited and captured.
>
>
>
>
>
>
>
> Since a user, with no
>
> prior experience, shall first connect to a RS to perform an
>
> operation, the user consent
>
> shall be performed by the RS,
>
>
> instead of the
>
> AS. This means that we
>
> should define a "consent" endpoint at the RS.
>
>
>
>
>
>
>
> Denis
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> comments inline ...
>
>
>
>
>
>
>
> On Wed, Aug 12, 2020 at 7:14
>
> AM Denis <[email-masked]> wrote:
>
>
>
>
>
>>
>>
>>
>> Hi Dick,
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Aug 11,
>> 2020 at 3:37 PM Francis Pouatcha <[email-masked]>
>>
>> wrote:
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>> Hello Dick,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Aug
>>>
>>> 11, 2020 at 6:22 PM Dick Hardt <[email-masked]>
>>>
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Hi Francis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The user is an entity, not a role in
>>>>
>>>> the protocol in how I am defining roles,
>>>>
>>>> so steps (1) and (7) are confusing to me
>>>>
>>>> on what is happening.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> "Requestor" is the role (*was*
>>>
>>> User). So the UML participant refers to the
>>>
>>> role "Requestor"
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>> I still don't understand what is happening in
>>
>> (1) and (7)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>>>> I also think that (2) could be an
>>>>
>>>> extension to GNAP, rather than part of
>>>>
>>>> the core protocol.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> If you make it an extension, you hide. It
>>>
>>> shall rather be an optional, integral part
>>>
>>> of the protocol.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>> Most deployments today accomplish (2) by the
>>
>> developer reading RS documentation. I'm in favor
>>
>> of showing that step in an abstract diagram.
>>
>>
>>
>>
>>
>>
>>
>>
>> förstår inte svenska. Jeg
>>
>> forstår ikke norsk.
>>
>>
>> One of the goals is for any
>>
>> Client to access any RS without the need
>>
> That is impractical. Most RSes today have resource
>
> specific APIs. The Client is either reading a standard API
>
> doc, or the resource specific API doc.
>
>
>
>
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> But it is not clear to me what the requirements
>>
>> for (2), and they may vary radically across use
>>
>> cases, so putting it in the core document seems to
>>
>> be getting ahead of ourselves.
>>
>>
>>
>>
>>
>>
>>
>>
>> [Denis] I can
>>
>> only reinsist on earlier explanations given about
>>
>> the Client-server use cases built along "Privacy by
>>
>> Design" since they are fundamental.
>>
>>
>>
>>
>>
>
> I agree with the principle of "Privacy by Design". There
>
> are LOTS of details in how to do what you outline below, and
>
> I expect they will be radically different across use cases,
>
> which is why I don't think it fits into the core document,
>
> but I do agree with calling it out in the abstract. When I
>
> publish an updated draft, let me know what you think then.
>
>
>
>
>
>
>
>
>
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Taking into
>>
>> consideration both the "data minimization"
>>
>> principle and the "user participation" principle
>>
>> when a user first authenticates to a RS leads to
>>
>> the following:
>>
>>
>>
>>
>>
>>
>>
>>
>> 1) When
>>
>> accessing a RS for the first time, the user should
>>
>> be informed of the authentication means proposed
>>
>> by the RS. The user should be able to use a dialog
>>
>> box
>>
>>
>> where some choices are presented by the RS. The
>>
>> user should be able to locally make his own
>>
>> choices and to indicate his consent to its Client.
>>
>>
>> 2) When a user chooses to perform one
>>
>> operation on a RS, the RS should limit the data to
>>
>> be collected from the user to only what is
>>
>> strictly necessary
>>
>>
>> to perform that operation. That data consists of
>>
>> specific types of attributes that need to be
>>
>> guaranteed by one or more ASs. The user should be
>>
>> able
>>
>>
>> to use a dialog box where some ASs choices are
>>
>> proposed by the RS. The user should be able to
>>
>> locally make his own choices and to indicate
>>
>>
>> It is
>> important to notice that the choices that will be
>>
>> proposed to a user may depend upon previous
>>
>> personal information voluntarily released by that
>>
>> user.
>>
>>
>> This means
>>
>> that the choices proposed by the RS may be
>>
>> tailored for the user. Furthermore, the proposed
>>
>> choices may only be disclosed to already
>>
>> authenticated users.
>>
>>
>>
>>
>> Denis
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> - the "Orchestrator/Negotiator/Client"
>>>
>>> will not know the AS to talk to unless the
>>>
>>> call (2).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>> - the request (2) might result in an
>>>
>>> exemption, meaning no need for further
>>>
>>> authorization, allowing to skip (3, 4, 5)
>>>
>>> and even (6).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>> Agreed.
>>
>>
>>
>>
>>
>>
>>
>>
>> ᐧ
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
> ᐧ
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> TXAuth mailing list
>
> [email-masked]
>

---

From: Denis <[email-masked]>
Date: Thu, 13 Aug 2020 16:04:18 +0200

Dick,

A web browser is not a person.

Denis

PS1. You didn't reply to the second point of my email about a "consent" 
endpoint at the RS.

PS2. It would be better that you wait until you can use a real laptop to 
respond and that you re-use the original message,
          because the message you sent back is almost unreadable.

> developer of the client is going to read the documentation for the RS 
> to program the Client.
>
> On Thu, Aug 13, 2020 at 6:47 AM Denis <[email-masked] 
>         l'italiano. Jag
>>     AM Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>         Hi Dick,
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>         2020 at 3:37 PM Francis Pouatcha <[email-masked]
>>>         <mailto:[email-masked]>>
>>>
>>>         wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>             Hello Dick,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>             On Tue, Aug
>>>
>>>             11, 2020 at 6:22 PM Dick Hardt <[email-masked]
>>>             <mailto:[email-masked]>>
>>>
>>>             wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>                 Hi Francis
>>>
>>>
>>>
>>>
>>>
>>>
>>         l'italiano. Jag förstår inte svenska. Jeg
>>
>>         forstår ikke norsk.
>>
>>
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Aug 2020 10:46:55 -0400

Different use cases are pulling for “simplicity” in different directions, and I think that we can have a core protocol that supports these without getting overly convoluted. At least, that’s the goal!

The rationale for having an RS register in this way is for a scenario where the AS is the trusted component in the ecosystem. I fully realize that this is very different from your scenario, where the AS is not trusted directly by the RS in the same way. Here, the RS wants to provide a specific runtime reference for what a particular client is trying to do, independent of any static API definitions for resources/scopes. In this ecosystem, the AS is trusted to manage and provision access to all of the RS’s, and the RS’s are known to the AS ahead of time. Yes, it’s acting as a “big brother” as you put it, but that’s the intentional design — the RS’s have outsourced portions of their security and trust to the AS. 

The inspiration for this is UMA’s federated authorization spec, which I also helped develop:

https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html>

This pattern is in use in the wild, but unfortunately limitations in OAuth 2 make it more separate from the OAuth ecosystem than it really ought to be. By bringing this idea of the RS and AS having a more loose runtime association into GNAP, we can solve not only the “strong AS” UMA use cases but also the “naive AS” use case that you’re bringing.

 — Justin

> On Aug 13, 2020, at 9:49 AM, Denis <[email-masked]> wrote:
> 
> Justin,
> 
>> Denis,
>> 
> It is good to know. But what will be the rational(s) for it ? Token introspection ?
> If this is the single case, since token transparency is needed for privacy reasons, it is doubtful that it would still be needed.
> 
>>> On Aug 12, 2020, at 12:02 PM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Justin,
>>>

---

From: Tom Jones <[email-masked]>
Date: Thu, 13 Aug 2020 07:59:43 -0700

I strong object to the objectification of human users. It is way past time
that the IETF becaume user oriented instead of web service oriented.
users are human in my language.
Peace ..tom

On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <[email-masked]> wrote:

> If defined as the party operating the client software, then the user is a
> role. I believe this is more accurate and inclusive than the definition you
> have proposed with the user as an entity.
>
>  - Justin
> Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing example (a
> driving use case for the creation of OAuth)
>
> Hi Francis
>
> [
> https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ
> <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]%E1%90%A7>
>
> [
> https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA
> ]
>
> Warren Parad
> Founder, CTO
>
> Implement Authress<https://bit..ly/37SSO1p>.
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Aug 2020 11:10:58 -0400

It’s a role fulfilled by a person, so I’m not sure where the objection you’re raising comes from.

Also, whatever roles we define here, whether software or human-ware, they need to be related to the protocol.

 — Justin

> On Aug 13, 2020, at 10:59 AM, Tom Jones <[email-masked]> wrote:
> 
> I strong object to the objectification of human users. It is way past time that the IETF becaume user oriented instead of web service oriented.
> On Tue, Aug 11, 2020 at 4:38 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> From: Dick Hardt [[email-masked] <mailto:[email-masked]>]
> Cc: Justin Richer; Denis; Benjamin James Kaduk; [email-masked] <mailto:[email-masked]>
> On Mon, Aug 10, 2020 at 8:04 PM Francis Pouatcha <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]%E1%90%A7>
> 
> On Wed, Aug 5, 2020 at 8:20 AM Justin Richer <jricher@mit..edu<mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> On Aug 4, 2020, at 3:32 PM, Warren Parad <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
> [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA <https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA>]
> 
> Warren Parad
> Founder, CTO
> 
> Secure your user data and complete your authorization architecture. Implement Authress<https://bit. <https://bit./>.ly/37SSO1p>.
> 
> 
> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> Hi Denis,
> 
> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Aug 2020 11:15:27 -0400

Denis, I want to focus on one point here:

> In OAuth 2.0, the user consent is performed by the AS using an authorize endpoint where the user consent is solicited and captured.
> 
> Since a user, with no prior experience, shall first connect to a RS to perform an operation, the user consent shall be performed by the RS, 
> instead of the AS. This means that we should define a "consent" endpoint at the RS.

One of my goals with XYZ’s design was to be able to separate the interaction with the user from the web-based flows for the delegation protocol, and that aspect is enshrined in the GNAP charter as well.

It points to the reality that there are two different aspects of the traditional AS that we might need to talk about separately now. One deals with delegation, issuing tokens, returning data directly to the client (not through a separate API, since that’s the RS), and other back-channel stuff. The other aspect deals with interacting with the user and/or resource owner. 

We already saw bits of this in OAuth 2: the AS is defined by the pair of the token endpoint and authorization endpoint, each filling the respective roles above. What if we formally separate these? Strawman names:

Delegation Server (DS) - handles the back-channel stuff

Interaction Server (IS) - handles the front-channel stuff

 — Justin

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 13 Aug 2020 17:17:49 +0200

Without surprise, +1 to differentiate between the back-channel and the
front-channel.

On Thu, Aug 13, 2020 at 5:15 PM Justin Richer <[email-masked]> wrote:

> One of my goals with XYZ’s design was to be able to separate the
> interaction with the user from the web-based flows for the delegation
> protocol, and that aspect is enshrined in the GNAP charter as well.
>
> It points to the reality that there are two different aspects of the
> traditional AS that we might need to talk about separately now. One deals
> with delegation, issuing tokens, returning data directly to the client (not
> through a separate API, since that’s the RS), and other back-channel stuff.
> The other aspect deals with interacting with the user and/or resource
> owner.
>
> We already saw bits of this in OAuth 2: the AS is defined by the pair of
> the token endpoint and authorization endpoint, each filling the respective
> roles above. What if we formally separate these? Strawman names:
>
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Aug 2020 08:21:36 -0700

I agree with clearly separating the GS interaction with the Client from the
interaction with the User.

I'm having a hard time viewing those as two different roles. They are two
different interactions. Just as the client interaction with the AS is
different from the client interaction with the GS.
ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Aug 2020 08:26:26 -0700

I think Tom's objection, and I agree with it, is that humans don't interact
in bits and bytes.

I think it is useful to separate human interactions with software from
software interactions with software. The latter we can standardize, the
former we can call out as part of the overall process, but it is not
something that is testable or required for interop, so I would argue human
to software interactions are NOT part of the protocol.

ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Aug 2020 08:28:38 -0700

Hi Denis, we were discussing if a developer needs to read docs to use an
API.

If you want to introduce a new topic, would you start a new thread?

ᐧ

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Aug 2020 11:33:01 -0400

A point I forgot to make below: the “front channel” isn’t going to exist for a lot of systems anymore, where interaction happens through an app or communication happens through some separate communication fabric. So there are cases, just like in OAuth 2, where there’s only a “back channel” and the other aspect of the AS never comes into play.

 — Justin

> On Aug 13, 2020, at 11:17 AM, Fabien Imbault <[email-masked]> wrote:
> 
> Without surprise, +1 to differentiate between the back-channel and the front-channel.
> 
> On Thu, Aug 13, 2020 at 5:15 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 13 Aug 2020 17:34:29 +0200

Indeed.

On Thu, Aug 13, 2020 at 5:33 PM Justin Richer <[email-masked]> wrote:

> A point I forgot to make below: the “front channel” isn’t going to exist
> for a lot of systems anymore, where interaction happens through an app or
> communication happens through some separate communication fabric. So there
> are cases, just like in OAuth 2, where there’s only a “back channel” and
> the other aspect of the AS never comes into play.
>
>  — Justin
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Aug 2020 08:40:35 -0700

I've often thought of front channel as an interaction visible to the user,
and back channel as being between two software systems, in this case, the
client and GS.

Consent from the user is the front channel, independent of how the user
gets to the GS, or if an app is part of the GS, or is the GS.
ᐧ

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Aug 2020 11:52:08 -0400

That’s true when the front channel (redirects between parties) is used as the method for interaction, but the point I was making is that that method isn’t going to be the only way that interaction happens. I don’t think it’s helpful to conflate other interaction mechanisms that don’t use redirections with URIs and query parameters as “front channel” here. The security models and surrounding assumptions are very different. 

 — Justin

> On Aug 13, 2020, at 11:40 AM, Dick Hardt <[email-masked]> wrote:
> 
> I've often thought of front channel as an interaction visible to the user, and back channel as being between two software systems, in this case, the client and GS.
> 
> Consent from the user is the front channel, independent of how the user gets to the GS, or if an app is part of the GS, or is the GS.
> ᐧ
> 
> On Thu, Aug 13, 2020 at 8:34 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Indeed.
> 
> On Thu, Aug 13, 2020 at 5:33 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 13, 2020, at 11:17 AM, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Aug 2020 08:59:05 -0700

A browser redirect has not been the only way that OAuth has worked. I
presented about device flows at IETF when I presented OAuth WRAP.

I do think the terms back channel and front channel are unlikely to be
helpful in the GNAP work.

My point was user awareness rather than protocol.

For example, a site making back channel calls to verify a user from a
"source" vs a front channel where the user is involved in consenting to the
release of data from a "source".

ᐧ

On Thu, Aug 13, 2020 at 8:52 AM Justin Richer <[email-masked]> wrote:

> That’s true when the front channel (redirects between parties) is used as
> the method for interaction, but the point I was making is that that method
> isn’t going to be the only way that interaction happens. I don’t think it’s
> helpful to conflate other interaction mechanisms that don’t use
> redirections with URIs and query parameters as “front channel” here. The
> security models and surrounding assumptions are very different.
>
>  — Justin
>
>>>> In OAuth 2.0, the user consent is performed by the AS using an
>>>> authorize endpoint where the user consent is solicited and captured.
>>>>
>>>> We already saw bits of this in OAuth 2: the AS is defined by the pair
>>>> of the token endpoint and authorization endpoint, each filling the
>>>> respective roles above. What if we formally separate these? Strawman names:
>>>>
>>>>

---

From: Tom Jones <[email-masked]>
Date: Thu, 13 Aug 2020 09:25:00 -0700

If you want to refer to the role i believe the correct term is user agent.
Peace ..tom

On Thu, Aug 13, 2020 at 8:27 AM Dick Hardt <[email-masked]> wrote:

> I think Tom's objection, and I agree with it, is that humans don't
> interact in bits and bytes.
>
>> I strong object to the objectification of human users. It is way past
>> time that the IETF becaume user oriented instead of web service oriented.
>>> If defined as the party operating the client software, then the user is
>>> a role. I believe this is more accurate and inclusive than the definition
>>> you have proposed with the user as an entity.
>>>
>>>  - Justin

---

From: Denis <[email-masked]>
Date: Thu, 13 Aug 2020 19:27:56 +0200

Dick,

> software interactions with software.
> The latter we can standardize, the former we can call out as part of 
> the overall process, but it is not something
> that is testable or required for interop, so I would argue human to 
> software interactions are NOT part of the protocol.

I disagree.  A set of a choices should be presented by the RS to the 
Client in a standardized way. The choices made by the user
should be locally recorded by the Client, hence the RS does not need to 
be informed of these choices. The RS will only know
the end result of these choices when/if it gets back one or more access 
tokens.

Human to software interactions should be part of the protocol.

    RS to Client: a set of choices

    Client to RS: Done (choices have been done by the user).

Denis

>
> ᐧ
>
> On Thu, Aug 13, 2020 at 8:11 AM Justin Richer <[email-masked] 
>     Also, whatever roles we define here, whether software or
>     human-ware, they need to be related to the protocol.
>
>      — Justin
>
>>     On Aug 13, 2020, at 10:59 AM, Tom Jones
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     I strong object to the objectification of human users. It is way
>>     past time that the IETF becaume user oriented instead of web
>>     service oriented.
>>         If defined as the party operating the client software, then
>>         the user is a role. I believe this is more accurate and
>>         inclusive than the definition you have proposed with the user
>>         as an entity.
>>
>>          - Justin
>>         Subject: Re: [GNAP] [Txauth] Revisiting the photo sharing
>>         example (a driving use case for the creation of OAuth)
>>
>>         Hi Francis
>>
>>         <[email-masked] <mailto:[email-masked]><mailto:[email-masked]
>>         <mailto:[email-masked]>>> wrote:
>>         <[email-masked]
>>         <mailto:[email-masked]><mailto:[email-masked]
>>         <mailto:[email-masked]>>> wrote:
>>         significant confusion. If we have a different role than what
>>         we have had in the past, then that role should have a name
>>         not being used already in OAuth or OIDC.
>>
>>         Given what we have learned, and my own experience explaining
>>         what a Client is, and is not, improving the definition for
>>         Client could prove useful. I am not suggesting the term be
>>         redefined, but clarified.
>>
>>         other roles at other times, or some other language to help
>>         differentiate between "role" and "entity".
>>
>>         /Dick
>>         <jricher@mit..edu<mailto:[email-masked]
>>         <mailto:[email-masked]>>> wrote:
>>         I’m in favor of coming up with a new term that’s a better
>>         fit, but I’m not really in favor of taking an existing term
>>         and applying a completely new definition to it. In other
>>         words, I would sooner stop using “client” and come up with a
>>         new, more specific and accurate term for the role than to
>>         define “client” as meaning something completely different. We
>>         did this in going from OAuth 1 to OAuth 2 already, moving
>>         from the even-more-confusing “consumer” to “client”, but
>>         OAuth 2 doesn’t use the term “consumer” at all, nor does it
>>         use “server” on its own but instead always qualifies it with
>>         GNAP can do something similar, in my opinion. But what we
>>         can’t do is ignore the fact that GNAP is going to be coming
>>         up in a world that is already permeated  by OAuth 2 and its
>>         terminology. We don’t have a blank slate to work with, but
>>         neither are we bound to use the same terms and constructs as
>>         <mailto:[email-masked]><mailto:[email-masked]
>>         <mailto:[email-masked]>>> wrote:
>>
>>         If we say that this document assumes OAuth2.0 terminology,
>>         then we should not change the meanings of any definition. If
>>         we are saying this supersedes or replaces what OAuth 2.0
>>         creates, then we should pick the best word for the job and
>>         ignore conflicting meanings from OAuth 2.0. I have a lot of
>>         first hand experience of industries "ruining words", and
>>         attempting to side-step the problem rather than redefining
>>         the word just confuses everyone as everyone forgets the
>>         original meaning as new documents come out, but the confusion
>>         with the use of a non-obvious word continues.
>>
>>         Food for thought.
>>         - Warren
>>
>>         architecture. Implement Authress<https://bit.
>>         <https://bit./>.ly/37SSO1p>.
>>
>>
>>         On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <[email-masked]
>>         <mailto:[email-masked]><mailto:[email-masked]
>>         <mailto:[email-masked]>>> wrote:
>>         Hi Denis,
>>
>>         <mailto:[email-masked]><mailto:[email-masked]
>>         <mailto:[email-masked]>>
>>         <mailto:[email-masked]><mailto:[email-masked]
>>         <mailto:[email-masked]>>
>>         <mailto:[email-masked]><mailto:[email-masked]
>>         <mailto:[email-masked]>>
>>         <mailto:[email-masked]><mailto:[email-masked]
>>         <mailto:[email-masked]>>

---

From: Denis <[email-masked]>
Date: Thu, 13 Aug 2020 19:29:22 +0200

Justin,

Your response does not address my point. I am talking of two different 
channels with the RS, i.e. not with the AS.

Denis

>> Since a user, with no prior experience, shall first connect to a RS 
>> to perform an operation, the user consent shall be performed by the RS,
> traditional AS that we might need to talk about separately now. One 
> deals with delegation, issuing tokens, returning data directly to the 
> client (not through a separate API, since that’s the RS), and other 
> back-channel stuff. The other aspect deals with interacting with the 
> user and/or resource owner.
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 13 Aug 2020 14:01:11 -0400

So what I’m saying is that what you’re defining as part of the RS was (in Oauth) defined as a function of the AS. As such, I contend that it needs to be its own separate functional role, neither AS nor RS.

That way it could be fulfilled by an entity either closely tied to the AS or closely tied to the RS, as appropriate. It would give us more flexibility to talk about the patterns.

 — Justin

> On Aug 13, 2020, at 1:29 PM, Denis <[email-masked]> wrote:
> 
>  Justin,
> 
> Your response does not address my point. I am talking of two different channels with the RS, i.e. not with the AS.
> 
> Denis
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Aug 2020 11:16:14 -0700

I don't see how we can technically standardize a user experience, and it is
not clear why a standard would be needed for interoperability.

 In many jurisdictions there are regulations regarding what information
needs to be conveyed to a user, and potentially a consent requirement, for
example a site explaining its use of cookies -- but I don't see how IETF
would play a role in that.

On a related note, the browsers attempted to standardize the username /
password prompt, and that has been rejected by pretty much every site. The
only site I've visited in the last decade that has used the browsers' built
in username / password prompt was the W3C site -- and it was a frustrating
experience since there was no button for account recovery -- it would just
keep popping up.

ᐧ

On Thu, Aug 13, 2020 at 10:29 AM Denis <[email-masked]> wrote:

> The latter we can standardize, the former we can call out as part of the
> overall process, but it is not something
> should be locally recorded by the Client, hence the RS does not need to be
> informed of these choices. The RS will only know

---

From: Francis Pouatcha <[email-masked]>
Date: Thu, 13 Aug 2020 14:59:18 -0400

Lots of mails, so I will summarize my opinion in this single mail:

We are dealing with different levels of abstraction here, this is why we
are always falling back to wording battles.

oAuth2/OIDC vs. GNAP
AS vs. GS/DS/IS
Entity vs. Roles
User (human) vs. Requestor
Client vs (Orchestrator/Requesting Party/Negotiator...)
front-channel & back-channel

To direct the discussion, we have to agree on the level of abstraction at
which we want a certain discussion to take place.

Abstraction Level-0: GNAP

Level-0 deals with roles (participants) and messages (request/responses).
Level-0 does not consider entities (users) or the nature of any other
participants, neither Level-0 deals with the way a message is transported
(synchronous/asynchronous) or the type of interaction used to materialize
the message (front-channel, back-channel). The purpose of this abstraction
layer is to provide a common understanding of the core elements of the
protocol.

Level-0 can still provide some basic definition of messages including
information schema as long as we are not limiting the protocol with
constraints from lower layers.

Level-0 is ideal to address some fundamental privacy and confidentiality
matters that will be materialized in lower layers.

Abstraction Level-1: OAuth2 / OIDC / [SSI/DiD/VC]
Instantiation of Level-0 for a constrained application space. This is why
we will meet the world Client, User, RO, AS, ... here roles defined in
Level-0 will be mapped to entities, interaction will be used to materialize
messages defined in Level-0.
The protocol mapping at this layer also takes into consideration that some
of those participants are human or only pieces of software, running on the
user device or on a server with consequences on the protocol design.

Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / ...

In Summary:
Level-0: Roles, Messages
Level-1: Entities, Interactions
...

And if it happens we want to define GNAP at Level-1 (instead of 0), let
declare it as such and limit the application space before we proceed with
further discussions.

Best regards.
/Francis

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Aug 2020 12:27:16 -0700

Hi Francis

I have come to a similar conclusion. I'll be posting my thoughts in a
concrete proposal and am keen to hear how it fits into how your mental
model.

/Dick
ᐧ

On Thu, Aug 13, 2020 at 12:00 PM Francis Pouatcha <fpo=
[email-masked]> wrote:

> we will meet the world Client, User, RO, AS, .... here roles defined in
> Abstraction Level-2: Trust Frameworks like IAM / PSD2,FAPI / ....
>
> In Summary:
> Level-0: Roles, Messages

---

From: Dave Tonge <[email-masked]>
Date: Fri, 14 Aug 2020 03:39:08 +0200

> I agree with clearly separating the GS interaction with the Client from
the interaction with the User.

I also struggle to see these as different roles - they seem to be
fundamentally linked,
However what I think does need to be taken into consideration is that there
may be multiple Grant Servers involved in a user flow (I've added a new use
case to describe some of these flows:
https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow
)

-- 

DISCLAIMER: This email

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 14 Aug 2020 08:29:01 +0200

Thanks, that's an important use case. Should add DID also.

This raises additional questions related to claim aggregation though, in
case you have contradictory information.

Le ven. 14 août 2020 à 03:39, Dave Tonge <[email-masked]> a écrit :

> > I'm having a hard time viewing those as two different roles. They are
> two different interactions. Just as the client interaction with the AS is
> However what I think does need to be taken into consideration is that
> there may be multiple Grant Servers involved in a user flow (I've added a
> new use case to describe some of these flows:

---

From: Denis <[email-masked]>
Date: Fri, 14 Aug 2020 12:12:19 +0200

This is a new thread built from "Revisiting the photo sharing example (a 
driving use case for the creation of OAuth)"

Justin,

> So what I’m saying is that what you’re defining as part of the RS was 
> (in Oauth) defined as a function of the AS.
> As such, I contend that it needs to be its own separate functional 
> role, neither AS nor RS.

I don't see that as separate roles, but as two different kinds of 
interactions with the same entity.

> That way it could be fulfilled by an entity either closely tied to the 
> AS or closely tied to the RS, as appropriate.
> It would give us more flexibility to talk about the patterns.

Nevertheless, such a possibility should be explored in more depth.

In my response to Dick I wrote:

    A set of a choices should be presented by the RS to the Client in a
    standardized way. The choices made by the user
    should be locally recorded by the Client, hence the RS does not need
    to be informed of these choices. The RS will only know
    the end result of these choices when/if it gets back one or more
    access tokens.

For a RS, before performing a given operation, the RS should specify to 
the User how many access tokens would be required, from which ASs
they could be obtained and which types of attributes these access tokens 
should contain.

For an AS, a key question would be whether some choices would be 
presented by the AS to the Client in a standardized way ? I don't know.
What would be such choices ?  I let Dick, yourself or someone else 
respond but I wonder that such choices could be presented by an AS
to a User (through the Client) in a standardized way.

Denis

>  — Justin
>
>> On Aug 13, 2020, at 1:29 PM, Denis <[email-masked] 
>> Your response does not address my point. I am talking of two 
>> different channels with the RS, i.e. not with the AS.
>>
>> Denis
>>
>>> interaction with the user from the web-based flows for the 
>>> delegation protocol, and that aspect is enshrined in the GNAP 
>>> charter as well.
>>>
>>> deals with delegation, issuing tokens, returning data directly to 
>>> the client (not through a separate API, since that’s the RS), and 
>>> other back-channel stuff. The other aspect deals with interacting 
>>> with the user and/or resource owner.
>>>
>>> We already saw bits of this in OAuth 2: the AS is defined by the 
>>> pair of the token endpoint and authorization endpoint, each filling 
>>> the respective roles above. What if we formally separate these? 
>>> Strawman names:
>>>

---

From: Denis <[email-masked]>
Date: Fri, 14 Aug 2020 12:14:04 +0200

Hi Dick,

> I don't see how we can technically standardize a user experience, and 
> it is not clear why a standard would be needed for interoperability.

I already wrote a proposal and made it available to the mailing list.

An access will be granted by a RS based on an mathematical expression 
which is formed using some combination of ANDand OR conditions.

Examples of combinations:

    /condition 1/AND/condition 2
    condition 1/OR /condition 2/
    (/condition 1/AND/condition 2)/OR/condition 3
    (condition 1/OR /condition 2)/AND/condition 3/

The following notation is being used for the /conditions/:

/condition x/= { AS identifier + set of attributes types }

Each RS internally constructs an /authorization table/ with the 
following content:

1°For the "authentication" operation: either FIDO U2For a mathematical 
expression using conditions;

2°For any other operation: a mathematical expression using conditions.

Given the operation selected by the client, the RS returns the 
appropriate mathematical expression and only the associated conditions
used in that mathematical expression. The User may then decide whether 
they are appropriate to him or not.

>  In many jurisdictions there are regulations regarding what 
> information needs to be conveyed to a user, and potentially a consent 
> requirement,
> for example a site explaining its use of cookies -- but I don't see 
> how IETF would play a role in that.
>
> On a related note, the browsers attempted to standardize the username 
> / password prompt, and that has been rejected by pretty much every site.
> The only site I've visited in the last decade that has used the 
> browsers' built in username / password prompt was the W3C site -- and 
> it was a frustrating
> experience since there was no button for account recovery -- it would 
> just keep popping up.

What I am proposing is unrelated to the two above cases you mention.

Denis

>
>
> ᐧ
>
> On Thu, Aug 13, 2020 at 10:29 AM Denis <[email-masked] 
>>     I think Tom's objection, and I agree with it, is that humans
>>     don't interact in bits and bytes.
>>
>>     I think it is useful to separate human interactions with software
>>     from software interactions with software.
>>     The latter we can standardize, the former we can call out as part
>>     of the overall process, but it is not something
>>     that is testable or required for interop, so I would argue human
>     I disagree.  A set of a choices should be presented by the RS to
>     the Client in a standardized way. The choices made by the user
>     should be locally recorded by the Client, hence the RS does not
>     need to be informed of these choices. The RS will only know
>>>         I strong object to the objectification of human users. It is
>>>         way past time that the IETF becaume user oriented instead of
>>>         web service oriented.
>>>         On Tue, Aug 11, 2020 at 4:38 PM Justin Richer
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             If defined as the party operating the client software,
>>>             then the user is a role. I believe this is more accurate
>>>             and inclusive than the definition you have proposed with
>>>             the user as an entity.
>>>
>>>              - Justin
>>>             Subject: Re: [GNAP] [Txauth] Revisiting the photo
>>>             sharing example (a driving use case for the creation of
>>>             OAuth)
>>>
>>>             Hi Francis
>>>
>>>             <[email-masked]
>>>             <mailto:[email-masked]><mailto:[email-masked]
>>>             In this context, I suggest we pick some words to work
>>>             with, and sharpen them as we move on, discover and map
>>>             new use cases to the protocol.
>>>
>>>             access to a protected resource. It starts with a
>>>             requestor delegating activity to an orchestrator. These
>>>             are all roles, no entities. Let focus on mapping the use
>>>             cases to the protocol roles and interactions so wwe can
>>>             discover what is missing.
>>>
>>>             "Orchestrator" (or whatever word we finally use) plays
>>>             the same role as the "Client" in oAuth2.
>>>
>>>             Best regards.
>>>             /Francis
>>>
>>>
>>>
>>>
>>>
>>>             should have a name not being used already in OAuth or OIDC.
>>>
>>>             <jricher@mit..edu
>>>             <mailto:jricher@mit..edu><mailto:[email-masked]
>>>             existing term and applying a completely new definition
>>>             to it. In other words, I would sooner stop using
>>>             “client” and come up with a new, more specific and
>>>             accurate term for the role than to define “client” as
>>>             meaning something completely different. We did this in
>>>             going from OAuth 1 to OAuth 2 already, moving from the
>>>             even-more-confusing “consumer” to “client”, but OAuth 2
>>>             doesn’t use the term “consumer” at all, nor does it use
>>>             “server” on its own but instead always qualifies it with
>>>             GNAP can do something similar, in my opinion. But what
>>>             we can’t do is ignore the fact that GNAP is going to be
>>>             coming up in a world that is already permeated  by OAuth
>>>             2 and its terminology. We don’t have a blank slate to
>>>             work with, but neither are we bound to use the same
>>>             terms and constructs as before. It’s going to be a
>>>             delicate balance!
>>>
>>>              — Justin
>>>
>>>             <[email-masked]
>>>             terminology, then we should not change the meanings of
>>>             any definition. If we are saying this supersedes or
>>>             replaces what OAuth 2.0 creates, then we should pick the
>>>             best word for the job and ignore conflicting meanings
>>>             from OAuth 2.0. I have a lot of first hand experience of
>>>             industries "ruining words", and attempting to side-step
>>>             the problem rather than redefining the word just
>>>             meaning as new documents come out, but the confusion
>>>             <[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Fri, 14 Aug 2020 10:28:21 -0400

I think the roles are linked, but so are the roles of the AS and RS (since the RS needs to trust and understand what the AS issues, ultimately). But by talking about them as separate roles, we can talk about ways to connect them, much the way that separating the AS from the RS (which were both just the “server” in OAuth 1) let us talk about JWTs and token introspection as methods for connecting the two.

And the thing is, people are already deploying the token-issuing portions and the interactive portions separately. For example these all point towards that:

https://github.com/ietf-wg-gnap/general/wiki/Decomposed-Grant-Server <https://github.com/ietf-wg-gnap/general/wiki/Decomposed-Grant-Server>

https://github.com/ietf-wg-gnap/general/wiki/Three-Client-server-use-cases-built-along-%22Privacy-by-Design%22.-Contribution-from-Denis <https://github.com/ietf-wg-gnap/general/wiki/Three-Client-server-use-cases-built-along-%22Privacy-by-Design%22.-Contribution-from-Denis>

https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow <https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow>

Additionally, this is similar to how Google deploys OAuth 2 today, with the user interactive portion and the token-issuing portion in separate trust domains. We can label these parts separately without defining a single method of connecting them, and importantly without assuming they’ll be in the same box for someone’s deployment. 

 — Justin

> On Aug 14, 2020, at 2:29 AM, Fabien Imbault <[email-masked]> wrote:
> 
> This raises additional questions related to claim aggregation though, in case you have contradictory information.
> 
> Le ven. 14 août 2020 à 03:39, Dave Tonge <[email-masked] <mailto:[email-masked]>> a écrit :
> > I agree with clearly separating the GS interaction with the Client from the interaction with the User. 
> 
> > I'm having a hard time viewing those as two different roles. They are two different interactions. Just as the client interaction with the AS is different from the client interaction with the GS.
> 
> I also struggle to see these as different roles - they seem to be fundamentally linked, 
> However what I think does need to be taken into consideration is that there may be multiple Grant Servers involved in a user flow (I've added a new use case to describe some of these flows: https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow <https://github.com/ietf-wg-gnap/general/wiki/Multiple-Authorization-Servers-in-a-single-flow>)
> 
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
>

---

From: Francis Pouatcha <[email-masked]>
Date: Fri, 14 Aug 2020 12:13:21 -0400

Small digest of the consent discussion into the suggested abstract flow.
Please do not nail on the words used (just working assumptions).
- GS is used to refer to the token manager (what Justin calls Delegation
Server (DS) - handles the back-channel stuff)
- AS is used to refer to the authorization server (what Justin calls
Interaction Server (IS) - handles the front-channel stuff)
- (End User), (Client) are sample entities materializing the corresponding
roles (in oAuth2 for example)

Added Separation between GS and AS (resp. DS and IS sse above)
- 3a: GS forwards request for the RC consent to an AS, that knows how to
interact with the RC
- 3b: AS returns RC consent to GS.
This separation might help draw a line between token management and user
authorization. This is essential for forward thinking into the world of
Fido, SSI, DID.

Display front channel and back channel (At the Abstraction Level-0 -GNAP,
this shall not matter.)
Steps (1, 4, 7) are good candidates for a front channel, as we are
interacting with a potential (End User).
Steps (2, 3, 5 , 6) are good candidates for back channel.
Steps (3a, 3b) are candidates for both, as AS might be running on a user
device.

Here is the new diagram.

+-----------+      +--------------+  +----+
 +----+   +----+  +---------------------+
| Requestor |      | Orchestrator |  |    |  |    |   |    |  | Resource
Controller |
|           |      |              |  | RS |  | GS |   | AS |  |
         |
|(End User) |      |   (Client)   |  |    |  |    |   |    |  |      (End
User)     |
+-----------+      +--------------+  +----+
 +----+   +----+  +---------------------+
  |(1) ServiceRequest     |            |       |        |                |
  |---------------------->|            |       |        |                |
  |                       |(2) ServiceIntent:AuthZChallenge              |
  |                       |<---------->|       |        |                |
  |                       |            |       |        |                |
  |                       |(3) AuthZRequest(AuthZChallenge)              |
  |                       |------------------->|        |                |
  |                       |            |
 |(3a)ConsentRequest(AuthZChallenge)
  |                       |            |       |------->|                |
  |                       |            |       |        |(4)
ConsentRequest:Consent
  |                       |            |       |        |<-------------->|
  |                       |            |       |(3b)UserConsent          |
  |                       |            |       |<-------|                |
  |                       |(5) GrantAccess(AuthZ).      |                |
  |                       |<-------------------|        |                |
  |                       |            |       |        |                |
  |                       |(6) ServiceRequest(AuthZ):ServiceResponse.    |
  |                       |<---------->|       |        |                |
  |(7) ServiceResponse    |            |       |        |                |
  |<----------------------|            |       |        |                |
  +                       +            +       +        +                +

Best regards.
/Francis

On Fri, Aug 14, 2020 at 6:14 AM Denis <[email-masked]> wrote:

> I don't see how we can technically standardize a user experience, and it
> is not clear why a standard would be needed for interoperability.
>
> which is formed using some combination of AND and OR conditions.
>
> *condition 1* AND
> *condition 2 condition 1* OR *condition 2*
> (*condition 1* AND *condition 2)* OR
> *condition 3 (condition 1* OR *condition 2)* AND *condition 3*
>
> The following notation is being used for the *conditions*:
>
> *condition x* = { AS identifier + set of attributes types }
>
> Each RS internally constructs an *authorization table* with the following
> content:
>
> 1°  For the "authentication" operation: either FIDO U2F or a mathematical
> 2°  For any other operation: a mathematical expression using conditions.
>
> Given the operation selected by the client, the RS returns the appropriate
> mathematical expression and only the associated conditions
> needs to be conveyed to a user, and potentially a consent requirement,
> for example a site explaining its use of cookies -- but I don't see how
> IETF would play a role in that.
>
> password prompt, and that has been rejected by pretty much every site.
> The only site I've visited in the last decade that has used the browsers'
> built in username / password prompt was the W3C site -- and it was a
> frustrating
>>>> It seems cumbersome to use it in discussions as it is impossible to
>>>> give the word "Client" a clear definition.
>>>>
>>>> significant confusion. If we have a different role than what we have had in
>>>> the past, then that role should have a name not being used already in OAuth
>>>> or OIDC.
>>>>

---

From: Tom Jones <[email-masked]>
Date: Fri, 14 Aug 2020 09:39:02 -0700

Here are some proposals that are working their way through other channels.
1. on consent grant.: https://wiki.idesg.org/wiki/index.php/Consent_Grant
2 on delegations: https://wiki.idesg.org/wiki/index.php/Delegation
Comments are welcomed.
Peace ..tom

On Fri, Aug 14, 2020 at 9:13 AM Francis Pouatcha <fpo=
[email-masked]> wrote:

>> Each RS internally constructs an *authorization table* with the
>> following content:
>>
>> 1°  For the "authentication" operation: either FIDO U2F or a
>> mathematical expression using conditions;
>>
>>>>> If defined as the party operating the client software, then the user
>>>>> is a role. I believe this is more accurate and inclusive than the
>>>>> definition you have proposed with the user as an entity.
>>>>>
>>>>>  - Justin
>>>>> In this context, I suggest we pick some words to work with, and
>>>>> sharpen them as we move on, discover and map new use cases to the protocol.
>>>>>

---

From: Denis <[email-masked]>
Date: Fri, 14 Aug 2020 18:39:45 +0200

Hi Francis,

In the proposed flow, between (2) and (3), there should be a flow for 
the User Consent. That flow is missing.

In addition, keep in mind that the Resource Controller (RC) can be an 
application with no end-user involved.
Hence, there is no "consent" from such an application, but only the 
enforcement of some rules.

I do not see the relationship with the topic raised in that thread which 
is about User Consent based on information
provided to the User by the RS. If you want to discuss something else, 
please open a new thread.

Denis

> Small digest of the consent discussion into the suggested abstract 
> flow. Please do not nail on the words used (just working assumptions).
> - GS is used to refer to the token manager (what Justin calls 
> Delegation Server (DS) - handles the back-channel stuff)
> - (End User), (Client) are sample entities materializing the 
> corresponding roles (in oAuth2 for example)
>
> - 3a: GS forwards request for the RC consent to an AS, that knows how 
> to interact with the RC
> This separation might help draw a line between token management and 
> user authorization. This is essential for forward thinking into the 
> world of Fido, SSI, DID.
>
> Display front channel and back channel (At the Abstraction Level-0 
> -GNAP, this shall not matter.)
> Steps (3a, 3b) are candidates for both, as AS might be running on a 
> user device.
>
> Here is the new diagram.
>
> | Requestor |      | Orchestrator |  |    |  |    |   |    |  | 
> Resource Controller |
> |           |      | |  | RS |  | GS |   | AS |  |                     |
> |(End User) |      |   (Client) |  |    |  |    |   |    |  |      
> (End User)     |
> On Fri, Aug 14, 2020 at 6:14 AM Denis <[email-masked] 
>     This is a new thread built from "Revisiting the photo sharing
>     example (a driving use case for the creation of OAuth)"
>
>     Hi Dick,
>
>>     I don't see how we can technically standardize a user experience,
>>     and it is not clear why a standard would be needed for
>>     interoperability.
>
>     An access will be granted by a RS based on an mathematical
>     expression which is formed using some combination of ANDand OR
>     conditions.
>
>     1°For the "authentication" operation: either FIDO U2For a
>     used in that mathematical expression. The User may then decide
>     whether they are appropriate to him or not.
>
>>     information needs to be conveyed to a user, and potentially a
>>     consent requirement,
>>     for example a site explaining its use of cookies -- but I don't
>>     see how IETF would play a role in that.
>>
>>     On a related note, the browsers attempted to standardize the
>>     username / password prompt, and that has been rejected by pretty
>>     much every site.
>>     browsers' built in username / password prompt was the W3C site --
>>     and it was a frustrating
>>     experience since there was no button for account recovery -- it
>>     would just keep popping up.
>
>>>         I think it is useful to separate human interactions with
>>>         software from software interactions with software.
>>>         The latter we can standardize, the former we can call out as
>>>         part of the overall process, but it is not something
>>>         that is testable or required for interop, so I would argue
>>>         human to software interactions are NOT part of the protocol.
>>
>>         I disagree.  A set of a choices should be presented by the RS
>>         to the Client in a standardized way. The choices made by the
>>         user
>>         should be locally recorded by the Client, hence the RS does
>>         not need to be informed of these choices. The RS will only know
>>         the end result of these choices when/if it gets back one or
>>         more access tokens.
>>
>>>         On Thu, Aug 13, 2020 at 8:11 AM Justin Richer
>>>>             I strong object to the objectification of human users.
>>>>             It is way past time that the IETF becaume user oriented
>>>>             instead of web service oriented.
>>>>                 If defined as the party operating the client
>>>>                 software, then the user is a role. I believe this
>>>>                 is more accurate and inclusive than the definition
>>>>                 sharing example (a driving use case for the
>>>>                 creation of OAuth)
>>>>
>>>>                 Hi Francis
>>>>
>>>>                 The user is an entity, not a role in the protocol
>>>>                 in how I am defining roles, so steps (1) and (7)
>>>>                 are confusing to me on what is happening.
>>>>
>>>>                 I also think that (2) could be an extension to
>>>>                 GNAP, rather than part of the core protocol.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                 In this context, I suggest we pick some words to
>>>>                 work with, and sharpen them as we move on, discover
>>>>                 and map new use cases to the protocol.
>>>>
>>>>                  |<-------------->|
>>>>                 The purpose of the GNAP protocol is to help
>>>>                 negotiate access to a protected resource. It starts
>>>>                 with a requestor delegating activity to an
>>>>                 orchestrator. These are all roles, no entities. Let
>>>>                 focus on mapping the use cases to the protocol
>>>>                 roles and interactions so wwe can discover what is
>>>>                 missing.
>>>>
>>>>                 It seems cumbersome to use it in discussions as it
>>>>                 is impossible to give the word "Client" a clear
>>>>                 definition.
>>>>
>>>>                 "Orchestrator" (or whatever word we finally use)
>>>>                 plays the same role as the "Client" in oAuth2.
>>>>
>>>>                 Best regards.
>>>>                 /Francis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                 I agree with Justin. Redefining well used terms
>>>>                 will lead to significant confusion. If we have a
>>>>                 different role than what we have had in the past,
>>>>                 explaining what a Client is, and is not, improving
>>>>                 the definition for Client could prove useful. I am
>>>>                 not suggesting the term be redefined, but clarified.
>>>>
>>>>                 entity plays in the protocol, and that the same
>>>>                 entity may play other roles at other times, or some
>>>>                 other language to help differentiate between "role"
>>>>                 and "entity".
>>>>
>>>>                 /Dick
>>>>                 conflicting meanings from OAuth 2.0. I have a lot
>>>>                 of first hand experience of industries "ruining
>>>>                 words", and attempting to side-step the problem
>>>>                 rather than redefining the word just confuses
>>>>                 everyone as everyone forgets the original meaning
>>>>                 as new documents come out, but the confusion with
>>>>                 the use of a non-obvious word continues.
>>>>
>>>>                 Food for thought.
>>>>                 - Warren
>>>>
>>>>                 authorization architecture. Implement
>>>>                 Authress<https://bit. <https://bit./>.ly/37SSO1p>.
>>>>
>>>>

---

From: Denis <[email-masked]>
Date: Fri, 14 Aug 2020 18:47:56 +0200

Tom,

I will make a reply similar to the one sent to Francis.

You are willing to discuss something else, please open one or two new 
threads (since there are two new topics).

Denis

> On Fri, Aug 14, 2020 at 9:13 AM Francis Pouatcha 
> <fpo=[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     - AS is used to refer to the authorization server (what Justin
>     calls Interaction Server (IS) - handles the front-channel stuff)
>     - 3a: GS forwards request for the RC consent to an AS, that knows
>     how to interact with the RC
>     This separation might help draw a line between token management
>     and user authorization. This is essential for forward thinking
>     into the world of Fido, SSI, DID.
>
>     Steps (3a, 3b) are candidates for both, as AS might be running on
>     a user device.
>
>     Here is the new diagram.
>
>       |                       |          |       |------->|           
>>         I don't see how we can technically standardize a user
>>         experience, and it is not clear why a standard would be
>>         needed for interoperability.
>
>         Each RS internally constructs an /authorization table/ with
>         the following content:
>
>>         for example a site explaining its use of cookies -- but I
>>         don't see how IETF would play a role in that.
>>
>>         username / password prompt, and that has been rejected by
>>         pretty much every site.
>>         The only site I've visited in the last decade that has used
>>         the browsers' built in username / password prompt was the W3C
>>         site -- and it was a frustrating
>>         experience since there was no button for account recovery --
>>         it would just keep popping up.
>
>>>             I think Tom's objection, and I agree with it, is that
>>>             humans don't interact in bits and bytes.
>>>
>>>             The latter we can standardize, the former we can call
>>>             out as part of the overall process, but it is not something
>>>             that is testable or required for interop, so I would
>>>             argue human to software interactions are NOT part of the
>>>             protocol.
>>
>>             I disagree.  A set of a choices should be presented by
>>             the RS to the Client in a standardized way. The choices
>>             made by the user
>>             should be locally recorded by the Client, hence the RS
>>             does not need to be informed of these choices. The RS
>>             will only know
>>             the end result of these choices when/if it gets back one
>>             or more access tokens.
>>
>>>                 It’s a role fulfilled by a person, so I’m not sure
>>>                 where the objection you’re raising comes from.
>>>
>>>                 Also, whatever roles we define here, whether
>>>                 software or human-ware, they need to be related to
>>>                 the protocol.
>>>
>>>                  — Justin
>>>
>>>>                 I strong object to the objectification of human
>>>>                 users. It is way past time that the IETF becaume
>>>>                 user oriented instead of web service oriented.
>>>>                     software, then the user is a role. I believe
>>>>                     this is more accurate and inclusive than the
>>>>                     Subject: Re: [GNAP] [Txauth] Revisiting the
>>>>                     photo sharing example (a driving use case for
>>>>                     the creation of OAuth)
>>>>
>>>>                     Hi Francis
>>>>
>>>>                     The user is an entity, not a role in the
>>>>                     protocol in how I am defining roles, so steps
>>>>                     (1) and (7) are confusing to me on what is
>>>>                     happening.
>>>>
>>>>                     On Mon, Aug 10, 2020 at 8:04 PM Francis
>>>>                     Pouatcha <[email-masked]
>>>>                     In this context, I suggest we pick some words
>>>>                     to work with, and sharpen them as we move on,
>>>>                     discover and map new use cases to the protocol.
>>>>
>>>>                     negotiate access to a protected resource. It
>>>>                     starts with a requestor delegating activity to
>>>>                     an orchestrator. These are all roles, no
>>>>                     entities. Let focus on mapping the use cases to
>>>>                     the protocol roles and interactions so wwe can
>>>>                     It seems cumbersome to use it in discussions as
>>>>                     it is impossible to give the word "Client" a
>>>>                     clear definition.
>>>>
>>>>                     "Orchestrator" (or whatever word we finally
>>>>                     use) plays the same role as the "Client" in oAuth2.
>>>>
>>>>                     Best regards.
>>>>                     /Francis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                     will lead to significant confusion. If we have
>>>>                     a different role than what we have had in the
>>>>                     past, then that role should have a name not
>>>>                     being used already in OAuth or OIDC.
>>>>
>>>>                     Given what we have learned, and my own
>>>>                     experience explaining what a Client is, and is
>>>>                     not, improving the definition for Client could
>>>>                     prove useful. I am not suggesting the term be
>>>>                     For example, clarifying that a Client is a role
>>>>                     an entity plays in the protocol, and that the
>>>>                     same entity may play other roles at other
>>>>                     times, or some other language to help
>>>>                     I’m in favor of coming up with a new term
>>>>                     that’s a better fit, but I’m not really in
>>>>                     favor of taking an existing term and applying a
>>>>                     completely new definition to it. In other
>>>>                     words, I would sooner stop using “client” and
>>>>                     come up with a new, more specific and accurate
>>>>                     term for the role than to define “client” as
>>>>                     meaning something completely different. We did
>>>>                     this in going from OAuth 1 to OAuth 2 already,
>>>>                     moving from the even-more-confusing “consumer”
>>>>                     to “client”, but OAuth 2 doesn’t use the term
>>>>                     “consumer” at all, nor does it use “server” on
>>>>                     its own but instead always qualifies it with
>>>>                     GNAP can do something similar, in my opinion.
>>>>                     But what we can’t do is ignore the fact that
>>>>                     GNAP is going to be coming up in a world that
>>>>                     is already permeated  by OAuth 2 and its
>>>>                     terminology. We don’t have a blank slate to
>>>>                     work with, but neither are we bound to use the
>>>>                     same terms and constructs as before. It’s going
>>>>                     to be a delicate balance!
>>>>
>>>>                      — Justin
>>>>
>>>>                     meanings of any definition. If we are saying
>>>>                     this supersedes or replaces what OAuth 2.0
>>>>                     creates, then we should pick the best word for
>>>>                     the job and ignore conflicting meanings from
>>>>                     OAuth 2.0. I have a lot of first hand
>>>>                     experience of industries "ruining words", and
>>>>                     attempting to side-step the problem rather than
>>>>                     documents come out, but the confusion with the
>>>>                     use of a non-obvious word continues.
>>>>
>>>>                     Food for thought.
>>>>                     - Warren
>>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Fri, 14 Aug 2020 13:03:31 -0400

Hi Denis,

On Fri, Aug 14, 2020 at 12:39 PM Denis <[email-masked]> wrote:

> Hi Francis,
>
> In the proposed flow, between (2) and (3), there should be a flow for the
> User Consent. That flow is missing.
>
What User? (End User -> Requestor) or (End User -> Resource Controller)?
What if both are not the same party?

> enforcement of some rules.
Means you are obtaining the consent from an "End User" in his role as a
"Requestor" of the service? What do you need this consent for?

> please open a new thread.
NO! Correct thread! Without the diagram, there is no way the reader can
figure out what is being discussed here.

/Francis

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 Aug 2020 13:27:43 -0700

Denis, a mathematical expression is not a user experience.

While we may be able to standardize the result of a user experience, that
is not the same thing.

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 17 Aug 2020 10:04:55 +0200

Hi,

They're not the same thing for me either. AND/OR conditions are logical
operators, but it's the responsibility of the UI to display them however
they wish.

We still can discuss good practices of how the UI may look like (and which
can be useful for reference implementations), but it's only informative in
my opinion.
An example of similar discussions:
https://github.com/WICG/WebID/blob/master/design.md

Fabien

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 19 Aug 2020 12:31:08 +0200

Just wondering if that might be a way to compose the generic
transaction/continuation pattern (XYZ style, layer 1) from a lower-level
GS-API (layer 0).
Fabien

On Thu, Aug 13, 2020 at 9:28 PM Dick Hardt <[email-masked]> wrote:

>> The protocol mapping at this layer also takes into consideration that
>> some of those participants are human or only pieces of software, running on
>> the user device or on a server with consequences on the protocol design.
>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 19 Aug 2020 11:09:19 -0400

In my perspective, the focus should be on defining the protocol: what you’d call the transaction pattern. We can potentially use a API language to describe how an entity can perform a role within that protocol, but ultimately we should be defining the protocol.

 — Justin

> On Aug 19, 2020, at 6:31 AM, Fabien Imbault <[email-masked]> wrote:
> 
> Just wondering if that might be a way to compose the generic transaction/continuation pattern (XYZ style, layer 1) from a lower-level GS-API (layer 0).
> Fabien
> 
> On Thu, Aug 13, 2020 at 9:28 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Francis
> 
> I have come to a similar conclusion. I'll be posting my thoughts in a concrete proposal and am keen to hear how it fits into how your mental model.
> 
> /Dick
> ᐧ
> 
> On Thu, Aug 13, 2020 at 12:00 PM Francis Pouatcha <fpo=[email-masked] <mailto:[email-masked]>> wrote:
> We are dealing with different levels of abstraction here, this is why we are always falling back to wording battles.
> 
> oAuth2/OIDC vs. GNAP
> AS vs. GS/DS/IS
> Entity vs. Roles
> To direct the discussion, we have to agree on the level of abstraction at which we want a certain discussion to take place.
> 
> Level-0 deals with roles (participants) and messages (request/responses). Level-0 does not consider entities (users) or the nature of any other participants, neither Level-0 deals with the way a message is transported (synchronous/asynchronous) or the type of interaction used to materialize the message (front-channel, back-channel). The purpose of this abstraction layer is to provide a common understanding of the core elements of the protocol. 
> 
> Level-0 can still provide some basic definition of messages including information schema as long as we are not limiting the protocol with constraints from lower layers.
> 
> Level-0 is ideal to address some fundamental privacy and confidentiality matters that will be materialized in lower layers.
> 
> Instantiation of Level-0 for a constrained application space. This is why we will meet the world Client, User, RO, AS, .... here roles defined in Level-0 will be mapped to entities, interaction will be used to materialize messages defined in Level-0. 
> The protocol mapping at this layer also takes into consideration that some of those participants are human or only pieces of software, running on the user device or on a server with consequences on the protocol design.
> 
> And if it happens we want to define GNAP at Level-1 (instead of 0), let declare it as such and limit the application space before we proceed with further discussions.
> 
> Best regards.
> /Francis
> 
> 
> 
> 
> On Thu, Aug 13, 2020 at 1:30 PM Denis <[email-masked] <mailto:[email-masked]>> wrote:
>  Justin,
> 
> https://adorsys-platform.de/solutions/ <https://adorsys-platform.de/solutions/>-- 
> TXAuth mailing list

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 19 Aug 2020 19:15:47 +0200

Indeed.

Le mer. 19 août 2020 à 17:09, Justin Richer <[email-masked]> a écrit :

> In my perspective, the focus should be on defining the protocol: what
> you’d call the transaction pattern. We can potentially use a API language
> to describe how an entity can perform a role within that protocol, but
> ultimately we should be defining the protocol.
>
>  — Justin
>
>>> To direct the discussion, we have to agree on the level of abstraction
>>> at which we want a certain discussion to take place.
>>>
>>> Level-0 deals with roles (participants) and messages
>>> (request/responses). Level-0 does not consider entities (users) or the
>>> nature of any other participants, neither Level-0 deals with the way a
>>> message is transported (synchronous/asynchronous) or the type of
>>> interaction used to materialize the message (front-channel, back-channel).
>>> The purpose of this abstraction layer is to provide a common understanding
>>> of the core elements of the protocol.
>>>
>>> Instantiation of Level-0 for a constrained application space. This is
>>> why we will meet the world Client, User, RO, AS, .... here roles defined in