Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

From: Dick Hardt <[email-masked]>
Date: Thu, 2 Jul 2020 10:59:40 -0700

Catching up on this email ... comments inserted ...

On Mon, Jun 29, 2020 at 12:06 AM Denis <[email-masked]> wrote:

> Hello Dick,
>
> Denis, thanks for sharing your thoughts, some clarifications on your
> statements inserted:
>
> On Fri, Jun 26, 2020 at 9:42 AM Denis <[email-masked]> wrote:
> <snip>
>
>> *New proposed charter*
>>
>> <snip>
>
>>
>> Resource servers inform their clients about which access token formats
>> are acceptable and depending upon the king of operation
>> that is requested, which kind of attributes are needed and from which ASs
>> that my be obtained.
>>
>> While at times this may be appropriate, at other times disclosing the
> attributes the RS requires is not needed by the client.
> For example, an enterprise client accessing a resource does not need to
> know which groups a user belongs to,
> but the RS may require that to determine if the user running the client
> has access.
>
> As soon as there is a desire to implement privacy by default, the client
> should not provide more attributes than strictly necessary.
> Even after three readings of your example, I failed to understand it.
>
>
>> A major difference with OAuth 2.0 is that there is no bilateral trust
>> relationship between an authorization server and a resource server:
>> for a given category of attributes, a resource server may trust one or
>> more authorization servers. Another major difference with OAuth 2.0.
>> is that the content of an attributes token is meant to be accessible to
>> the client.
>>
>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF
> presentation on what became OAuth 2.0
>
> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>
> I looked at the two slides.
>
> Unfortunately slide 7 has just one arrow with the word "trust". This is
> insufficient to understand what is meant unless being present
> at the presentation. Does it mean that the PR (RS) trusts one AS or that
> it may trust multiple ASs ?
>
Unfortunately slide 8 has just one arrow between the PR and the AS which is
> red-crossed but no text at all. This is insufficient to understand
> what is meant unless being present at the presentation. Does it mean that
> the PR and the AS never communicate directly ?
> Does it mean that they have no relationships at all, besides the one way
> trust relationship mentioned in slide 7 ?
>
> So it hard to say whether these two slides are indeed meaning that there
> is no bilateral relationship between an authorization server and a resource
> server.
>
Apologies for not providing an explanation on the slides.

Slide 7 shows that trust between the AS and PR (now RS) was unidirectional,
from the RS to the AS.
Slide 8 indicates that trust is not bidirectional.

There is no limit on how many ASs an RS may trust.

> On June 12, Nat Sakimura recently answered to an email with the following
> topic:
>
> Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
> Authorization Framework: JWT Secured Authorization Request))
>
> My arguments were:
>
>      The original model for OAuth was making the assumption that the AS
> and the RS had a strong bilateral relationship.
>
>       *A key question is whether such strong relationship will be
> maintained for ever *or
>      whether it will be allowed to perform some evolutions of this
> relationship.
>
>      In order to respect the privacy of the users, there is the need to
> encompass other scenarios. One of these scenarios is that the AS and the RS
>      do not need any longer to have such a strong relationship. In terms
> of trust relationships, a RS simply needs to trust the access tokens issued
> by an AS.
>      The AS does have any more a "need to know" of all the RSs that are
> accepting its access tokens. This would be a major simplification of the
> current global architecture.
>
> Nat's position was:
>
> "My take is that the basic assumption of OAuth 2.0 Framework is that there
> is a strong relationship between AS and RS.
> I feel that it is quite unrealistic that an RS would trust the access
> token issued by an AS that it has no strong relationship with".
>
> There are indeed different positions on this topic.
>

I don't think Nat and I have different opinions, but I will let Nat clarify.
Just because there is a strong relationship between the AS and RS, does not
mean it is bidirectional. I would understand

"I feel that it is quite unrealistic that an RS would trust the access
token issued by an AS that it has no strong relationship with"

to indicate Nat is expecting the trust to be from the RS to the AS.

>
> The AS may not even know who the RS (or PR in the slides) is.
>
> <snip>
>
>>
>> I got rid of the word "delegation": the client does not delegate anything
>> to an authorization server. If it would, this would mean that the
>> authorization server
>> would be able to act as the client and could know everything that the
>> client will do, which comes into contradiction with the user's privacy.
>>
>
> The above is not true.
>
> The Resource Owner is delegating access control to the AS in authorization
> use cases.
>
> The OAuth 2.0 model does not mandate any more the presence of a Resource
> Owner.
>

Why do you say that? The RO is who owns the RS. Your statement does not
make sense.

>
> The client is may be delegating user authentication to the AS in identity
> claim use cases.
>
> Delegating user authentication to the AS is different from delegating
> access control to the AS.
>

Agreed. Your statement was there was no delegation. I'm explaining there
are potentially two delegations.

>
> The AS can act as the client in many OAuth deployments, as the access
> token is a bearer token.
>
> A bearer token is rather insecure.
>
Cookies are also bearer tokens. But we use them all the time in web apps
for storing session state and prior authentication! :)

> That does not mean the AS knows what the client is doing.
>
> There are currently two attempts in the OAuth WG to let know to the AS
> what the client is doing:
>
>    - draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization Framework:
>    JWT Secured Authorization Request)
>    - draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization
>    Requests)
>
> Those are optional, and in some situations are a desired property.

/Dick

---

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

(dropping IESG, adding Nat as Denis is quoting him)

On Thu, Jul 2, 2020 at 10:59 AM Dick Hardt <[email-masked]> wrote:

>>> that is requested, which kind of attributes are needed and from which
>>> ASs that my be obtained.
>>>
>>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original
>> IETF presentation on what became OAuth 2.0
>>
> Unfortunately slide 8 has just one arrow between the PR and the AS which
>> is red-crossed but no text at all. This is insufficient to understand
> Slide 7 shows that trust between the AS and PR (now RS) was
> unidirectional, from the RS to the AS.
>> On June 12, Nat Sakimura recently answered to an email with the
>> following topic:
>>
>> "My take is that the basic assumption of OAuth 2.0 Framework is that
>> there is a strong relationship between AS and RS.
> Just because there is a strong relationship between the AS and RS, does
> not mean it is bidirectional. I would understand
>
>>> I got rid of the word "delegation": the client does not delegate
>>> anything to an authorization server. If it would, this would mean that the
>>> authorization server
>> The Resource Owner is delegating access control to the AS in
>> authorization use cases.
>>
>>    - draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization
>>    Framework: JWT Secured Authorization Request)

---

From: Denis <[email-masked]>
Date: Fri, 3 Jul 2020 11:16:19 +0200

Hello Dick,

> On Mon, Jun 29, 2020 at 12:06 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello Dick,
>
>>     Denis, thanks for sharing your thoughts, some clarifications on
>>     your statements inserted:
>>
>>     On Fri, Jun 26, 2020 at 9:42 AM Denis <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     <snip>
>>
>>             *New proposed charter*
>>
>>     <snip>
>>
>>
>>             Resource servers inform their clients about which access
>>             token formats are acceptable and depending upon the king
>>             of operation
>>             that is requested, which kind of attributes are needed
>>             and from which ASs that my be obtained.
>>
>>     While at times this may be appropriate, at other times disclosing
>>     the attributes the RS requires is not needed by the client.
>>     For example, an enterprise client accessing a resource does not
>>     need to know which groups a user belongs to,
>>     but the RS may require that to determine if the user running the
>>     client has access.
>
>     As soon as there is a desire to implement privacy by default, the
>     client should not provide more attributes than strictly necessary.
>>             A major difference with OAuth 2.0 is that there is no
>>             bilateral trust relationship between an authorization
>>             server and a resource server:
>>             for a given category of attributes, a resource server may
>>             trust one or more authorization servers. Another major
>>             difference with OAuth 2.0.
>>             is that the content of an attributes token is meant to be
>>             accessible to the client.
>>
>>     This is not how OAuth 2.0 works. See slides 7 and 8 from my
>>     original IETF presentation on what became OAuth 2.0
>>
>     Unfortunately slide 7 has just one arrow with the word "trust".
>     This is insufficient to understand what is meant unless being present
>     at the presentation. Does it mean that the PR (RS) trusts one AS
>     or that it may trust multiple ASs ?
>
>     Unfortunately slide 8 has just one arrow between the PR and the AS
>     which is red-crossed but no text at all. This is insufficient to
>     understand
>     what is meant unless being present at the presentation. Does it
>     mean that the PR and the AS never communicate directly ?
>     Does it mean that they have no relationships at all, besides the
>     one way trust relationship mentioned in slide 7 ?
>
>     So it hard to say whether these two slides are indeed meaning that
>     there is no bilateral relationship between an authorization server
>     and a resource server.
>

[Denis]  ... which means that slide 8 contradicts slide 7.  :-)

I would have preferred that you meant: the RS and the AS never 
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy.

> There is no limit on how many ASs an RS may trust.

[Denis] This is fine.

>         Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The
>         OAuth 2.0 Authorization Framework: JWT Secured Authorization
>         Request))
>
>     My arguments were:
>
>          The original model for OAuth was making the assumption that
>     the AS and the RS had a strong bilateral relationship.
>
>          In order to respect the privacy of the users, there is the
>     need to encompass other scenarios. One of these scenarios is that
>     the AS and the RS
>          do not need any longer to have such a strong relationship. In
>     terms of trust relationships, a RS simply needs to trust the
>     access tokens issued by an AS.
>          The AS does have any more a "need to know" of all the RSs
>     that are accepting its access tokens. This would be a major
>     simplification of the current global architecture.
>
>     Nat's position was:
>
>         "My take is that the basic assumption of OAuth 2.0 Framework
>         is that there is a strong relationship between AS and RS.
>         I feel that it is quite unrealistic that an RS would trust the
>         access token issued by an AS that it has no strong
>         relationship with".
>
> Just because there is a strong relationship between the AS and RS, 
> does not mean it is bidirectional. I would understand
>

[Denis]  Speaking of a "strong relationship" is ambiguous. The key point 
being whether the relationship is unilateral or bilateral.
There is no need to use the wording "strong relationship" when the 
relationship is only unilateral: a RS simply trusts an AS for the access 
tokens it issues.
In such a case, this does not mean that an AS is knowing all the RSs 
that are trusting it.

On the contrary, a strong (bi-)relationship is when a RS and an AS both 
agree between them about the meaning of scope parameters.
This is a typical case for OAuth 2.0.

>>         I got rid of the word "delegation": the client does not
>>         delegate anything to an authorization server. If it would,
>>         this would mean that the authorization server
>>         would be able to act as the client and could know everything
>>         that the client will do, which comes into contradiction with
>>         the user's privacy.
>>
>>
>>     The above is not true.
>     The OAuth 2.0 model does not mandate any more the presence of a
>     Resource Owner.
>
>
> Why do you say that? The RO is who owns the RS. Your statement does 
> not make sense.

[Denis]  I mean that there is not necessarily a protocol defined so that 
the RO can interact with the requests from the clients.

>>
>>     The client is may be delegating user authentication to the AS in
>>     identity claim use cases.
>
>     Delegating user authentication to the AS is different from
>     delegating access control to the AS.
>
>
> Agreed. Your statement was there was no delegation. I'm explaining 
> there are potentially two delegations.
>
>>
>>     The AS can act as the client in many OAuth deployments, as the
>>     access token is a bearer token.
>
> Cookies are also bearer tokens. But we use them all the time in 
> web apps for storing session state and prior authentication! :)
>
>     There are currently two attempts in the OAuth WG to let know to
>     the AS what the client is doing:
>
>       * draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization
>       * draft-ietf-oauth-rar-01     (OAuth 2.0 Rich Authorization
>         Requests)
>

[Denis]  However, in these two drafts, the privacy considerations 
sections are silent on this point.

Denis

---

From: Dick Hardt <[email-masked]>
Date: Fri, 3 Jul 2020 18:41:19 -0700

+ Nat as he is mentioned
- IESG

> [Denis]  ... which means that slide 8 contradicts slide 7.  :-)

Slide 8 says it does not go both ways. Slide 7 says it goes one way. I
don't see the contradiction.

> I would have preferred that you meant: the RS and the AS never communicate
> directly, which is indeed a nice property to follow
That is one model. Other models are appropriate in other circumstances.

> In such a case, this does not mean that an AS is knowing all the RSs that
> are trusting it.
>
You can ask Nat what he meant by "strong relationship"

The AS is stating what a scope means to it and the user. The RS can do
whatever it wants. I don't see that as requiring a bidirectional
relationship.

> the RO can interact with the requests from the clients.
Is the RO the User? In consumer use cases it usually is, and the RO is
using the client. I'm not sure what you scenario you are describing

> [Denis]  However, in these two drafts, the privacy considerations sections
> are silent on this point.
>
There are lots of missing details in both drafts! Security considerations,
error messages etc.

I think pretty much everyone is onboard supporting privacy, but not all use
cases have the same privacy considerations.

/Dick

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 6 Jul 2020 12:45:03 +0000

Hi!

The milestones below the charter text now reflect the proposed simplification described below (by Dick).

Regards,
Roman

From: iesg <[email-masked]> On Behalf Of Tom Jones
Sent: Friday, June 26, 2020 6:10 PM
To: Justin Richer <[email-masked]>
Cc: Dick Hardt <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

Right - I have already proposed binding to application level keys in other venues and strongly oppose continued use of channel binding.
Peace ..tom

On Fri, Jun 26, 2020 at 2:03 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I agree with this proposed change in wording for the milestones. We don’t want to artificially limit the key binding presentation mechanisms. While I think the three listed are likely to be among the first ones we see (based on prior art and current community interest), I don’t think we can predict entirely what will be developed by the group and when.

 — Justin

On Jun 26, 2020, at 1:21 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

I am concerned with the following milestones:

  Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to
  WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol,
  detached HTTP signatures, to WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol,
  embedded HTTP signature, to WGLC

I think it is overly prescriptive to specify which key presentation mechanisms will be created, and it implies that other key presentation mechanisms will not be worked on. While it is possible that channel binding mechanisms such as TLS, detached HTTP signatures, and embedded HTTP signatures will be appropriate key presentation mechanisms for GNAP, it is also quite possible that the WG will determine one or more are not appropriate, or the underlying mechanism may not gain acceptance, or channel binding is not always needed. For example, the effort to bind OAuth access tokens using RFC8471 was disbanded.

Additionally, there are two primary communication channels in the protocol that have different security requirements. The client to authorization server, and the client to resource server. The term "core protocol" is vague and could be construed that the same mechanism MUST be used in both channels.

I propose the following new wording:

Oct 2021 - Key presentation mechanism binding for each communication channel to WGLC.

---------- Forwarded message ---------
From: The IESG <[email-masked]<mailto:[email-masked]>>
Date: Fri, Jun 26, 2020 at 9:10 AM
Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap)
To: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>

A new IETF WG has been proposed in the Security Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list ([email-masked]<mailto:[email-masked]>) by 2020-07-06.

Grant Negotiation and Authorization Protocol (gnap)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
  Leif Johansson <[email-masked]<mailto:[email-masked]>>

Assigned Area Director:
  Roman Danyliw <[email-masked]<mailto:[email-masked]>>

Security Area Directors:
  Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
  Roman Danyliw <[email-masked]<mailto:[email-masked]>>

Mailing list:
  Address: [email-masked]<mailto:[email-masked]>
  To subscribe: https://www.ietf.org/mailman/listinfo/txauth
  Archive: https://mailarchive.ietf.org/arch/browse/txauth/

Group page: https://datatracker.ietf.org/group/gnap/

Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/

This group is chartered to develop a fine-grained delegation protocol for
authorization and API access, as well as requesting and providing user
identifiers and claims. This protocol will allow an authorizing party to
delegate access to client software through an authorization server. It will
expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect
(itself an extension of OAuth 2.0) to support authorizations scoped as
narrowly as a single transaction, provide a clear framework for interaction
among all parties involved in the protocol flow, and remove unnecessary
dependence on a browser or user-agent for coordinating interactions..

The delegation process will be acted upon by multiple parties in the protocol,
each performing a specific role. The protocol will decouple the interaction
channels, such as the end user’s browser, from the delegation channel, which
happens directly between the client and the authorization server (in contrast
with OAuth 2.0, which is initiated by the client redirecting the user’s
browser). The protocol will include a means of specifying how the user can
potentially be involved in an interactive fashion during the delegation
process. The client and Authorization Server (AS) will use these interaction
mechanisms to involve the user, as necessary, to make authorization decisions.
This decoupling avoids many of the security concerns and technical challenges
of OAuth 2.0 and provides a non-invasive path for supporting future types of
clients and interaction channels.

The group will define interoperability for this protocol between different
parties, including
 - client and authorization server;
 - client and resource server; and
 - authorization server and resource server.

The group will seek to minimize assumptions about the form of client
applications, allowing for:
- Fine-grained specification of access
- Approval of AS attestation to identifiers and other identity claims
- Approval of access to multiple resources and APIs in a single interaction
- Support for multiple access tokens in a single request and response
- Support for directed, audience-restricted access tokens
- Separation between the party authorizing access and the party operating the
client requesting access

The group will define extension points for this protocol to allow for
flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possession
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other
information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information (including identifiers and
identity assertions) through the delegation process

Additionally, the group will provide mechanisms for management of the protocol
lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Mechanisms for the AS and RS to communicate the access granted by an access
token

Although the artifacts for this work are not intended or expected to be
backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol
where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such
will focus on new technological solutions not necessarily compatible with
OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed
to the OAuth Working Group, including functionality back-ported from the
protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic
methods, such as JOSE and COSE, to the delegation process. This group is not
chartered to develop new cryptographic methods.

The group is chartered to develop mechanisms for conveying identity
information within the protocol including existing identifiers (such as email
addresses, phone numbers, usernames, and subject identifiers) and assertions
(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
Credentials). The group is not chartered to develop new formats for
identifiers or assertions, nor is the group chartered to develop schemas for
user information, profiles, or other identity attributes, unless a viable
existing format is not available.

The initial work will focus on using HTTPS for communication between the
client and the authorization server, taking advantage of optimization
features of HTTP/2 and HTTP/3 where possible, and will strive to enable
simple mapping to other protocols such as COAP when doing so does not
conflict with the primary focus.

Milestones to include:
- Core delegation protocol
- Key presentation mechanism bindings to the core protocol including TLS,
detached HTTP signature, and embedded HTTP signatures
- Conveyance mechanisms for identifiers and assertions
- Guidelines for use of protocol extension points
- (if needed) Guidelines on migration paths, implementation, and operations

Where possible, the group will seek to make use of tools to guide and inform
the standardization process including formal analysis, architecture documents,
and use case documents. These artifacts will not be considered as working
group milestones or deliverables.

The working group will cooperate and coordinate with other IETF WGs such as
OAUTH, and work with external organizations, such as the OpenID Foundation,
as appropriate.

Milestones:

  Jul 2021 - Core delegation protocol in WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to
  WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol,
  detached HTTP signatures, to WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol,
  embedded HTTP signature, to WGLC

  Dec 2021 - Guidelines for use of protocol extension points to WGLC

  Feb 2022 - Guidelines on migration paths, implementation, and operations to
   WGLC

_______________________________________________
IETF-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-announce
[Image removed by sender.]ᐧ
--
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: Roman Danyliw <[email-masked]>
Date: Mon, 6 Jul 2020 14:35:45 +0000

Hello!

I’m top-posting here because there is no easy way for me to cleaning insert my process comment.  I think we are having a necessary conversation below and in no way should it stop because of this note.

As a process check, this thread started with a request for community review on the charter text [1].  Among other things, this charter review is trying to ensure the problem is clear, defines the bounds of the desired solutions and identifies critical objections from the consensus-derived text.  The text is not intended to define detailed requirements/architecture, resolve tradeoffs, or to specify a solution, unless they are critical to bounding the solution.  These details should be left to future discussions of a chartered WG (not that they can’t start now in parallel).  Additionally, as a reminder, while there are multiple individual drafts with proposed solutions in the datatracker, the design decisions they make are not part of the charter and their adoption is not assumed by the charter.  If there are key design elements in those or any other documents that is felt to be crucial to scoping the WG,  we need to capture the thinking, generalize it (as appropriate), and add it to the charter text explicitly or by reference.

Let’s continue to talk about the technical details of the use cases, design properties, constraints and candidate solutions.  Additionally, given the -05 charter text and milestones [2], it would be helpful to understand what outstanding concerns remain with the charter text in preparation for the Thursday, July 9th telechat where the IESG will use community feedback to help decide the way ahead for this proposed WG.

Roman

[1] https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/
[2] https://datatracker.ietf.org/doc/charter-ietf-gnap/

From: Txauth <[email-masked]> On Behalf Of Dick Hardt
Sent: Friday, July 3, 2020 9:41 PM
To: Denis <[email-masked]>
Cc: Nat Sakimura <[email-masked]>; [email-masked]
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

+ Nat as he is mentioned
- IESG

On Fri, Jul 3, 2020 at 2:16 AM Denis <[email-masked]<mailto:[email-masked]>> wrote:
Hello Dick,

On Mon, Jun 29, 2020 at 12:06 AM Denis <[email-masked]<mailto:[email-masked]>> wrote:
Hello Dick,

Denis, thanks for sharing your thoughts, some clarifications on your statements inserted:

On Fri, Jun 26, 2020 at 9:42 AM Denis <[email-masked]<mailto:[email-masked]>> wrote:
<snip>

New proposed charter
<snip>

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be obtained.
While at times this may be appropriate, at other times disclosing the attributes the RS requires is not needed by the client.
For example, an enterprise client accessing a resource does not need to know which groups a user belongs to,
but the RS may require that to determine if the user running the client has access.

As soon as there is a desire to implement privacy by default, the client should not provide more attributes than strictly necessary.
Even after three readings of your example, I failed to understand it.

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the client.
This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF presentation on what became OAuth 2.0

Unfortunately slide 7 has just one arrow with the word "trust". This is insufficient to understand what is meant unless being present
at the presentation. Does it mean that the PR (RS) trusts one AS or that it may trust multiple ASs ?

Unfortunately slide 8 has just one arrow between the PR and the AS which is red-crossed but no text at all. This is insufficient to understand
what is meant unless being present at the presentation. Does it mean that the PR and the AS never communicate directly ?
Does it mean that they have no relationships at all, besides the one way trust relationship mentioned in slide 7 ?

So it hard to say whether these two slides are indeed meaning that there is no bilateral relationship between an authorization server and a resource server.
Apologies for not providing an explanation on the slides.

Slide 7 shows that trust between the AS and PR (now RS) was unidirectional, from the RS to the AS.
Slide 8 indicates that trust is not bidirectional.

Slide 8 says it does not go both ways. Slide 7 says it goes one way. I don't see the contradiction.

I would have preferred that you meant: the RS and the AS never communicate directly, which is indeed a nice property to follow
to ensure the user's privacy.
That is one model. Other models are appropriate in other circumstances..

[Denis] This is fine.
 On June 12, Nat Sakimura recently answered to an email with the following topic:
Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))
My arguments were:
     The original model for OAuth was making the assumption that the AS and the RS had a strong bilateral relationship.

      A key question is whether such strong relationship will be maintained for ever or
     whether it will be allowed to perform some evolutions of this relationship.

     In order to respect the privacy of the users, there is the need to encompass other scenarios. One of these scenarios is that the AS and the RS
     do not need any longer to have such a strong relationship. In terms of trust relationships, a RS simply needs to trust the access tokens issued by an AS.
     The AS does have any more a "need to know" of all the RSs that are accepting its access tokens. This would be a major simplification of the current global architecture.
Nat's position was:
"My take is that the basic assumption of OAuth 2.0 Framework is that there is a strong relationship between AS and RS.
I feel that it is quite unrealistic that an RS would trust the access token issued by an AS that it has no strong relationship with".
There are indeed different positions on this topic.

I don't think Nat and I have different opinions, but I will let Nat clarify.
Just because there is a strong relationship between the AS and RS, does not mean it is bidirectional. I would understand

"I feel that it is quite unrealistic that an RS would trust the access token issued by an AS that it has no strong relationship with"

[Denis]  Speaking of a "strong relationship" is ambiguous. The key point being whether the relationship is unilateral or bilateral.
There is no need to use the wording "strong relationship" when the relationship is only unilateral: a RS simply trusts an AS for the access tokens it issues.
In such a case, this does not mean that an AS is knowing all the RSs that are trusting it.

On the contrary, a strong (bi-)relationship is when a RS and an AS both agree between them about the meaning of scope parameters.
This is a typical case for OAuth 2.0.
You can ask Nat what he meant by "strong relationship"

The AS is stating what a scope means to it and the user.. The RS can do whatever it wants. I don't see that as requiring a bidirectional relationship.

<snip>

I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.

The above is not true.

The Resource Owner is delegating access control to the AS in authorization use cases.

The OAuth 2.0 model does not mandate any more the presence of a Resource Owner.

Why do you say that? The RO is who owns the RS. Your statement does not make sense.

[Denis]  I mean that there is not necessarily a protocol defined so that the RO can interact with the requests from the clients.
Is the RO the User? In consumer use cases it usually is, and the RO is using the client. I'm not sure what you scenario you are describing

The client is may be delegating user authentication to the AS in identity claim use cases.

Delegating user authentication to the AS is different from delegating access control to the AS.

Agreed. Your statement was there was no delegation. I'm explaining there are potentially two delegations.

The AS can act as the client in many OAuth deployments, as the access token is a bearer token.

A bearer token is rather insecure.
Cookies are also bearer tokens. But we use them all the time in web apps for storing session state and prior authentication! :)

There are currently two attempts in the OAuth WG to let know to the AS what the client is doing:

  *   draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request)
  *   draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization Requests)
Those are optional, and in some situations are a desired property.

[Denis]  However, in these two drafts, the privacy considerations sections are silent on this point.
There are lots of missing details in both drafts! Security considerations, error messages etc.

I think pretty much everyone is onboard supporting privacy, but not all use cases have the same privacy considerations.

/Dick

---

From: Denis <[email-masked]>
Date: Mon, 6 Jul 2020 16:55:02 +0200

Since it is today the last day to send back comments, you will find 
hereafter my comments on the last charter version-05.

    charter-ietf-gnap-00-05

This group is chartered to develop a fine-grained delegation protocol 
for authorization, API access, user identifiers, and identity 
assertions. [Denis] Fine. The protocol will also allow the client to 
present unverified identifiers and verifiable assertions to the AS as 
part of its request. [Denis] This sentence is too vague because "as part 
of its request" is not explicit enough. If it means"as part as an access 
token request" this should be explicitly said. If, it is not the case, 
then it should be clearly explained. The AS should know as little as 
possible (including nothing) about what the client is doing. This 
protocol will allow an authorizing party to delegate access to client 
software through an authorization server. [Denis] The word "*privacy*" 
is still missing in the charter. "Delegating access to client software 
through an authorization server" is negating the fact that the user's 
privacy will ever be considered. IMHO, I believe that a RS may delegate 
some operation to another RS, but I don't believe that an AS should be 
concerned by any form of delegation, otherwise it would have the ability 
to act as "Big Brother". OAuth has not been constructed taking into 
consideration the user's privacy. The major difference with it should be 
that GNAP has been constructed along "*privacy by design*" principles. 
It will *expand* upon the uses cases currently supported by OAuth 2.0 
and OpenID Connect (itself an extension of OAuth 2.0) to support 
authorizations scoped as narrowly as a single transaction, provide a 
clear framework for interaction among all parties involved in the 
protocol flow, and remove unnecessary dependence on a browser or 
user-agent for coordinating interactions. [Denis] There is no need to 
refer to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. 
"*non-expanded"* use cases) should be supported differently from OAuth 
2.0 and OpenID Connect, in particular to support the user's privacy. The 
delegation process will be acted upon by multiple parties in the 
protocol, each performing a specific role. The protocol will decouple 
the channels used by the protocol participants to communicate from the 
delegation channel, which happens directly between the client and the 
authorization server (in contrast with OAuth 2.0, which is initiated by 
the client redirecting the user’s browser). [Denis] Here again, the 
delegation process, if any, should be handled by RSs and not by ASs. The 
term "delegation channel" is being used but it is left undefined. It is 
not understandable. The protocol will include a means of specifying how 
the user can potentially be involved in an interactive fashion during 
the delegation process. The client and Authorization Server (AS) will 
use these interaction mechanisms to involve the user, as necessary, to 
make authorization decisions. [Denis] Here again, the delegation 
process, if any, should be handled by RSs and not by ASs. The AS should 
know as little as possible (including nothing) about what the client is 
doing. This decoupling avoids many of the security concerns and 
technical challenges of OAuth 2.0 and provides a non-invasive path for 
supporting future types of clients and interaction channels. [Denis] 
This is not understandable to me. Is such a sentence really needed in a 
charter ? The group will define interoperability for this protocol 
between different parties, including

-client and authorization server;

-client and resource server; and

- authorization server and resource server. [Denis] In order to support 
the user's privacy, there should be no interaction at all between an 
authorization server and a resource server /at the time of a client 
request/. The group will seek to minimize assumptions about the form of 
client applications, allowing for:

-Fine-grained specification of access

-Approval of AS attestation to identifiers and other identity claims

-Approval of access to multiple resources and APIs in a single interaction

-Multiple access tokens in a single request and response

-AS-directed dispatch of access tokens to the appropriate RS

[Denis] As-directed dispatch does not allow to support the user's 
privacy. However, RS-directed dispatch allows to support the user's 
privacy. It should be explicitly mentioned.

-Separation between the party authorizing access and the party operating 
the client requesting access [Denis] It is questionable whether such a 
separation would be really beneficial. In doubt, this item should be 
removed. The group will define extension points for this protocol to 
allow for flexibility in areas including: Cryptographic agility for 
keys, message signatures, and proof of possession

-User interaction mechanisms including web and non-web methods

-Mechanisms for conveying user, software, organization, and other 
information used in authorization decisions

-Mechanisms for presenting tokens to resource servers and binding 
resource requests to tokens and associated cryptographic keys

Optimized inclusion of additional information (including identifiers and 
identity assertions) through the delegation process Additionally, the 
group will provide mechanisms for management of the protocol lifecycle 
including:

-Discovery of the authorization server

-Revocation of active tokens

Data model for granted access and mechanisms for the AS and RS to 
communicate the granted access model [Denis] While it is the duty for 
the RS to communicate the granted access model to the client /at the 
appropriate instant of time/, the AS should be kept fully ignorant of 
it. Although the artifacts for this work are not intended or expected to 
be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will 
attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the 
new protocol where possible. This group is not chartered to develop 
extensions to OAuth 2.0, and as such will focus on new technological 
solutions not necessarily compatible with OAuth 2.0. Functionality that 
builds directly on OAuth 2.0 will be directed to the OAuth Working 
Group, including functionality back-ported from the protocol developed 
here to OAuth 2.0. The group is chartered to develop mechanisms for 
applying cryptographic methods, such as JOSE and COSE, to the delegation 
process. This group is not chartered to develop new cryptographic 
methods. The group is chartered to develop mechanisms for conveying 
identity information within the protocol including existing identifiers 
(such as email addresses, phone numbers, usernames, and subject 
identifiers) and assertions (such as OpenID Connect ID Tokens, SAML 
Assertions, and Verifiable Credentials). The group is not chartered to 
develop new formats for identifiers or assertions, nor is the group 
chartered to develop schemas for user information, profiles, or other 
identity attributes, unless a viable existing format is not available. 
The initial work will focus on using HTTPS for communication between the 
client and the authorization server, taking advantage of optimization 
features of HTTP/2 and HTTP/3 where possible, and will strive to enable 
simple mapping to other protocols such as COAP when doing so does not 
conflict with the primary focus. Milestones to include:

-Core delegation protocol

[Denis] Before defining a "Core delegation protocol", a simple client 
server-protocol involving the presentation of several access tokens to 
one RS should be defined. Privacy principles should be applied when 
defining the protocol. Then after, a delegation mechanism allowing one 
RS to forward an operation to another RS should be defined.

-Key presentation mechanism bindings to the core protocol including TLS, 
detached HTTP signature, and embedded HTTP signatures

[Denis] Bindings to TLS are now deprecated, why should they be 
maintained ? Signatures may be needed but they do not necessarily need 
to be "detached HTTP signature, and embedded HTTP signatures". This item 
should be either removed or reworded.

-Conveyance mechanisms for identifiers and assertions

-Guidelines for use of protocol extension points (if needed)

      -    Guidelines on migration paths, implementation, and operations

[Denis] The above three lines are rather mysterious.

Where possible, the group will seek to make use of tools to guide and 
inform the standardization process including formal analysis,
architecture documents, and use case documents. These artifacts will not 
be considered as working group milestones or deliverables.

The working group will cooperate and coordinate with other IETF WGs such 
as OAUTH, and work with external organizations,
such as the OpenID Foundation, as appropriate.

[Denis] The charter should be shorter.

/Denis

> IESG mailing list ([email-masked])*by 2020-07-06*.
>
>    Yaron Sheffer <[email-masked]>
>    Leif Johansson <[email-masked]>
>
> Assigned Area Director:
>    Roman Danyliw <[email-masked]>
>
> Security Area Directors:
>    Benjamin Kaduk <[email-masked]>
>    Roman Danyliw <[email-masked]>
>
> Mailing list:
>    Address: [email-masked]
>    To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth
> dependence on a browser or user-agent for coordinating interactions.
>

---

From: Denis <[email-masked]>
Date: Mon, 6 Jul 2020 17:49:12 +0200

One single comment.

Dick wrote on the last line:

    I think pretty much everyone is onboard supporting privacy, but not
    all use cases have the same privacy considerations.

I hope that this is true, but in such a case I can't understand why the 
word "*privacy*" is missing in the charter.

Denis

Note: IESG added

> Hello!
>
> I’m top-posting here because there is no easy way for me to cleaning 
> insert my process comment.  I think we are having a necessary 
> conversation below and in no way should it stop because of this note.
>
> As a process check, this thread started with a request for community 
> review on the charter text [1]. Among other things, this charter 
> review is trying to ensure the problem is clear, defines the bounds of 
> the desired solutions and identifies critical objections from the 
> consensus-derived text.  The text is not intended to define detailed 
> requirements/architecture, resolve tradeoffs, or to specify a 
> solution, unless they are critical to bounding the solution.  These 
> details should be left to future discussions of a chartered WG (not 
> that they can’t start now in parallel).  Additionally, as a reminder, 
> while there are multiple individual drafts with proposed solutions in 
> the datatracker, the design decisions they make are not part of the 
> charter and their adoption is not assumed by the charter. If there are 
> key design elements in those or any other documents that is felt to be 
> crucial to scoping the WG,  we need to capture the thinking, 
> generalize it (as appropriate), and add it to the charter text 
> explicitly or by reference.
>
> Let’s continue to talk about the technical details of the use cases, 
> design properties, constraints and candidate solutions.  Additionally, 
> given the -05 charter text and milestones [2], it would be helpful to 
> understand what outstanding concerns remain with the charter text in 
> preparation for the Thursday, July 9^th telechat where the IESG will 
> use community feedback to help decide the way ahead for this proposed WG.
>
> Roman
>
> [1] 
> https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/
>
> <https://datatracker.ietf.org/doc/charter-ietf-gnap/>
>
> *From:* Txauth <[email-masked]> *On Behalf Of *Dick Hardt
> *Sent:* Friday, July 3, 2020 9:41 PM
> *To:* Denis <[email-masked]>
> *Cc:* Nat Sakimura <[email-masked]>; [email-masked]
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization 
> Protocol (gnap)
>
> + Nat as he is mentioned
>
> - IESG
>
>                 Denis, thanks for sharing your thoughts, some
>                 clarifications on your statements inserted:
>
>                 On Fri, Jun 26, 2020 at 9:42 AM Denis
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 <snip>
>
>                         *New proposed charter*
>
>                 <snip>
>
>
>                         Resource servers inform their clients about
>                         which access token formats are acceptable and
>                         depending upon the king of operation
>                         that is requested, which kind of attributes
>                         are needed and from which ASs that my be obtained.
>
>                 While at times this may be appropriate, at other times
>                 disclosing the attributes the RS requires is not
>                 needed by the client.
>                 For example, an enterprise client accessing a resource
>                 does not need to know which groups a user belongs to,
>             As soon as there is a desire to implement privacy by
>             default, the client should not provide more attributes
>             than strictly necessary.
>                         A major difference with OAuth 2.0 is that
>                         there is no bilateral trust relationship
>                         between an authorization server and a resource
>                         server:
>                         for a given category of attributes, a resource
>                         server may trust one or more authorization
>                         servers. Another major difference with OAuth 2.0.
>                 This is not how OAuth 2.0 works. See slides 7 and 8
>                 from my original IETF presentation on what became
>                 OAuth 2.0
>
>             Unfortunately slide 7 has just one arrow with the word
>             "trust". This is insufficient to understand what is meant
>             unless being present
>             at the presentation. Does it mean that the PR (RS) trusts
>             one AS or that it may trust multiple ASs ?
>
>             Unfortunately slide 8 has just one arrow between the PR
>             and the AS which is red-crossed but no text at all. This
>             is insufficient to understand
>             what is meant unless being present at the presentation.
>             Does it mean that the PR and the AS never communicate
>             directly ?
>             Does it mean that they have no relationships at all,
>             besides the one way trust relationship mentioned in slide 7 ?
>
>             So it hard to say whether these two slides are indeed
>             meaning that there is no bilateral relationship between an
>             authorization server and a resource server.
>
>                 Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22
>                 (The OAuth 2.0 Authorization Framework: JWT Secured
>                 Authorization Request))
>
>             My arguments were:
>
>                  The original model for OAuth was making the
>             assumption that the AS and the RS had a strong bilateral
>             relationship.
>
>             *A key question is whether such strong relationship will
>             be maintained for ever *or
>             need to encompass other scenarios. One of these scenarios
>             is that the AS and the RS
>             do not need any longer to have such a strong relationship.
>             In terms of trust relationships, a RS simply needs to
>             trust the access tokens issued by an AS.
>             that are accepting its access tokens. This would be a
>             major simplification of the current global architecture.
>
>             Nat's position was:
>
>                 "My take is that the basic assumption of OAuth 2.0
>                 Framework is that there is a strong relationship
>                 between AS and RS.
>                 I feel that it is quite unrealistic that an RS would
>                 trust the access token issued by an AS that it has no
>                 strong relationship with".
>
>         Just because there is a strong relationship between the AS and
>         RS, does not mean it is bidirectional. I would understand
>
>         "I feel that it is quite unrealistic that an RS would trust
>         the access token issued by an AS that it has no strong
>         relationship with"
>
>     [Denis] Speaking of a "strong relationship" is ambiguous. The key
>     point being whether the relationship is unilateral or bilateral.
>     relationship is only unilateral: a RS simply trusts an AS for the
>     access tokens it issues.
>     On the contrary, a strong (bi-)relationship is when a RS and an AS
>     both agree between them about the meaning of scope parameters.
> The AS is stating what a scope means to it and the user.. The RS can 
> do whatever it wants. I don't see that as requiring a bidirectional 
> relationship.
>
>                     I got rid of the word "delegation": the client
>                     does not delegate anything to an authorization
>                     server. If it would, this would mean that the
>                     authorization server
>                     would be able to act as the client and could know
>                     everything that the client will do, which comes
>                     into contradiction with the user's privacy.
>
>                 The above is not true.
>
>     [Denis] I mean that there is not necessarily a protocol defined so
>     that the RO can interact with the requests from the clients.
>
>         Agreed. Your statement was there was no delegation. I'm
>         explaining there are potentially two delegations.
>
>                 The AS can act as the client in many OAuth
>                 deployments, as the access token is a bearer token.
>
>         Cookies are also bearer tokens. But we use them all the time
>         in web apps for storing session state and prior authentication! :)
>
>               * draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
>                 Authorization Framework: JWT Secured Authorization
>                 Request)
> I think pretty much everyone is onboard supporting privacy, but not 
> all use cases have the same privacy considerations.
>
> /Dick
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jul 2020 09:25:28 -0700

Hi Denis

Just like "privacy", "security" is not called out as a goal. (it is
mentioned as an issue with OAuth 2.0).

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

> I think pretty much everyone is onboard supporting privacy, but not all
> use cases have the same privacy considerations.
>
> insert my process comment.  I think we are having a necessary conversation
> below and in no way should it stop because of this note.
>
>
>
> review on the charter text [1].  Among other things, this charter review is
> trying to ensure the problem is clear, defines the bounds of the desired
> solutions and identifies critical objections from the consensus-derived
> text.  The text is not intended to define detailed
> requirements/architecture, resolve tradeoffs, or to specify a solution,
> unless they are critical to bounding the solution.  These details should be
> left to future discussions of a chartered WG (not that they can’t start now
> in parallel).  Additionally, as a reminder, while there are multiple
> individual drafts with proposed solutions in the datatracker, the design
> decisions they make are not part of the charter and their adoption is not
> assumed by the charter.  If there are key design elements in those or any
> other documents that is felt to be crucial to scoping the WG,  we need to
> capture the thinking, generalize it (as appropriate), and add it to the
> charter text explicitly or by reference.
>
>
>
> preparation for the Thursday, July 9th telechat where the IESG will use
> community feedback to help decide the way ahead for this proposed WG.
>
>
>
> Roman
>
>
>
> [1]
> *From:* Txauth <[email-masked]> <[email-masked]> *On
> Behalf Of *Dick Hardt
> *To:* Denis <[email-masked]> <[email-masked]>
> *Cc:* Nat Sakimura <[email-masked]> <[email-masked]>;
> [email-masked]
> Resource servers inform their clients about which access token formats are
> acceptable and depending upon the king of operation
> The AS is stating what a scope means to it and the user.. The RS can do
> I think pretty much everyone is onboard supporting privacy, but not all
> use cases have the same privacy considerations.
>
>
>
> /Dick
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jul 2020 09:25:40 -0700

Thanks Roman!

On Mon, Jul 6, 2020 at 5:45 AM Roman Danyliw <[email-masked]> wrote:

> Hi!
>
>
>
> The milestones below the charter text now reflect the proposed
> simplification described below (by Dick).
>
>
>
> Regards,
>
> Roman
>
>
>
> *From:* iesg <[email-masked]> *On Behalf Of * Tom Jones
> *Sent:* Friday, June 26, 2020 6:10 PM
> *To:* Justin Richer <[email-masked]>
> *Cc:* Dick Hardt <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]
> Right - I have already proposed binding to application level keys in other
> venues and strongly oppose continued use of channel binding.
>
> Peace ..tom
>
>
>
>
>
> On Fri, Jun 26, 2020 at 2:03 PM Justin Richer <[email-masked]> wrote:
>
> I agree with this proposed change in wording for the milestones. We don’t
> want to artificially limit the key binding presentation mechanisms. While I
> think the three listed are likely to be among the first ones we see (based
> on prior art and current community interest), I don’t think we can predict
> entirely what will be developed by the group and when.
>
>
>
>  — Justin
>
>
>
> On Jun 26, 2020, at 1:21 PM, Dick Hardt <[email-masked]> wrote:
>
>
>
>
>
> I think it is overly prescriptive to specify which key presentation
> mechanisms will be created, and it implies that other key presentation
> mechanisms will not be worked on. While it is possible that channel binding
> mechanisms such as TLS, detached HTTP signatures, and embedded HTTP
> signatures will be appropriate key presentation mechanisms for GNAP, it is
> also quite possible that the WG will determine one or more are not
> appropriate, or the underlying mechanism may not gain acceptance, or
> channel binding is not always needed. For example, the effort to bind OAuth
> access tokens using RFC8471 was disbanded.
>
>
>
> Additionally, there are two primary communication channels in the protocol
> that have different security requirements. The client to authorization
> server, and the client to resource server. The term "core protocol" is
> vague and could be construed that the same mechanism MUST be used in both
> channels.
>
>
>
> From: *The IESG* <[email-masked]>
> To: IETF-Announce <[email-masked]>
> Cc: <[email-masked]>
>
>
>
> IESG mailing list ([email-masked]) by 2020-07-06.
>
> inform
> [email-masked]
> ᐧ
> [email-masked]
> [email-masked]

---

From: Denis <[email-masked]>
Date: Mon, 6 Jul 2020 18:38:14 +0200

Hi Dick,
> mentioned as an issue with OAuth 2.0).

The word "security" appears once in the charter, but the word "privacy" 
does not appear.

What goes wellwithout saying, goes even better whenyou sayit.

Many features announced in the charter *prevent *to apply privacy 
principles.
So it is easy to get the impression that the charter is considering that 
privacy is a non-goal.

"Privacy by design" should be mentioned as well as "privacy by default".
These two magic sentences are of utmost importance.

Denis

>
> On Mon, Jul 6, 2020 at 8:49 AM Denis <[email-masked] 
>         I think pretty much everyone is onboard supporting privacy,
>         but not all use cases have the same privacy considerations.
>
>     I hope that this is true, but in such a case I can't understand
>     why the word "*privacy*" is missing in the charter.
>
>     Denis
>
>     Note: IESG added
>
>>     Hello!
>>
>>     I’m top-posting here because there is no easy way for me to
>>     cleaning insert my process comment.  I think we are having a
>>     necessary conversation below and in no way should it stop because
>>     of this note.
>>
>>     As a process check, this thread started with a request for
>>     community review on the charter text [1].  Among other things,
>>     this charter review is trying to ensure the problem is clear,
>>     defines the bounds of the desired solutions and identifies
>>     critical objections from the consensus-derived text.  The text is
>>     not intended to define detailed requirements/architecture,
>>     resolve tradeoffs, or to specify a solution, unless they are
>>     critical to bounding the solution.  These details should be left
>>     to future discussions of a chartered WG (not that they can’t
>>     start now in parallel). Additionally, as a reminder, while there
>>     are multiple individual drafts with proposed solutions in the
>>     datatracker, the design decisions they make are not part of the
>>     charter and their adoption is not assumed by the charter.  If
>>     there are key design elements in those or any other documents
>>     that is felt to be crucial to scoping the WG,  we need to capture
>>     the thinking, generalize it (as appropriate), and add it to the
>>     Let’s continue to talk about the technical details of the use
>>     cases, design properties, constraints and candidate solutions. 
>>     Additionally, given the -05 charter text and milestones [2], it
>>     would be helpful to understand what outstanding concerns remain
>>     with the charter text in preparation for the Thursday, July 9^th
>>     telechat where the IESG will use community feedback to help
>>     decide the way ahead for this proposed WG.
>>
>>     Roman
>>
>>     [1]
>>     *From:* Txauth <[email-masked]>
>>     <mailto:[email-masked]> *On Behalf Of *Dick Hardt
>>     *To:* Denis <[email-masked]> <mailto:[email-masked]>
>>     *Cc:* Nat Sakimura <[email-masked]>
>>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>>     *Subject:* Re: [Txauth] WG Review: Grant Negotiation and
>>     Authorization Protocol (gnap)
>>
>>     + Nat as he is mentioned
>>
>>     - IESG
>>
>>             On Mon, Jun 29, 2020 at 12:06 AM Denis
>>                     While at times this may be appropriate, at other
>>                     times disclosing the attributes the RS requires
>>                     is not needed by the client.
>>                     For example, an enterprise client accessing a
>>                     resource does not need to know which groups a
>>                     user belongs to,
>>                 default, the client should not provide more
>>                 attributes than strictly necessary.
>>                             between an authorization server and a
>>                             resource server:
>>                             for a given category of attributes, a
>>                             resource server may trust one or more
>>                             authorization servers. Another major
>>                             is that the content of an attributes
>>                             token is meant to be accessible to the
>>                             client.
>>
>>                     This is not how OAuth 2.0 works. See slides 7 and
>>                     8 from my original IETF presentation on what
>>                     became OAuth 2.0
>>
>>                 Unfortunately slide 7 has just one arrow with the
>>                 word "trust". This is insufficient to understand what
>>                 is meant unless being present
>>                 at the presentation. Does it mean that the PR (RS)
>>                 trusts one AS or that it may trust multiple ASs ?
>>
>>                 Unfortunately slide 8 has just one arrow between the
>>                 PR and the AS which is red-crossed but no text at
>>                 all. This is insufficient to understand
>>                 what is meant unless being present at the
>>                 presentation. Does it mean that the PR and the AS
>>                 never communicate directly ?
>>                 meaning that there is no bilateral relationship
>>                 between an authorization server and a resource server.
>>
>>             Slide 7 shows that trust between the AS and PR (now RS)
>>             was unidirectional, from the RS to the AS.
>>
>>         I would have preferred that you meant: the RS and the AS
>>         never communicate directly, which is indeed a nice property
>>         to follow
>>                     Re: [OAUTH-WG] Comments on
>>                     draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
>>                 assumption that the AS and the RS had a strong
>>                 bilateral relationship.
>>
>>                 *A key question is whether such strong relationship
>>                 will be maintained for ever *or
>>                 In order to respect the privacy of the users, there
>>                 is the need to encompass other scenarios. One of
>>                 these scenarios is that the AS and the RS
>>                 do not need any longer to have such a strong
>>                 relationship. In terms of trust relationships, a RS
>>                 simply needs to trust the access tokens issued by an AS.
>>                 The AS does have any more a "need to know" of all the
>>                 RSs that are accepting its access tokens. This would
>>                 be a major simplification of the current global
>>                 architecture.
>>
>>                 Nat's position was:
>>
>>                     "My take is that the basic assumption of OAuth
>>                     2.0 Framework is that there is a strong
>>                     relationship between AS and RS.
>>                     I feel that it is quite unrealistic that an RS
>>                     would trust the access token issued by an AS that
>>                     it has no strong relationship with".
>>
>>             Just because there is a strong relationship between the
>>             AS and RS, does not mean it is bidirectional. I would
>>             understand
>>
>>             "I feel that it is quite unrealistic that an RS would
>>             strong relationship with"
>>
>>         [Denis] Speaking of a "strong relationship" is ambiguous. The
>>         key point being whether the relationship is unilateral or
>>         bilateral.
>>         There is no need to use the wording "strong relationship"
>>         when the relationship is only unilateral: a RS simply trusts
>>         an AS for the access tokens it issues.
>>         On the contrary, a strong (bi-)relationship is when a RS and
>>         an AS both agree between them about the meaning of scope
>>         parameters.
>>     The AS is stating what a scope means to it and the user.. The RS
>>     can do whatever it wants. I don't see that as requiring a
>>     bidirectional relationship.
>>
>>                         I got rid of the word "delegation": the
>>                         client does not delegate anything to an
>>                         authorization server. If it would, this would
>>                         mean that the authorization server
>>                         would be able to act as the client and could
>>                         know everything that the client will do,
>>                         which comes into contradiction with the
>>                         user's privacy.
>>
>>                     The above is not true.
>>
>>         [Denis] I mean that there is not necessarily a protocol
>>         defined so that the RO can interact with the requests from
>>         the clients.
>>
>>     Is the RO the User? In consumer use cases it usually is, and the
>>     RO is using the client. I'm not sure what you scenario you are
>>     describing
>>
>>                     The client is may be delegating user
>>                     authentication to the AS in identity claim use cases.
>>
>>                 Delegating user authentication to the AS is different
>>                 from delegating access control to the AS.
>>
>>             Cookies are also bearer tokens. But we use them all the
>>             time in web apps for storing session state and prior
>>             authentication! :)
>>
>>                 There are currently two attempts in the OAuth WG to
>>                 let know to the AS what the client is doing:
>>
>>                     Authorization Framework: JWT Secured
>>                     Authorization Request)
>>         [Denis] However, in these two drafts, the privacy
>>         considerations sections are silent on this point.
>>
>>     I think pretty much everyone is onboard supporting privacy, but
>>     not all use cases have the same privacy considerations.
>>
>>     /Dick
>>
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jul 2020 09:58:20 -0700

Security is not called out as a goal, but is a goal for ALL
implementations/deployments.

While privacy will be a goal for some implementations/deployments, it will
NOT be a goal for all. I think your suggested additions will constrain the
work.

On Mon, Jul 6, 2020 at 9:38 AM Denis <[email-masked]> wrote:

> What goes well without saying, goes even better when you say it.
>

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 7 Jul 2020 03:08:32 +0000

Hi Denis!

Thanks for the feedback and for repeating your review on the revised text.  More inline …

From: iesg <[email-masked]> On Behalf Of Denis
Sent: Monday, July 6, 2020 10:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

Since it is today the last day to send back comments, you will find hereafter my comments on the last charter version-05.
charter-ietf-gnap-00-05

This group is chartered to develop a fine-grained delegation protocol for authorization, API access, user identifiers, and identity assertions.

[Denis] Fine.

The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request.

[Denis] This sentence is too vague because "as part of its request" is not explicit enough. If it means  "as part as an access token request"

this should be explicitly said. If, it is not the case, then it should be clearly explained. The AS should know as little as possible (including nothing)

about what the client is doing.

[Roman] The “request” here is the “access token request”.  That can be made clearer.

This protocol will allow an authorizing party to delegate access to client software through an authorization server.

[Denis] The word "privacy" is still missing in the charter. "Delegating access to client software through an authorization server"

is negating the fact that the user's privacy will ever be considered. IMHO, I believe that a RS may delegate some operation to another RS,

but I don't believe that an AS should be concerned by any form of delegation, otherwise it would have the ability to act as "Big Brother".

OAuth has not been constructed taking into consideration the user's privacy. The major difference with it should be that GNAP has been

constructed along "privacy by design" principles.

[Roman]  I don’t exactly follow how considerations for privacy are being negated.  Above and beyond use-case specific considerations that would be defined later, RFC6973 is the IETF consensus design guidance that will guide the privacy threats and mitigations of the work.  What design guidance would you recommend that the WG should consider that aren’t captured in RFC6973?

It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations

scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove

unnecessary dependence on a browser or user-agent for coordinating interactions.

[Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. "non-expanded" use cases) should be supported

differently from OAuth 2.0 and OpenID Connect, in particular to support the user's privacy.

[Roman] I’d want to hear others on this rescoping.  Building upon the use cases of OAuth 2.0 and OpenID Connect has been core, consensus-validated tenant for some time now.

The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the channels used

by the protocol participants to communicate from the delegation channel, which happens directly between the client and the authorization server (in contrast

with OAuth 2.0, which is initiated by the client redirecting the user’s browser).

[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs.

The term "delegation channel" is being used but it is left undefined. It is not understandable.

[Roman] This sentence was just added into -05 address Security AD feedback.  In this case, it was made to distinguish between in-band signaling and the new purpose-to-be-built channel.

The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process.

The client and Authorization Server (AS) will use these interaction mechanisms to involve the user, as necessary, to make authorization decisions.

[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs. The AS should know as little as possible (including nothing)

about what the client is doing.

[Roman] Understood – as I understand it, you have concern with the scope of the AS behavior.  I’d be interesting in hearing additional support for this rescoping.

This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types

of clients and interaction channels.

[Denis] This is not understandable to me. Is such a sentence really needed in a charter ?

[Roman] Can someone on the TxAuth mailing list remind us on why this sentence is here?  With a fresh read, I also can’t remember why we need it.

The group will define interoperability for this protocol between different parties, including

[Denis] In order to support the user's privacy, there should be no interaction at all between an authorization server and a resource server

at the time of a client request.

The group will seek to minimize assumptions about the form of client applications, allowing for:

-          Multiple access tokens in a single request and response

-          AS-directed dispatch of access tokens to the appropriate RS

[Denis] As-directed dispatch does not allow to support the user's privacy. However, RS-directed dispatch allows to support the user's privacy.

It should be explicitly mentioned.

[Roman] As above (per the AS vs. RS behavior)

-          Separation between the party authorizing access and the party operating the client requesting access

[Denis] It is questionable whether such a separation would be really beneficial. In doubt, this item should be removed.

[Roman] Could you say more on why this flexibility wouldn’t be worth it?

The group will define extension points for this protocol to allow for flexibility in areas including:

Cryptographic agility for keys, message signatures, and proof of possession

-          Mechanisms for conveying user, software, organization, and other information used in authorization decisions

-          Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys

Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process

Additionally, the group will provide mechanisms for management of the protocol lifecycle including:

Data model for granted access and mechanisms for the AS and RS to communicate the granted access model

[Denis] While it is the duty for the RS to communicate the granted access model to the client at the appropriate instant of time,

the AS should be kept fully ignorant of it.

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect,

the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily

compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed to the OAuth Working Group, including

functionality back-ported from the protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process.

This group is not chartered to develop new cryptographic methods.

The group is chartered to develop mechanisms for conveying identity information within the protocol including existing identifiers

(such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens,

SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group

chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available.

The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage

of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as COAP

when doing so does not conflict with the primary focus.

Milestones to include:

[Denis] Before defining a "Core delegation protocol", a simple client server-protocol involving the presentation of several access tokens to one RS should be defined.

Privacy principles should be applied when defining the protocol. Then after, a delegation mechanism allowing one RS to forward an operation to another RS should be defined.

-          Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures

[Denis] Bindings to TLS are now deprecated, why should they be maintained ?

Signatures may be needed but they do not necessarily need to be "detached HTTP signature, and embedded HTTP signatures".

This item should be either removed or reworded.

[Roman] Noted.  I’d want to hear others on this rescoping.

-          Guidelines for use of protocol extension points (if needed)
     -    Guidelines on migration paths, implementation, and operations
[Denis] The above three lines are rather mysterious.
[Roman] The guidelines on migration paths came from the initial IESG review in order to have a named activity to action the design goal of “… the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible” a bit earlier in the text.
Where possible, the group will seek to make use of tools to guide and inform the standardization process including formal analysis,
architecture documents, and use case documents. These artifacts will not be considered as working group milestones or deliverables.
The working group will cooperate and coordinate with other IETF WGs such as OAUTH, and work with external organizations,
such as the OpenID Foundation, as appropriate.
[Denis] The charter should be shorter.

[Roman] Definitely.  Nevertheless, we have the current text through rough consensus process achieved from two BoFs and multiple mailing list consensus calls.

Regards,
Roman

/Denis

Chairs:

  Yaron Sheffer <[email-masked]><mailto:[email-masked]>

  Leif Johansson <[email-masked]><mailto:[email-masked]>

Assigned Area Director:

  Roman Danyliw <[email-masked]><mailto:[email-masked]>

Security Area Directors:

  Benjamin Kaduk <[email-masked]><mailto:[email-masked]>

  Roman Danyliw <[email-masked]><mailto:[email-masked]>

Mailing list:

parties, including

client requesting access

lifecycle including:

token

where possible.

Milestones to include:

as appropriate.

Milestones:

  WGLC

   WGLC

---

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

I guess I disagree with several of the assertions made by Denis, especially
the one about the AS knowing as little as possible about the requirement of
the client as it will be presented to the RS. That may be his use case, but
in mine the AS is tightly bound to the user and the ONLY means for the user
to get information about why the client wants or deserves access to the
resources. In the healthcare case, the client and the RS understand the
meaning of the data, the AS and the user have a limited understanding of
the data. The AS formulates the grant, which is in terms of the request for
access, which the AS needs to understand the request to present to the user
for approval. The AS creates a grant, which is not in terms of the claims
provided, but in terms of the requirements for access. Clearly the AS and
RS (and client) need a shared taxonomy of the request types. The AS does
not need to understand the presentation of access from the RS to the
client, but the AS does need full understanding of the request in terms the
user can comprehend.
Peace ..tom

On Mon, Jul 6, 2020 at 8:08 PM Roman Danyliw <[email-masked]> wrote:

> *From:* iesg <[email-masked]> *On Behalf Of * Denis
> *Sent:* Monday, July 6, 2020 10:55 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
> [Denis] The word "*privacy*" is still missing in the charter. "Delegating access to client software through an authorization server"
>
> constructed along "*privacy by design*" principles.
>
>
>
> It will *expand* upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations
>
> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. "*non-expanded"* use cases) should be supported
>
> *at the time of a client request*.
>
>
>
> [Denis] While it is the duty for the RS to communicate the granted access model to the client *at the appropriate instant of time*,
>
> [Roman] The guidelines on migration paths came from the initial IESG
> review in order to have a named activity to action the design goal of “…
> the group will attempt to simplify migrating from OAuth 2.0 and OpenID
> Connect to the new protocol where possible” a bit earlier in the text.
>
> [Roman] Definitely.  Nevertheless, we have the current text through rough
> consensus process achieved from two BoFs and multiple mailing list
> consensus calls.
>
>
>
> Regards,
>
> Roman
>
>
>
> /Denis
>
>
>
> IESG mailing list ([email-masked]) *by 2020-07-06*.
>
>
>
>   Yaron Sheffer <[email-masked]> <[email-masked]>
>
>   Leif Johansson <[email-masked]> <[email-masked]>
>
>
>
> Assigned Area Director:
>
>   Roman Danyliw <[email-masked]> <[email-masked]>
>
>
>
> Security Area Directors:
>
>   Benjamin Kaduk <[email-masked]> <[email-masked]>
>
>   Roman Danyliw <[email-masked]> <[email-masked]>
>
>
>
> Mailing list:
>
>   Address: [email-masked]
>

---

From: Denis <[email-masked]>
Date: Tue, 7 Jul 2020 14:43:02 +0200

Hi Roman,
> hereafter my comments on the last charter version-05.
BTW, I sent an email yesterday evening with the subject: *Support of 
FIDO* and data minimization by RSs, where I indicated that the charter 
should
mention FIDO U2F so that it should be possible to logon to a RS using 
either FIDO or by presenting one (or more) access tokens from one (or 
more) AS.

The original email is here : 
https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/

> for authorization, API access, user identifiers, and identity assertions.
> [Denis] Fine.
> The protocol will also allow the client to present unverified 
> identifiers and verifiable assertions to the AS as part of its request.
> [Denis] This sentence is too vague because "as part of its request" is 
> not explicit enough. If it means  "as part as an access token request"
> this should be explicitly said. If, it is not the case, then it should 
> be clearly explained. The AS should know as little as possible 
> (including nothing)

This would be appreciated.

> This protocol will allow an authorizing party to delegate access to 
> client software through an authorization server.
> [Denis] The word "*privacy*" is still missing in the charter. 
> "Delegating access to client software through an authorization server"
> is negating the fact that the user's privacy will ever be considered. 
> IMHO, I believe that a RS may delegate some operation to another RS,
> but I don't believe that an AS should be concerned by any form of 
> delegation, otherwise it would have the ability to act as "Big Brother".
> OAuth has not been constructed taking into consideration the user's 
> privacy. The major difference with it should be that GNAP has been
> [Roman]  I don’t exactly follow how considerations for privacy are 
> being negated.  Above and beyond use-case specific considerations that 
> would be defined later, RFC6973 is the IETF consensus design guidance 
> that will guide the privacy threats and mitigations of the work.  What 
> design guidance would you recommend that the WG should consider that 
> aren’t captured in RFC6973?

I believe my message is quite clear : If the AS is handling the 
delegation process, it will know what the client is doing or where it is 
going.
On the contrary, if the RS is handling the delegation process, the AS 
will be unable to know what the client is doing. In addition, an AS-centric
architecture would not be scalable and would need a lot of 
synchronizations between ASs and RSs. The user consent should be handled 
by the RS
and not by the AS. When a RS is unable to provide the service, it is 
best placed to tell directly to the client what it could do next.

RFC 6973 is very good document. Section 7.1 states:

           b.  Data.  What information does the protocol expose about 
individuals, their devices, and/or their device usage (other than the 
identifiers discussed in (a))?

Data includes both the operation and the data associated with the 
operation. An AS should be kept ignorant of both the operation and the 
data associated with the operation.

    c.  Observers.  (...) Are there ways for protocol implementers to 
    choose to limit the information shared with each entity?

If theses guidances were followed, the proposed architecture would not 
be AS-centric.

> authorizations
> scoped as narrowly as a single transaction, provide a clear framework 
> for interaction among all parties involved in the protocol flow, and 
> remove
> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. 
> Some existing uses cases (i.e. "*non-expanded"* use cases) should be 
> supported
> [Roman] I’d want to hear others on this rescoping.  Building upon the 
> use cases of OAuth 2.0 and OpenID Connect has been core, 
> consensus-validated tenant for some time now.
> The delegation process will be acted upon by multiple parties in the 
> the channels used
> by the protocol participants to communicate from the delegation 
> channel, which happens directly between the client and the 
> authorization server (in contrast
> [Roman] This sentence was just added into -05 address Security AD 
> feedback.  In this case, it was made to distinguish between in-band 
> signaling and the new purpose-to-be-built channel.

Since delegation should not be handled by the AS, a delegation channel 
should not exist.

> The protocol will include a means of specifying how the user can 
> potentially be involved in an interactive fashion during the 
> delegation process.
> The client and Authorization Server (AS) will use these interaction 
> [Denis] Here again, the delegation process, if any, should be handled 
> by RSs and not by ASs. The AS should know as little as possible 
> (including nothing)
> [Roman] Understood – as I understand it, you have concern with the 
> scope of the AS behavior.  I’d be interesting in hearing additional 
> support for this rescoping.
> This decoupling avoids many of the security concerns and technical 
> challenges of OAuth 2.0 and provides a non-invasive path for 
> supporting future types
> [Roman] Can someone on the TxAuth mailing list remind us on why this 
> sentence is here?  With a fresh read, I also can’t remember why we 
> need it.
> [Denis] In order to support the user's privacy, there should be no 
> interaction at all between an authorization server and a resource server
> /at the time of a client request/.
> -Separation between the party authorizing access and the party 
> operating the client requesting access
> [Denis] It is questionable whether such a separation would be really 
> beneficial. In doubt, this item should be removed.

Except for added complexity, there is no need to have separate channels. 
It is simpler to send the access token in addition to the data
and, for additional security, to sign the data using a private key 
corresponding to a public key present in the access token.

> Optimized inclusion of additional information (including identifiers 
> and identity assertions) through the delegation process
> communicate the granted access model
> [Denis] While it is the duty for the RS to communicate the granted 
> access model to the client /at the appropriate instant of time/,
> Although the artifacts for this work are not intended or expected to 
> be backwards-compatible with OAuth 2.0 or OpenID Connect,
> Connect to the new protocol where possible.
> This group is not chartered to develop extensions to OAuth 2.0, and as 
> such will focus on new technological solutions not necessarily
> compatible with OAuth 2.0. Functionality that builds directly on OAuth 
> 2.0 will be directed to the OAuth Working Group, including
> The group is chartered to develop mechanisms for applying 
> cryptographic methods, such as JOSE and COSE, to the delegation process.
> information within the protocol including existing identifiers
> identifiers) and assertions (such as OpenID Connect ID Tokens,
> SAML Assertions, and Verifiable Credentials). The group is not 
> chartered to develop new formats for identifiers or assertions, nor is 
> the group
> The initial work will focus on using HTTPS for communication between 
> the client and the authorization server, taking advantage
> of optimization features of HTTP/2 and HTTP/3 where possible, and will 
> strive to enable simple mapping to other protocols such as COAP
> one RS should be defined.
> Privacy principles should be applied when defining the protocol. Then 
> after, a delegation mechanism allowing one RS to forward an operation 
> to another RS should be defined.
> -Key presentation mechanism bindings to the core protocol including 
> TLS, detached HTTP signature, and embedded HTTP signatures
> maintained ?
> Signatures may be needed but they do not necessarily need to be 
> "detached HTTP signature, and embedded HTTP signatures".

As explained above, it is possible to sign the data using a private key 
corresponding to a public key present in the access token.

> review in order to have a named activity to action the design goal of 
> “… the group will attempt to simplify migrating from OAuth 2.0 and 
> OpenID Connect to the new protocol where possible” a bit earlier in 
> the text.
>
> architecture documents, and use case documents. These artifacts will 
> not be considered as working group milestones or deliverables.
>
> The working group will cooperate and coordinate with other IETF WGs 
> such as OAUTH, and work with external organizations,
> [Roman] Definitely.  Nevertheless, we have the current text through 
> rough consensus process achieved from two BoFs and multiple mailing 
> list consensus calls.
>
In a previous post, I proposed a much shorter text.

Denis

>     IESG mailing list ([email-masked]  <mailto:[email-masked]>)*by 2020-07-06*.
>
>        Yaron Sheffer<[email-masked]>  <mailto:[email-masked]>
>
>        Leif Johansson<[email-masked]>  <mailto:[email-masked]>
>
>     Assigned Area Director:
>
>        Roman Danyliw<[email-masked]>  <mailto:[email-masked]>
>
>     Security Area Directors:
>
>        Benjamin Kaduk<[email-masked]>  <mailto:[email-masked]>
>
>        Roman Danyliw<[email-masked]>  <mailto:[email-masked]>
>
>     Mailing list:
>
>        Address:[email-masked]  <mailto:[email-masked]>
>
>        To subscribe:​https://www.ietf.org/mailman/listinfo/txauth
>
>        Archive:https://mailarchive.ietf.org/arch/browse/txauth/
>
>     Group page:https://datatracker.ietf.org/group/gnap/
>
>     Charter:https://datatracker.ietf.org/doc/charter-ietf-gnap/
>

---

From: Tom Jones <[email-masked]>
Date: Tue, 7 Jul 2020 08:28:16 -0700

To be perfectly blunt about it, if Denis' view on the AS were to prevail. I
would have little use for the resulting standards and would not even
attempt compliance with them.

thx ..Tom (mobile)

On Tue, Jul 7, 2020, 5:43 AM Denis <[email-masked]> wrote:

> *From:* iesg <[email-masked]> <[email-masked]> *On Behalf
> Of * Denis
> BTW, I sent an email yesterday evening with the subject: *Support of FIDO*
> and data minimization by RSs, where I indicated that the charter should
> either FIDO or by presenting one (or more) access tokens from one (or more)
> AS.
>
> [Roman]  I don’t exactly follow how considerations for privacy are being negated.  Above and beyond use-case specific considerations that would be defined later,
> RFC6973 is the IETF consensus design guidance that will guide the privacy threats and mitigations of the work.  What design guidance would you recommend that
> the WG should consider that aren’t captured in RFC6973?
>
> I believe my message is quite clear : If the AS is handling the delegation
> process, it will know what the client is doing or where it is going.
> On the contrary, if the RS is handling the delegation process, the AS will
> be unable to know what the client is doing. In addition, an AS-centric
> synchronizations between ASs and RSs. The user consent should be handled by
> the RS
> and not by the AS. When a RS is unable to provide the service, it is best
> placed to tell directly to the client what it could do next.
>
> operation. An AS should be kept ignorant of both the operation and the data
> associated with the operation.
>
> c.  Observers.  (...) Are there ways for protocol implementers to  choose
> to limit the information shared with each entity?
>
> If theses guidances were followed, the proposed architecture would not be
> AS-centric.
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 7 Jul 2020 12:03:30 -0400

Denis,

A lot of what you’re describing below changes the very nature of the roles in the system. The component that manages the consent and issues tokens is, by definition, the AS. The user shouldn’t ever have to interact directly with the RS, since the RS is, by definition, an API that is called by software, not an interactive component. 

But it’s important to note that these are only :roles: to be played and not strictly speaking separate pieces of software, and that these roles can be combined and split in a variety of ways. For instance, in what you’re talking about below, instead of saying that it’s the RS that manages the consent, what if you saw it as the functionality of the AS that’s been split between two components: one privacy-preserving element that issues tokens, and another that deals with interaction and consent. This is already a pattern that some in the WG have expressed interest in supporting with GNAP, and the core charter tenet of separating the interaction from the delegation channels is something that could help there. 

Would it be possible to look at your use case in this different light? It’s always possible that we need to re-cast some of these roles, and that’s been done before: in OAuth 2 we defined the AS and RS roles separately, even though they can always be deployed together anyway. So with that it’s possible that there are other distinct pieces here that are working together that we need to tease out, but that’s something for the WG to figure out. We can always decide to separate out the parts and allow them to be recombined in deployment, But I do not think it is helpful to redefine the existing roles, especially by moving key facets from one existing role to another.

 — Justin

> On Jul 7, 2020, at 8:43 AM, Denis <[email-masked]> wrote:
> 
> Hi Roman,
>> Hi Denis!
>>  
>> From: iesg <[email-masked]> <mailto:[email-masked]> On Behalf Of Denis
>> To: [email-masked] <mailto:[email-masked]>
>> Cc: [email-masked] <mailto:[email-masked]>
> BTW, I sent an email yesterday evening with the subject: Support of FIDO and data minimization by RSs, where I indicated that the charter should 
> mention FIDO U2F so that it should be possible to logon to a RS using either FIDO or by presenting one (or more) access tokens from one (or more) AS.
> 
> The original email is here : https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/ <https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/>charter-ietf-gnap-00-05
>> 
> I believe my message is quite clear : If the AS is handling the delegation process, it will know what the client is doing or where it is going. 
> On the contrary, if the RS is handling the delegation process, the AS will be unable to know what the client is doing. In addition, an AS-centric 
> architecture would not be scalable and would need a lot of synchronizations between ASs and RSs. The user consent should be handled by the RS 
> and not by the AS. When a RS is unable to provide the service, it is best placed to tell directly to the client what it could do next. 
> 
>           b.  Data.  What information does the protocol expose about individuals, their devices, and/or their device usage (other than the identifiers discussed in (a))? 
> 
> Data includes both the operation and the data associated with the operation. An AS should be kept ignorant of both the operation and the data associated with the operation.
> 
> c.  Observers.  (...) Are there ways for protocol implementers to  choose to limit the information shared with each entity?  
> 
> If theses guidances were followed, the proposed architecture would not be AS-centric.
> 
>>  
> Since delegation should not be handled by the AS, a delegation channel should not exist.
> 
>>  
> Except for added complexity, there is no need to have separate channels. It is simpler to send the access token in addition to the data 
> and, for additional security, to sign the data using a private key corresponding to a public key present in the access token.
> 
> As explained above, it is possible to sign the data using a private key corresponding to a public key present in the access token.
> 
>>  
>> IESG mailing list ([email-masked] <mailto:[email-masked]>) by 2020-07-06.
>>  
>>   Yaron Sheffer <[email-masked]> <mailto:[email-masked]>
>>   Leif Johansson <[email-masked]> <mailto:[email-masked]>
>>  
>> Assigned Area Director:
>>   Roman Danyliw <[email-masked]> <mailto:[email-masked]>
>>  
>> Security Area Directors:
>>   Benjamin Kaduk <[email-masked]> <mailto:[email-masked]>
>>   Roman Danyliw <[email-masked]> <mailto:[email-masked]>
>>  
>> Mailing list:
>>   Address: [email-masked] <mailto:[email-masked]>
>>   To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>   Archive: https://mailarchive.ietf.org/arch/browse/txauth/ <https://mailarchive.ietf.org/arch/browse/txauth/>
>>  
>> Group page: https://datatracker.ietf.org/group/gnap/ <https://datatracker.ietf.org/group/gnap/>
>>  
>> Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ <https://datatracker.ietf.org/doc/charter-ietf-gnap/>
>>

---

From: Denis <[email-masked]>
Date: Tue, 7 Jul 2020 19:04:23 +0200

Justin,
> Denis,
>
> A lot of what you’re describing below changes the very nature of the 
> roles in the system. The component that manages the consent and issues 
> tokens is, by definition, the AS.

The current charter states: "the artifacts for this work are not 
intended or expected to be backwards-compatible with OAuth 2.0 or OpenID 
Connect".
So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do not 
need to stick with all their concepts.

I believe that the user's consent should be given after a dialogue with 
the RS which does not mean that the RS shall capture the user's consent
since it is the duty of the client. When a user selects one operation 
among a choice of operations proposed by the RS, the RS should inform
the client about which attributes it needs to present and from which 
ASs. It is only at this moment that the clients learns which ASs are
adequate. Before this moment, the dialogue *cannot* be handled by an AS. 
Then after the duty of the client is to look for these attributes and
to get them from one or more ASs. ASs are all equal. There is no single 
AS with which the user shall be bound or have a particular relationship

Managing the authorization (and the user's consent) at the RS is simple: 
I have proposed a way to do it (and FIDO U2F is even included).

Managing the authorization at the AS would mandate a close 
synchronization between the RS and all the ASs with which it has a 
relationship.
There would be the need to define a synch. protocol and it is much 
simpler to avoid to use such a protocol and thus not to define it.
"Out-of-bands" means for such a synchronisation would not be a better 
solution. But the major issue by managing the user's consent at the AS
is to allow the AS to act as Big Brother.

A copy and paste from a document published under the "Digital Europe for 
All" (DE4A) project :

    The privacy principle requires that the private life, the home and
    the communications of each citizen
    are respected and that no personal data are gathered without a
    legitimate reason and purpose.

    Data protection and privacy should (as far as possible) be *achieved
    by design*, i.e. be embedded in the
    technical solutions and services in a way that misuse or
    illegitimate access is made impossible or at
    least very difficult through the technical approach itself, and
    *without having to rely on organisational **
    **measures or solely on legal measures to guarantee the compliance*.

    Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action
    Plan, EIF, Tallinn Declaration, and
    SDGR.

> The user shouldn’t ever have to interact directly with the RS, since 
> the RS is, by definition, an API that is called by software, not an 
> interactive component.
>
> But it’s important to note that these are only :roles: to be played 
> and not strictly speaking separate pieces of software, and that these 
> roles can be combined and split in a variety of ways. For instance, in 
> what you’re talking about below, instead of saying that it’s the RS 
> that manages the consent, what if you saw it as the functionality of 
> the AS that’s been split between two components: one 
> privacy-preserving element that issues tokens, and another that deals 
> with interaction and consent. This is already a pattern that some in 
> the WG have expressed interest in supporting with GNAP, and the core 
> charter tenet of separating the interaction from the delegation 
> channels is something that could help there.
>
> Would it be possible to look at your use case in this different light?

I could see the RS (i.e. not the AS) split into two components: an API 
and an MMI to manage the choices and the consent of the user.
This looks artificial but would it help ?

Denis

> It’s always possible that we need to re-cast some of these roles, and 
> that’s been done before: in OAuth 2 we defined the AS and RS roles 
> separately, even though they can always be deployed together anyway. 
> So with that it’s possible that there are other distinct pieces here 
> that are working together that we need to tease out, but that’s 
> something for the WG to figure out. We can always decide to separate 
> out the parts and allow them to be recombined in deployment, But I do 
> not think it is helpful to redefine the existing roles, especially by 
> moving key facets from one existing role to another.
>
>  — Justin
>
>> On Jul 7, 2020, at 8:43 AM, Denis <[email-masked] 
>>> *From:*iesg<[email-masked]>*On Behalf Of*Denis
>>> *Sent:*Monday, July 6, 2020 10:55 AM
>>> *To:[email-masked]
>>> *Cc:[email-masked]
>>> *Subject:*Re: [Txauth] WG Review: Grant Negotiation and 
>> BTW, I sent an email yesterday evening with the subject:*Support of 
>> FIDO*and data minimization by RSs, where I indicated that the charter 
>> should
>> The original email is here 
>> :https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/
>>
>>>
>>>     charter-ietf-gnap-00-05
>>>
>>> This group is chartered to develop a fine-grained delegation 
>>> protocol for authorization, API access, user identifiers, and 
>>> identity assertions.
>>> [Denis] Fine.
>>> [Denis] This sentence is too vague because "as part of its request" 
>>> is not explicit enough. If it means  "as part as an access token 
>>> request"
>>> this should be explicitly said. If, it is not the case, then it 
>>> should be clearly explained. The AS should know as little as 
>>> possible (including nothing)
>>> is negating the fact that the user's privacy will ever be 
>>> considered. IMHO, I believe that a RS may delegate some operation to 
>>> another RS,
>>> being negated.  Above and beyond use-case specific considerations 
>>> that would be defined later, RFC6973 is the IETF consensus design 
>>> guidance that will guide the privacy threats and mitigations of the 
>>> work.  What design guidance would you recommend that the WG should 
>>> consider that aren’t captured in RFC6973?
>>
>> delegation process, it will know what the client is doing or where it 
>> is going.
>> synchronizations between ASs and RSs. The user consent should be 
>> handled by the RS
>> operation. An AS should be kept ignorant of both the operation and 
>> the data associated with the operation.
>>
>>     c.  Observers.  (...) Are there ways for protocol implementers
>>     to  choose to limit the information shared with each entity?
>>
>>> It will *expand* upon the uses cases currently supported by OAuth 
>>> 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support 
>>> authorizations
>>> scoped as narrowly as a single transaction, provide a clear 
>>> framework for interaction among all parties involved in the protocol 
>>> flow, and remove
>>> [Roman] I’d want to hear others on this rescoping.  Building upon 
>>> the use cases of OAuth 2.0 and OpenID Connect has been core, 
>>> protocol, each performing a specific role. The protocol will 
>>> decouple the channels used
>>> [Denis] Here again, the delegation process, if any, should be 
>>> handled by RSs and not by ASs. The AS should know as little as 
>>> possible (including nothing)
>> Except for added complexity, there is no need to have separate 
>> channels. It is simpler to send the access token in addition to the data
>>> the group will attempt to simplify migrating from OAuth 2.0 and 
>>> OpenID Connect to the new protocol where possible.
>>> This group is not chartered to develop extensions to OAuth 2.0, and 
>>> as such will focus on new technological solutions not necessarily
>>> compatible with OAuth 2.0. Functionality that builds directly on 
>>> OAuth 2.0 will be directed to the OAuth Working Group, including
>>> chartered to develop new formats for identifiers or assertions, nor 
>>> is the group
>>> chartered to develop schemas for user information, profiles, or 
>>> other identity attributes, unless a viable existing format is not 
>>> available.
>>> of optimization features of HTTP/2 and HTTP/3 where possible, and 
>>> will strive to enable simple mapping to other protocols such as COAP
>>> [Denis] Before defining a "Core delegation protocol", a simple 
>>> client server-protocol involving the presentation of several access 
>>> tokens to one RS should be defined.
>>> Privacy principles should be applied when defining the protocol. 
>>> Then after, a delegation mechanism allowing one RS to forward an 
>>> operation to another RS should be defined.
>> As explained above, it is possible to sign the data using a private 
>> key corresponding to a public key present in the access token.
>>
>>> review in order to have a named activity to action the design goal 
>>> of “… the group will attempt to simplify migrating from OAuth 2.0 
>>> and OpenID Connect to the new protocol where possible” a bit earlier 
>>> in the text.
>>> Where possible, the group will seek to make use of tools to guide 
>>> and inform the standardization process including formal analysis,
>> [email-masked] <mailto:[email-masked]>

---

From: Tom Jones <[email-masked]>
Date: Tue, 7 Jul 2020 10:06:56 -0700

Again to be blunt, my flow for consent doesn't match yours.

thx ..Tom (mobile)

On Tue, Jul 7, 2020, 10:04 AM Denis <[email-masked]> wrote:

> Justin,
>
> Denis,
>
> A lot of what you’re describing below changes the very nature of the roles
> in the system. The component that manages the consent and issues tokens is,
> by definition, the AS.
>
> The current charter states: "the artifacts for this work are not intended
> or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect".
> So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do not need
> to stick with all their concepts.
>
> the client about which attributes it needs to present and from which ASs.
> It is only at this moment that the clients learns which ASs are
> to get them from one or more ASs. ASs are all equal. There is no single AS
> with which the user shall be bound or have a particular relationship
>
> Managing the authorization (and the user's consent) at the RS is simple: I
> have proposed a way to do it (and FIDO U2F is even included).
>
> Managing the authorization at the AS would mandate a close synchronization
> between the RS and all the ASs with which it has a relationship.
> There would be the need to define a synch. protocol and it is much simpler
> to avoid to use such a protocol and thus not to define it.
> The privacy principle requires that the private life, the home and the
> communications of each citizen
> are respected and that no personal data are gathered without a legitimate
> reason and purpose.
>
> Data protection and privacy should (as far as possible) be *achieved by
> design*, i.e. be embedded in the
> technical solutions and services in a way that misuse or illegitimate
> access is made impossible or at
> least very difficult through the technical approach itself, and *without
> having to rely on organisational *
> *measures or solely on legal measures to guarantee the compliance*.
>
> Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action Plan,
> EIF, Tallinn Declaration, and
> SDGR.
>
> The user shouldn’t ever have to interact directly with the RS, since the
> RS is, by definition, an API that is called by software, not an interactive
> component.
>
> But it’s important to note that these are only :roles: to be played and
> not strictly speaking separate pieces of software, and that these roles can
> be combined and split in a variety of ways. For instance, in what you’re
> talking about below, instead of saying that it’s the RS that manages the
> consent, what if you saw it as the functionality of the AS that’s been
> split between two components: one privacy-preserving element that issues
> tokens, and another that deals with interaction and consent. This is
> already a pattern that some in the WG have expressed interest in supporting
> with GNAP, and the core charter tenet of separating the interaction from
> the delegation channels is something that could help there.
>
> I could see the RS (i.e. not the AS) split into two components: an API and
> an MMI to manage the choices and the consent of the user.
> separately, even though they can always be deployed together anyway. So
> with that it’s possible that there are other distinct pieces here that are
> working together that we need to tease out, but that’s something for the WG
> to figure out. We can always decide to separate out the parts and allow
> them to be recombined in deployment, But I do not think it is helpful to
> redefine the existing roles, especially by moving key facets from one
> existing role to another.
>
>  — Justin
>
> Of *Denis
> existing format is not available.<o:p cl
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 7 Jul 2020 14:05:47 -0400

> Again to be blunt, my flow for consent doesn't match yours.

Thanks, Tom — we are aware that there are pulls from different directions here, and that’s why I think it’s important for the group to try and look at them the same way. Declarations that there is one and only one use case aren’t helpful. I’ve said before, and I’ll say again, that I think that we can have both trust models inside GNAP.

> thx ..Tom (mobile)
> 
> On Tue, Jul 7, 2020, 10:04 AM Denis <[email-masked] <mailto:[email-masked]>> wrote:
> Justin,
>> Denis,
>> 
>> A lot of what you’re describing below changes the very nature of the roles in the system. The component that manages the consent and issues tokens is, by definition, the AS.
> The current charter states: "the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect".
> So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do not need to stick with all their concepts.
> 
No, but what you call things does matter. Reassigning a piece of functionality from one component to another without changing the name is problematic, as it causes a lot of confusion. We can’t change the model that OAuth 2 gave us, we live in a world where it already exists. It’s not helpful to try to force a new definition on something. But we can transcend that model with GNAP, and sometimes that means questioning the atomicity of our components and their roles. 

> I believe that the user's consent should be given after a dialogue with the RS which does not mean that the RS shall capture the user's consent 
> since it is the duty of the client. When a user selects one operation among a choice of operations proposed by the RS, the RS should inform 
> the client about which attributes it needs to present and from which ASs. It is only at this moment that the clients learns which ASs are
> adequate. Before this moment, the dialogue *cannot* be handled by an AS. Then after the duty of the client is to look for these attributes and 
> to get them from one or more ASs. ASs are all equal. There is no single AS with which the user shall be bound or have a particular relationship
> 
> Managing the authorization (and the user's consent) at the RS is simple: I have proposed a way to do it (and FIDO U2F is even included).
> 
> 
> Managing the authorization at the AS would mandate a close synchronization between the RS and all the ASs with which it has a relationship.
> There would be the need to define a synch. protocol and it is much simpler to avoid to use such a protocol and thus not to define it.
> "Out-of-bands" means for such a synchronisation would not be a better solution. But the major issue by managing the user's consent at the AS 
Again, you seem to assume that the AS cannot be something that is in the control of the RS, the client, or the user. That’s not true. It’s a functional role in the system, not a deployment requirement.

> A copy and paste from a document published under the "Digital Europe for All" (DE4A) project :
> 
> The privacy principle requires that the private life, the home and the communications of each citizen 
> are respected and that no personal data are gathered without a legitimate reason and purpose.
> 
> Data protection and privacy should (as far as possible) be achieved by design, i.e. be embedded in the 
> technical solutions and services in a way that misuse or illegitimate access is made impossible or at 
> least very difficult through the technical approach itself, and without having to rely on organisational 
> measures or solely on legal measures to guarantee the compliance. 
> 
> Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action Plan, EIF, Tallinn Declaration, and 
> SDGR. 
> 
>> The user shouldn’t ever have to interact directly with the RS, since the RS is, by definition, an API that is called by software, not an interactive component. 
>> 
> I could see the RS (i.e. not the AS) split into two components: an API and an MMI to manage the choices and the consent of the user. 

I believe so, because then the “MMI” is defined as a separate functional component. Don’t be surprised when people classify it as “part of the AS”, since that’s where that functionality was previously hosted. It’s like the early days of OAuth 2 where people talked about both the “AS” and “RS” as the “server”, since that was the component that both pieces fulfilled. And indeed, there are a lot of OAuth 2 deployments that combine these two today. There are also other arrangements like the ones you’ve been talking about where the trust is distributed differently. 

 — Justin

> Denis
> 
>> It’s always possible that we need to re-cast some of these roles, and that’s been done before: in OAuth 2 we defined the AS and RS roles separately, even though they can always be deployed together anyway. So with that it’s possible that there are other distinct pieces here that are working together that we need to tease out, but that’s something for the WG to figure out. We can always decide to separate out the parts and allow them to be recombined in deployment, But I do not think it is helpful to redefine the existing roles, especially by moving key facets from one existing role to another.
>> 
>>  — Justin
>> 
>>> On Jul 7, 2020, at 8:43 AM, Denis <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Roman,
>>>> Hi Denis!
>>>>