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

From: The IESG <[email-masked]>
Date: Fri, 26 Jun 2020 09:09:41 -0700

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]) by 2020-07-06.

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

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

---

From: Denis <[email-masked]>
Date: Fri, 26 Jun 2020 18:42:26 +0200

The current proposed charter is two pages long, which is far too long, 
while the OAuth 2.0 charter was half a page long.

We should attempt to make the charter shorter ... and understandable. 
Hereafter is a full rewording of the charter,
while the justification of its rewording is placed at the very end of 
this email.

    *New proposed charter*

    This group is chartered to develop a fine-grained protocol in a
    client, authorization server and resource server model,
    where a client can request to one or more authorization servers one
    or more attributes that it needs in order to perform
    one or more operations on a resource server, at the time it needs it.

    The attributes issued by an authorization server are provided in the
    form of an attributes token that is cryptographically signed.

    The protocol supports attributes tokens usable for multiple
    operations as well as narrowly as for a single operation.

    Since the privacy of the user is a concern, privacy by default and
    privacy by design are considered.

    The group is chartered to develop mechanisms for conveying target
    information and identity information within the protocol
    including identity attributes such as pseudonyms, email addresses,
    user names, home addresses, business addresses, phone numbers,
    date of birth, age. When a viable existing format is not available
    for these attributes, the group is chartered to define such format.

    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.

    Through interaction mechanisms supported by the protocol, the
    resource server allows a user to make a decision whether it is
    willing or not
    to disclose some attributes to perform one or more operations.

    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.

    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.

    The group will define interoperable protocols between different
    parties, including:

      * client and authorization server; and
      * client and resource server.

    Milestones to include:

      * Architecture of the model,
      * Attributes token definition, including mechanism bindings
      * Core protocol between the different parties

*Justification for the rewording*

I have re-used the original text whenever it was adequate and concise.

I also read "Identity in XYZ" from: 
https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz*

*The good:

"Rather than returning an ID token with potentially stale or large 
amounts of user information in the authorization response,
let's return only the minimum necessary for the application to function, 
and let it request additional information that it needs when it needs it".

_Comment_: This is a "privacy by default" principle which is indeed 
important.

The good:

"The value MAY vary for the same user when logging in to different 
applications in order to preserve the user's privacy,
preventing different applications from cross-correlating users between 
apps".

_Comment_: This is a privacy principle which is also indeed important.

The bad:

"The transaction response can include just the unique user identifier 
along with the access token. (...)
This property is analogous to the "sub" property in an ID token. This 
value MUST uniquely identify this user within the system,
and MUST be consistent when the same user logs in to the same application".

_Comment_: This is in contradiction with the previous privacy principle.

I also read https://oauth.xyz/.

The bad:

"In XYZ, a client that needs to talk to an API first begins an 
authorization transaction with the authorization server".

_Comment_: IMHO, this workflow scenario is lincorrect. A client that 
needs to talk to an API first begins a dialog
with ... the resource server. Depending upon the kind of operation the 
client wants to perform, the resource server informs the client
about the categories of the attributes that are needed and about the 
authorization servers that are able to issue such attributes.

I also browsed through previous emails from the mailing list:

The bad:

"The client is identified by its key".

_Comment _: With such a paradigm, key rollover would be either 
impossible or rather complicated. A client is identified by ... an 
identifier.
There are diffrent kinds of identifiers whether they are :

      (1) temporarily unique,
      (2) unique to the resource server,
      (3) unique to the authorization server, or
      (4) globally unique.

*About the new proposed text of the charter
*

There is a need to introduce the components of the model and the trust 
relationships (which are different from those of Auth 2.0 which,
by the way, are not mentioned in the charter).

OAuth 2.0 did not (and still does not) consider privacy as being 
important. In this BoF/WG, we should consider the user's privacy as 
being important.

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.

I used the wording "attributes token" in order to make a wording 
difference with "access token". It is similar (but different) since its 
content is meant
to be accessible by the client (whereas it is not allowed to be 
accessible in OAuth 2.0, which makes its content's verification 
impossible by the user).

An authorization server / resource server protocol has not been 
explicitly mentioned (but has not been explicitly excluded).
Such a protocol, if it would be related to a client, would come into 
contradiction with the user's privacy.

Denis Pinkas

DP Security Consulting France

---

From: Dick Hardt <[email-masked]>
Date: Fri, 26 Jun 2020 10:21:27 -0700

I am concerned with the following milestones:

  Oct 2021 - Key presentation mechanism binding to the core protocol, TLS,
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]>
Date: Fri, Jun 26, 2020 at 9:10 AM
Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap)
To: IETF-Announce <[email-masked]>
Cc: <[email-masked]>

Chairs:

Assigned Area Director:

Security Area Directors:

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

expand upon the uses cases currently supported by OAuth 2.0 and OpenID
Connect

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.

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

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

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.

information within the protocol including existing identifiers (such as
email

Milestones to include:

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.

Milestones:

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

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

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce
ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Fri, 26 Jun 2020 10:39:57 -0700

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>

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

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

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

The above is not true.

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

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

The AS can act as the client in many OAuth deployments, as the access token
is a bearer token. That does not mean the AS knows what the client is
doing.

/Dick

ᐧ

---

From: Justin Richer <[email-masked]>
Date: Fri, 26 Jun 2020 17:02:56 -0400

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.
> 
> Oct 2021 - Key presentation mechanism binding for each communication channel to WGLC.
> 
> 
> From: The IESG <[email-masked] <mailto:[email-masked]>>
> To: IETF-Announce <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>>
> 
> 
> 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/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>
> ᐧ
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Tom Jones <[email-masked]>
Date: Fri, 26 Jun 2020 15:09:34 -0700

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
>
> TLS, to
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 27 Jun 2020 15:56:38 -0400

Removing the IESG as this is really a more internal-to-the-group discussion, as it comes down to the scope of use cases that we want to address here in GNAP.

While it is definitely important to understand how and why OAuth 2 does things, we do need to keep use cases like Denis’s in mind. It’s not unheard of today for a single OAuth 2 RS to accept tokens from multiple AS’s. In fact, we’ve even got cases with things like the Solid project where the RS will take a token from :any: AS so long as it can verify that it’s approved by the resource owner. While the Solid platform has its own special layering in place to allow this, our model should not assume a closely-tied connection between an RS and any single AS. The question of :how: we solve that is, of course, up to the WG to figure out over time.

Taking that even further, I think the idea of an AS that’s personal to the user, to promote privacy and control, is a very good one. In fact, this is one of the main selling points of UMA2 and its federated authorization mechanisms. With GNAP, we might be able to deliver on this promise even more than UMA has been able to, and it’s my hope that we can have a cohesive protocol that allows both user-to-self and user-to-another delegation sharing without needing to use different mechanisms. 

Additionally, the RS-first method is also something from the UMA2 work that we should be working on, as it touches on AS discovery, AS/RS communication, and a few other aspects of the protocol design. It’s not a trivial problem by any stretch, and there are huge privacy and security implications, but there’s both need for it and some good prior art to pull from. In fact, XYZ’s whole notion of a “transaction handle” is an adaptation of UMA2’s “permission ticket”. In UMA, this ticket is first issued to the RS by the AS, and the RS then hands it to the client, which starts the negotiation for access. I envision something very similar happening here with GNAP, where a client can get something to bootstrap the process at the AS. The important thing, to me, is that we don’t have to jump through a bunch of weird hoops such that the AS-first and RS-first cases look completely different, as they do in UMA2 and OAuth 2 respectively today. We’ve got the chance to have a clean and cohesive protocol here, let’s not miss that opportunity.

So in sum, the trust model of OAuth 2 is not sufficient to cover everything, and the model that Denis is proposing is something we should at least look at as a use case. Where Denis and I seem to disagree is whether this trust model should be the :only: one that we address with the protocol. I strongly believe, as I believe much of this group does, that we can’t discount or ignore (or make things overly difficult for) the tightly bound AS/RS combos, or any type of static setup where the RS offloads its trust fully to the AS. But it’s my belief that we should be able to do so without needlessly throwing out all of the OAuth 2 use cases.

We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting factor here. We need to understand the what and wherefore of things that OAuth 2 is bad at, otherwise we’re just going to re-invent OAuth 2 and inherit its problems.

 — Justin

> On Jun 26, 2020, at 1:39 PM, Dick Hardt <[email-masked]> wrote:
> 
> 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..
> 
> 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 <https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation>
> 
> 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 client is may be delegating user authentication to the AS in identity claim use cases.
> 
> The AS can act as the client in many OAuth deployments, as the access token is a bearer token. That does not mean the AS knows what the client is doing. 
> 
> /Dick
>  
> ᐧ
> -- 
> Txauth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Sat, 27 Jun 2020 13:14:15 -0700

+1 to 'We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting
factor here.'

Conversely, I worry about scope creep if we are forced to complicate the
protocol to cover use cases that are only theoretical. (I'm not implying
that any of the use cases discussed in this thread are in that category).

/Dick

On Sat, Jun 27, 2020 at 12:56 PM Justin Richer <[email-masked]> wrote:

> Removing the IESG as this is really a more internal-to-the-group
> discussion, as it comes down to the scope of use cases that we want to
> address here in GNAP.
>
> While it is definitely important to understand how and why OAuth 2 does
> things, we do need to keep use cases like Denis’s in mind. It’s not unheard
> of today for a single OAuth 2 RS to accept tokens from multiple AS’s. In
> fact, we’ve even got cases with things like the Solid project where the RS
> will take a token from :any: AS so long as it can verify that it’s approved
> by the resource owner. While the Solid platform has its own special
> layering in place to allow this, our model should not assume a closely-tied
> connection between an RS and any single AS. The question of :how: we solve
> that is, of course, up to the WG to figure out over time.
>
> Taking that even further, I think the idea of an AS that’s personal to the
> user, to promote privacy and control, is a very good one. In fact, this is
> one of the main selling points of UMA2 and its federated authorization
> mechanisms. With GNAP, we might be able to deliver on this promise even
> more than UMA has been able to, and it’s my hope that we can have a
> cohesive protocol that allows both user-to-self and user-to-another
> delegation sharing without needing to use different mechanisms.
>
> Additionally, the RS-first method is also something from the UMA2 work
> that we should be working on, as it touches on AS discovery, AS/RS
> communication, and a few other aspects of the protocol design. It’s not a
> trivial problem by any stretch, and there are huge privacy and security
> implications, but there’s both need for it and some good prior art to pull
> from. In fact, XYZ’s whole notion of a “transaction handle” is an
> adaptation of UMA2’s “permission ticket”. In UMA, this ticket is first
> issued to the RS by the AS, and the RS then hands it to the client, which
> starts the negotiation for access. I envision something very similar
> happening here with GNAP, where a client can get something to bootstrap the
> process at the AS. The important thing, to me, is that we don’t have to
> jump through a bunch of weird hoops such that the AS-first and RS-first
> cases look completely different, as they do in UMA2 and OAuth 2
> respectively today. We’ve got the chance to have a clean and cohesive
> protocol here, let’s not miss that opportunity.
>
> So in sum, the trust model of OAuth 2 is not sufficient to cover
> everything, and the model that Denis is proposing is something we should at
> least look at as a use case. Where Denis and I seem to disagree is whether
> this trust model should be the :only: one that we address with the
> protocol. I strongly believe, as I believe much of this group does, that we
> can’t discount or ignore (or make things overly difficult for) the tightly
> bound AS/RS combos, or any type of static setup where the RS offloads its
> trust fully to the AS. But it’s my belief that we should be able to do so
> without needlessly throwing out all of the OAuth 2 use cases.
>
> We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting factor
> here. We need to understand the what and wherefore of things that OAuth 2
> is bad at, otherwise we’re just going to re-invent OAuth 2 and inherit its
> problems.
>
>  — Justin
>
>> Resource servers inform their clients about which access token formats
>> are acceptable and depending upon the king of operation
> running the client has access..
>
>>
> The AS can act as the client in many OAuth deployments, as the access
> token is a bearer token. That does not mean the AS knows what the client is
> doing.
>
> /Dick
>
> ᐧ
> --
> Txauth mailing list
> [email-masked]

---

From: Tom Jones <[email-masked]>
Date: Sat, 27 Jun 2020 13:45:03 -0700

+1 - Right on Justin.
Peace ..tom

On Sat, Jun 27, 2020 at 1:15 PM Dick Hardt <[email-masked]> wrote:

>> Taking that even further, I think the idea of an AS that’s personal to
>> the user, to promote privacy and control, is a very good one. In fact, this
>> is one of the main selling points of UMA2 and its federated authorization
>> running the client has access...
>>
>>>
>>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original
>> IETF presentation on what became OAuth 2.0
>>
>>> anything to an authorization server. If it would, this would mean that the
>>> authorization server

---

From: Justin Richer <[email-masked]>
Date: Sun, 28 Jun 2020 13:50:21 -0400

I’m also worried about feature creep, but it’s something that the group can guard against in very practical ways. It’s dangerous to dismiss someone else’s work as “only theoretical”, especially because GNAP is going to draw from a different sent of circumstances that are going to be outside the experience of the core OAuth community, and that’s a really good thing. 

But I believe that we can apply a set of sensible criteria to things:

 - Is there an implementation (even a proof of concept)? Running code makes bad assumptions come out in sharp relief, and we need to test these assumptions constantly. But also keep in mind that running code can be changed.
 - Is there an existing, perhaps more convoluted, solution out there? Pulling disparate systems under a common structure should be a way of working here. But this only works if it can come “in common” and we aren’t stretching the abstractions so much that they’re meaningless.
 - Does it fit in the GNAP model along with other work? This might mean we have to adjust the model, but such adjustments shouldn’t be at the expense of all other use cases. Sometimes, things don’t fit, and that’s ok.

Cohesiveness of the GNAP solution will come from applying good engineering and questioning assumptions about our existing and proposed solutions. It’s important that we know the :why: of things and not just the :what:. The last thing I think we want is a protocol that is actually a bunch of completely different protocols with switched behavior. This is one of the biggest complaints that I see about OAuth 2’s “framework” approach and I think we have an opportunity to do much better here if we get the model right. That’s going to take time and effort, but I believe it’s possible, and I look forward to building that with everyone here.

Right now, our best focus is going to be use cases — what do people want to :do: with GNAP — and what those use cases say about our model and assumptions going in to the solution space. There are a number of valuable points in both Tom and Denis’s discussion below. Some of it fits, some of it doesn’t. Some of it might be better for an extension. Some of it might be counter to what we’re after. 

Discussing all of that is why we’re all in a standards working group and not just building a commercial product.

 — Justin

> On Jun 27, 2020, at 4:45 PM, Tom Jones <[email-masked]> wrote:
> 
> +1 - Right on Justin.
> Peace ..tom
> 
> 
> On Sat, Jun 27, 2020 at 1:15 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> +1 to 'We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting factor here.'
> 
> Conversely, I worry about scope creep if we are forced to complicate the protocol to cover use cases that are only theoretical. (I'm not implying that any of the use cases discussed in this thread are in that category).
> 
> /Dick
> 
> On Sat, Jun 27, 2020 at 12:56 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jun 26, 2020, at 1:39 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 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...
>>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 28 Jun 2020 19:32:18 -0700

In case it was not clear from my email, I was not dismissing anybody's work
as "theoretical".

On Sun, Jun 28, 2020 at 10:50 AM Justin Richer <[email-masked]> wrote:

> I’m also worried about feature creep, but it’s something that the group
> can guard against in very practical ways. It’s dangerous to dismiss someone
> else’s work as “only theoretical”, especially because GNAP is going to draw
> from a different sent of circumstances that are going to be outside the
> experience of the core OAuth community, and that’s a really good thing.
>
>  - Is there an implementation (even a proof of concept)? Running code
> makes bad assumptions come out in sharp relief, and we need to test these
> assumptions constantly. But also keep in mind that running code can be
> changed.
>  - Is there an existing, perhaps more convoluted, solution out there?
> Pulling disparate systems under a common structure should be a way of
> working here. But this only works if it can come “in common” and we aren’t
> stretching the abstractions so much that they’re meaningless.
>  - Does it fit in the GNAP model along with other work? This might mean we
> have to adjust the model, but such adjustments shouldn’t be at the expense
> of all other use cases. Sometimes, things don’t fit, and that’s ok.
>
> Cohesiveness of the GNAP solution will come from applying good engineering
> and questioning assumptions about our existing and proposed solutions. It’s
> important that we know the :why: of things and not just the :what:. The
> last thing I think we want is a protocol that is actually a bunch of
> completely different protocols with switched behavior. This is one of the
> biggest complaints that I see about OAuth 2’s “framework” approach and I
> think we have an opportunity to do much better here *if we get the model
> right*. That’s going to take time and effort, but I believe it’s
> possible, and I look forward to building that with everyone here.
>
> Right now, our best focus is going to be use cases — what do people want
> to :do: with GNAP — and what those use cases say about our model and
> assumptions going in to the solution space. There are a number of valuable
> points in both Tom and Denis’s discussion below. Some of it fits, some of
> it doesn’t. Some of it might be better for an extension. Some of it might
> be counter to what we’re after.
>

---

From: Denis <[email-masked]>
Date: Mon, 29 Jun 2020 09:06:39 +0200

Hello Dick,

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

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.

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.

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

> identity claim use cases.

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

> token is a bearer token.

A bearer token is rather insecure.

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

Denis

---

From: Denis <[email-masked]>
Date: Mon, 29 Jun 2020 09:13:53 +0200

Justin,

> While it is definitely important to understand how and why OAuth 2 
> does things, we do need to keep use cases like Denis’s in mind.
Thanks.
> It’s not unheard of today for a single OAuth 2 RS to accept tokens 
> from multiple AS’s.

We are preparing the future. A simple case is to prove "who you are" and 
since banks "need to know their customers"
they would be well placed to provide an access token containing some 
verified personal attributes.

For example, a student would like to change university and would need to 
present his prior graduations.
In such a case, each university or school would be well placed to 
produce such a proof by issuing an access token.

> In fact, we’ve even got cases with things like the Solid project where 
> the RS will take a token from :any: AS so long as it can verify that 
> it’s approved by the resource owner. While the Solid platform has its 
> own special layering in place to allow this, our model should not 
> assume a closely-tied connection between an RS and any single AS. The 
> question of :how: we solve that is, of course, up to the WG to figure 
> out over time.

Would this mean that we strongly agree together that the model should 
not assume a closely-tied connection between an RS and any single AS ?

> the user, to promote privacy and control, is a very good one.

In a previous message, I indicated that I have been able to understand 
what you mean by: an "AS that’s personal to the user" ?

> In fact, this is one of the main selling points of UMA2 and its 
> federated authorization mechanisms. With GNAP, we might be able to 
> deliver
> on this promise even more than UMA has been able to, and it’s my hope 
> that we can have a cohesive protocol that allows both user-to-self
> and user-to-another delegation sharing without needing to use 
> different mechanisms.
>
> communication, and a few other aspects of the protocol design. It’s 
> not a trivial problem by any stretch, and there are huge privacy and 
> security implications, but there’s both need for it and some good 
> prior art to pull from. In fact, XYZ’s whole notion of a “transaction 
> handle” is an adaptation of UMA2’s “permission ticket”. In UMA, this 
> ticket is first issued to the RS by the AS, and the RS then hands it 
> to the client, which starts the negotiation for access. I envision 
> something very similar happening here with GNAP, where a client can 
> get something to bootstrap the process at the AS. The important thing, 
> to me, is that we don’t have to jump through a bunch of weird hoops 
> such that the AS-first and RS-first cases look completely different, 
> as they do in UMA2 and OAuth 2 respectively today. We’ve got the 
> chance to have a clean and cohesive protocol here, let’s not miss that 
> opportunity.
>
> everything, and the model that Denis is proposing is something we 
> should at least look at as a use case.
> Where Denis and I seem to disagree is whether this trust model should 
> be the :only: one that we address with the protocol.

Any trust relationship may be described using the following 
construction:  entity A trusts entity B for some action C.
If you have in mind additional trust relationships, would you be able to 
express them using this construction ?
Maybe you also have in mind some relationships that do not imply a form 
of trust ?

> I strongly believe, as I believe much of this group does, that we 
> can’t discount or ignore (or make things overly difficult for)
> the tightly bound AS/RS combos, or any type of static setup where the 
> RS offloads its trust fully to the AS.
> But it’s my belief that we should be able to do so without needlessly 
> throwing out all of the OAuth 2 use cases.

Reading these sentences confuses me again since they seem to mean that 
the model should assume a closely-tied connection between RSs and ASs.

In OAuth 2.0, the scope parameter allows the client to specify the 
desired scope of the requested security token in the context of the 
service or resource
where the token will be used. The values and associated semantics of 
scope are service specific and and expected to be described in the 
relevant service
documentation [RFC 8693]. Since the scope is RS dependent, the client 
MUST inform the AS about the identity of the RS, but this should be 
avoided for
privacy reasons.

Currently in OAuth 2.0, there is no protocol being defined to be able to 
know which attributes correspond to a given scope for a given RS.
IMHO, the main idea is the following:  rather than using the scope 
parameter, the client should be able to inform directly the AS about
which attributes it needs. In this way, the client would not need to 
inform the AS for which RS these attributes are needed.

A major difference with OAuth 2.0 would be that attributes could be 
requested directly to an AS without using the pair scope/RS.
Such an approach would make the architecture scalable.

Denis

>
> We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting 
> factor here. We need to understand the what and wherefore of things 
> that OAuth 2 is bad at, otherwise we’re just going to re-invent OAuth 
> 2 and inherit its problems.
>
>  — Justin
>
>>         Resource servers inform their clients about which access
>>         token formats are acceptable and depending upon the king of
>>         operation
>> 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..
>>
>>
>>     the client will do, which comes into contradiction with the
>>     user's privacy.
>>
>>
>> The above is not true.
>> token is a bearer token. That does not mean the AS knows what the 
>> client is doing.
>>
>> /Dick
>> ᐧ
>> -- 
>> Txauth mailing list

---

From: Justin Richer <[email-masked]>
Date: Mon, 29 Jun 2020 10:28:09 -0400

Hi Denis,

> On Jun 29, 2020, at 3:13 AM, Denis <[email-masked]> wrote:
> 
> Justin,
> 
>> While it is definitely important to understand how and why OAuth 2 does things, we do need to keep use cases like Denis’s in mind.
> Thanks.
>> It’s not unheard of today for a single OAuth 2 RS to accept tokens from multiple AS’s.
> We are preparing the future. A simple case is to prove "who you are" and since banks "need to know their customers" 
> they would be well placed to provide an access token containing some verified personal attributes.  
> 
> For example, a student would like to change university and would need to present his prior graduations. 
> In such a case, each university or school would be well placed to produce such a proof by issuing an access token.
> 
This is a great example — each university is definitely in place to produce the attributes bound to the user, and therefore to host the “graduation proof” API. But the question is, who will produce the access tokens that can be used for each copy of that API?

In the OAuth 2 trust model, each university would have its own AS protecting its own API. That model still makes sense for a lot of things, and maybe even this case as well. But each university could also accept, say, access tokens from other universities within a consortium, or from a trusted third-party agency, or even an arbitrary AS as long as the access token can prove it’s bound to a user credential the university can trust as being that former student. There are a lot of possibilities, and the details of most of these other scenarios are going to rely on additional pieces that will be defined outside of GNAP.

>> In fact, we’ve even got cases with things like the Solid project where the RS will take a token from :any: AS so long as it can verify that it’s approved by the resource owner. While the Solid platform has its own special layering in place to allow this, our model should not assume a closely-tied connection between an RS and any single AS. The question of :how: we solve that is, of course, up to the WG to figure out over time.
> Would this mean that we strongly agree together that the model should not assume a closely-tied connection between an RS and any single AS ?
> 
Correct, we shouldn’t assume it, but we should also not preclude it. I think a lot of the internet is going keep with that model for some time to come, even if it’s not universal.

>> Taking that even further, I think the idea of an AS that’s personal to the user, to promote privacy and control, is a very good one.
> In a previous message, I indicated that I have been able to understand what you mean by: an "AS that’s personal to the user" ?
> 
This means that a user has their own AS that’s under their personal control. Maybe it’s something they host on the web somewhere, or maybe it’s an app on their personal device, or any number of things. As below, this is the idealized UMA model below, where the user gets to decide which AS to use to protect their data API.
>> In fact, this is one of the main selling points of UMA2 and its federated authorization mechanisms. With GNAP, we might be able to deliver 
>> on this promise even more than UMA has been able to, and it’s my hope that we can have a cohesive protocol that allows both user-to-self 
>> and user-to-another delegation sharing without needing to use different mechanisms. 
>> 
>> So in sum, the trust model of OAuth 2 is not sufficient to cover everything, and the model that Denis is proposing is something we should at least look at as a use case. 
>> Where Denis and I seem to disagree is whether this trust model should be the :only: one that we address with the protocol.
> Any trust relationship may be described using the following construction:  entity A trusts entity B for some action C.
> If you have in mind additional trust relationships, would you be able to express them using this construction ?
> Maybe you also have in mind some relationships that do not imply a form of trust ?
> 
The difference isn’t on what “trust” means, the difference is on which parties are A, B, and C in your equation above, and more importantly, *why* they trust. There are scenarios where the RS would trust the user because the RS knows the user, not because of which AS the user is using. 
>> I strongly believe, as I believe much of this group does, that we can’t discount or ignore (or make things overly difficult for) 
>> the tightly bound AS/RS combos, or any type of static setup where the RS offloads its trust fully to the AS. 
>> But it’s my belief that we should be able to do so without needlessly throwing out all of the OAuth 2 use cases.
> Reading these sentences confuses me again since they seem to mean that the model should assume a closely-tied connection between RSs and ASs.
> 
> In OAuth 2.0, the scope parameter allows the client to specify the desired scope of the requested security token in the context of the service or resource
> where the token will be used. The values and associated semantics of scope are service specific and and expected to be described in the relevant service 
> documentation [RFC 8693]. Since the scope is RS dependent, the client MUST inform the AS about the identity of the RS, but this should be avoided for 
> privacy reasons.
> 
The scope doesn’t have to be RS dependent, you can have many RS’s implementing the same API with the same scopes. There are of course plenty of instances where the scope does identify the RS, but there’s also been other work in the OAuth WG like the “resource” parameter [RFC8707] to provide explicit direction as well. Honestly that aspect of the request is a bit of a mess in OAuth right now, and it’s one of the main things I think we need to clean up here in GNAP. Incidentally, this is why I’m so against simply importing “scope” and RAR directly into GNAP, we need to move past the intrinsic limitations in those systems.
> Currently in OAuth 2.0, there is no protocol being defined to be able to know which attributes correspond to a given scope for a given RS.  
> IMHO, the main idea is the following:  rather than using the scope parameter, the client should be able to inform directly the AS about 
> which attributes it needs. In this way, the client would not need to inform the AS for which RS these attributes are needed.
> 
> A major difference with OAuth 2.0 would be that attributes could be requested directly to an AS without using the pair scope/RS.

In GNAP, we will be defining ways to do fine-grained access control. This will let the client specify what it wants across a wide range of dimensions, and that’s a really powerful pattern. One of the dimensions that the client :could: specify to the AS is which RS it wants to talk to. In some deployments, this will let the AS draft a token that is limited to just that single RS, perhaps by encrypting it against the RS’s key or setting an audience-restriction field. So using the syntax from XYX and RAR (which is a back-port of part of XYZ to OAuth 2), you get something like this:

	{
		resources: {
			location: [“https://rs.example.com/resource <https://rs.example.com/resource>”],
			action: [“read”]
		}
	}

But there are other cases, like what you’re talking about in this thread, where you don’t want the AS to know which RS the client is going to talk to. The client knows, and it just needs to get a token that the RS will trust for the action it wants to take. Using the same syntax, that would look something like this:

	{
		resources: {
			action: [“read”]
			type: “proof_of_graduation”
		}
	}

Which one of these do you use? That’s up to your API deployment. What will your RS want or need to know in order to fulfill the request? What will your AS need in order to create a token that will work for the deployed system? That’s not something the protocol should dictate, but it should allow that choice. The client needs to know what to ask for, the AS needs to know what to expect and issue, and the RS needs to know what to look for in (or about) the token.

This is one of the places where I think we can really start to innovate and bring these worlds together. There’s kind of an artificial split right now and we can do better. OAuth 2 moved us past the concept of the AS and RS being the same system (just called the “server” in OAuth 1), and UMA pushed the conversation further into the AS and RS being introduced to each other during the protocol flow. GNAP can keep this going, and do so without giving up the ability for the RS to be tightly bound to the AS, if the deployment desires or requires it. I think we can do these advanced distributed trust models without getting in the way of the classical AS-as-the-hub trust model form OAuth 2, and both become options that (importantly) work pretty similarly within the GNAP protocol itself.

 — Justin

---

From: Mike Varley <[email-masked]>
Date: Mon, 29 Jun 2020 16:02:32 +0000

Hello Denis, all, I just wanted to jump in on this point below:

From: Txauth <[email-masked]> on behalf of Denis <[email-masked]>
Date: Monday, June 29, 2020 at 3:14 AM

There is a proxy/broker model which sort of is described by the above, but I’d like to call out below.

There are cases where A trusts Z and  B trusts Z, but A and B do not know/trust each other directly, and Z is Not the AS (but there is a trust relationship between Z and the AS – this allows for more than one AS in the trust framework). In order for A and B to interact, the AS will act as a ‘locator’ service and subject-representative, but any associated access tokens the AS generate will require assurances from Z that the participants in the transaction are legitimate entities in the transaction.

Here is a for example: A is a rental car company, B is a DMV. The AS is a personal digital identity management service (*cough* wallet *cough*) that interacts with the license holder/Renter. A, B, and AS have a trust relationship and defined role in an organization Z. When the Renter wishes to provide his eligibility to drive to A, the AS must provide:

  1.  Evidence to A from Z that B is a qualified DMV (permitted to provide the required info).
  2.  Evidence to B from Z that A is a qualified Rental Car Company (permitted to collect the required into).
  3.  Evidence to both A and B from Z that the AS is a trusted subject representative.
  4.  A route for A and B to communicate with each other with all these access permissions.

Note in this model the AS can also be a trusted participant in another Z+1 trust framework.

I see GNAP as an opportunity to support the above model with flexible user agents, AS, discovery, token structures and crypto.

Thanks,

MV

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.

---

From: Tom Jones <[email-masked]>
Date: Mon, 29 Jun 2020 09:35:26 -0700

We have addressed that problem w/i Kantara and have a proposed solution.
See link below.
But there is a caveat.
You MUST stop using the term trust - it has no agreed meaning.
So you must define what attribute needs attestation.
In our case we identified three things that the second party needs to know.
we also stop trying to define the difference between the client and the rs.
At least in our case two parties could switch roles w/i milliseconds.
We defined these attributes to be shared between parties of the many that
could be spec'd.
1. identify proofing
2. authentication proofing
3. proof of presence
each had to be a signed assertion that was included in the az token.
perhaps this model could work for this wg?
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
Peace ..tom

On Mon, Jun 29, 2020 at 9:02 AM Mike Varley <[email-masked]>
wrote:

> *From: *Txauth <[email-masked]> on behalf of Denis <
> [email-masked]>
> *Date: *Monday, June 29, 2020 at 3:14 AM
>
> Any trust relationship may be described using the following construction:
> entity A trusts entity B for some action C.
> There are cases where A trusts Z and  B trusts Z, but A and B do not
> know/trust each other directly, and Z is Not the AS (but there is a trust
> relationship between Z and the AS – this allows for more than one AS in the
> trust framework). In order for A and B to interact, the AS will act as a
> ‘locator’ service and subject-representative, but any associated access
> tokens the AS generate will require assurances from Z that the participants
> in the transaction are legitimate entities in the transaction.
>
> Here is a for example: A is a rental car company, B is a DMV. The AS is a
> personal digital identity management service (*cough* wallet **cough**)
> that interacts with the license holder/Renter. A, B, and AS have a trust
> relationship and defined role in an organization Z. When the Renter wishes
> to provide his eligibility to drive to A, the AS must provide:
>
>    2. Evidence to B from Z that A is a qualified Rental Car Company
>    (permitted to collect the required into).
> I see GNAP as an opportunity to support the above model with flexible user
> agents, AS, discovery, token structures and crypto.
>
> Thanks,
>
> MV
>
> This email and any attachments are for the sole use of the intended
> recipients and may be privileged, confidential or otherwise exempt from
> disclosure under law. Any distribution, printing or other use by anyone
> other than the intended recipient is prohibited. If you are not an intended
> recipient, please contact the sender immediately, and permanently delete
> this email and its attachments.
> --
> Txauth mailing list
> [email-masked]

---

From: Denis <[email-masked]>
Date: Mon, 29 Jun 2020 19:20:04 +0200

Hi Justin,

A good news: we are progressing. The most important sentences from the 
text below are the following:

    [Denis]  Would this mean that we strongly agree together that the
    model should not assume a closely-tied connection between an RS and
    any single AS ?

    [Justin] Correct, *we shouldn’t assume it, but we should also not
    preclude it*. I think a lot of the internet is going keep with that
    model for some time to come, even if it’s not universal.

When we don't assume a closely-tied connection between a RS and any 
single AS, it is possible to respect the user's privacy.
When we assume a closely-tied connection between a RS and a *single AS*, 
it is not possible to respect the user's privacy as soon as a scope/RS 
pair is being used.

In OAuth 2.0, the scope/RS pair is being managed using "out of bands" 
means. If we maintain the use of the scope/RS pair, we should define 
some automated way(s)
to manage it. Let me illustrate it using two extreme examples:

    1) First example: the RS *publicly* publishes a table with a list of
    operations and for each operation, a scope name and the attributes
    that relate to that scope.
    The client connects to the RS and get this table. Knowing the
    operation it wants to perform, it inspects whether the associated
    attributes are adequate
    and then selects the associated scope. Then the client requests an
    access token using a scope/RS pair. In such a case, the AS may know
    which kind operation(s)
    will be performed by the user on that RS.

    2) Second example: the client connects to the RS and indicates which
    kind of operation it wants to perform. The RS replies to the client
    by communicating
    the row in the table which corresponds to that operation and which
    includes a scope name and the attributes that relate to that scope.
    The user inspects
    whether the associated attributes are adequate and then selects the
    associated scope. Then the client requests an access token using a
    scope/RS pair.
    Unless the AS has maliciously used or created an account on that RS,
    the AS will not know which kind operation will be performed by the
    user on that RS. 

The difference between these two cases is the following: in the case 
(1), the table is made publicly available while in case (2) a row of the 
table is only made available
to authenticated clients at the time of the operation. Nevertheless, the 
use of a scope/RS pair will never fully protect the users' privacy.

Denis

> Hi Denis,
>
>> On Jun 29, 2020, at 3:13 AM, Denis <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Justin,
>>
>>> discussion, as it comes down to the scope of use cases that we want 
>>> to address here in GNAP.
>>>
>> We are preparing the future. A simple case is to prove "who you are" 
>> and since banks "need to know their customers"
> This is a great example — each university is definitely in place to 
> produce the attributes bound to the user, and therefore to host the 
> “graduation proof” API. But the question is, who will produce the 
> access tokens that can be used for each copy of that API?
>
> In the OAuth 2 trust model, each university would have its own AS 
> protecting its own API. That model still makes sense for a lot of 
> things, and maybe even this case as well. But each university could 
> also accept, say, access tokens from other universities within a 
> consortium, or from a trusted third-party agency, or even an arbitrary 
> AS as long as the access token can prove it’s bound to a user 
> credential the university can trust as being that former student. 
> There are a lot of possibilities, and the details of most of these 
> other scenarios are going to rely on additional pieces that will be 
> defined outside of GNAP.
>
>>> In fact, we’ve even got cases with things like the Solid project 
>>> where the RS will take a token from :any: AS so long as it can 
>>> verify that it’s approved by the resource owner. While the Solid 
>>> platform has its own special layering in place to allow this, our 
>>> model should not assume a closely-tied connection between an RS and 
>>> any single AS. The question of :how: we solve that is, of course, up 
>>> to the WG to figure out over time.
>>
> Correct, we shouldn’t assume it, but we should also not preclude it. I 
> think a lot of the internet is going keep with that model for some 
> time to come, even if it’s not universal.
>
>>> Taking that even further, I think the idea of an AS that’s personal 
>>> to the user, to promote privacy and control, is a very good one.
>>
>> In a previous message, I indicated that I have been able to 
>> understand what you mean by: an "AS that’s personal to the user" ?
>>
> This means that a user has their own AS that’s under their personal 
> control. Maybe it’s something they host on the web somewhere, or maybe 
> it’s an app on their personal device, or any number of things. As 
> below, this is the idealized UMA model below, where the user gets to 
> decide which AS to use to protect their data API.
>>
>>> on this promise even more than UMA has been able to, and it’s my 
>>> hope that we can have a cohesive protocol that allows both user-to-self
>>> Additionally, the RS-first method is also something from the UMA2 
>>> work that we should be working on, as it touches on AS discovery, 
>>> AS/RS communication, and a few other aspects of the protocol design. 
>>> It’s not a trivial problem by any stretch, and there are huge 
>>> privacy and security implications, but there’s both need for it and 
>>> some good prior art to pull from. In fact, XYZ’s whole notion of a 
>>> “transaction handle” is an adaptation of UMA2’s “permission ticket”. 
>>> In UMA, this ticket is first issued to the RS by the AS, and the RS 
>>> then hands it to the client, which starts the negotiation for 
>>> access. I envision something very similar happening here with GNAP, 
>>> where a client can get something to bootstrap the process at the AS. 
>>> The important thing, to me, is that we don’t have to jump through a 
>>> bunch of weird hoops such that the AS-first and RS-first cases look 
>>> completely different, as they do in UMA2 and OAuth 2 respectively 
>>> today. We’ve got the chance to have a clean and cohesive protocol 
>>> here, let’s not miss that opportunity.
>>>
>>> Where Denis and I seem to disagree is whether this trust model 
>>> should be the :only: one that we address with the protocol.
>>
>> If you have in mind additional trust relationships, would you be able 
>> to express them using this construction ?
> The difference isn’t on what “trust” means, the difference is on which 
> parties are A, B, and C in your equation above, and more importantly, 
> *why* they trust. There are scenarios where the RS would trust the 
> user because the RS knows the user, not because of which AS the user 
> is using.
>>
>>> the tightly bound AS/RS combos, or any type of static setup where 
>>> the RS offloads its trust fully to the AS.
>>> But it’s my belief that we should be able to do so without 
>>> needlessly throwing out all of the OAuth 2 use cases.
>>
>> Reading these sentences confuses me again since they seem to mean 
>> that the model should assume a closely-tied connection between RSs 
>> and ASs.
>>
> The scope doesn’t have to be RS dependent, you can have many RS’s 
> implementing the same API with the same scopes. There are of course 
> plenty of instances where the scope does identify the RS, but there’s 
> also been other work in the OAuth WG like the “resource” parameter 
> [RFC8707] to provide explicit direction as well. Honestly that aspect 
> of the request is a bit of a mess in OAuth right now, and it’s one of 
> the main things I think we need to clean up here in GNAP. 
> Incidentally, this is why I’m so against simply importing “scope” and 
> RAR directly into GNAP, we need to move past the intrinsic limitations 
> in those systems.
>>
>> Currently in OAuth 2.0, there is no protocol being defined to be able 
>> to know which attributes correspond to a given scope for a given RS.
> In GNAP, we will be defining ways to do fine-grained access control. 
> This will let the client specify what it wants across a wide range of 
> dimensions, and that’s a really powerful pattern. One of the 
> dimensions that the client :could: specify to the AS is which RS it 
> wants to talk to. In some deployments, this will let the AS draft a 
> token that is limited to just that single RS, perhaps by encrypting it 
> against the RS’s key or setting an audience-restriction field. So 
> using the syntax from XYX and RAR (which is a back-port of part of XYZ 
> to OAuth 2), you get something like this:
>
> {
> resources: {
> location: [“https://rs.example.com/resource”],
> action: [“read”]
> }
> }
>
> But there are other cases, like what you’re talking about in this 
> thread, where you don’t want the AS to know which RS the client is 
> going to talk to. The client knows, and it just needs to get a token 
> that the RS will trust for the action it wants to take. Using the same 
> syntax, that would look something like this:
>
> {
> resources: {
> action: [“read”]
> Which one of these do you use? That’s up to your API deployment. What 
> will your RS want or need to know in order to fulfill the request? 
> What will your AS need in order to create a token that will work for 
> the deployed system? That’s not something the protocol should dictate, 
> but it should allow that choice. The client needs to know what to ask 
> for, the AS needs to know what to expect and issue, and the RS needs 
> to know what to look for in (or about) the token.
>
> This is one of the places where I think we can really start to 
> innovate and bring these worlds together. There’s kind of an 
> artificial split right now and we can do better. OAuth 2 moved us past 
> the concept of the AS and RS being the same system (just called the 
> “server” in OAuth 1), and UMA pushed the conversation further into the 
> AS and RS being introduced to each other during the protocol flow. 
> GNAP can keep this going, and do so without giving up the ability for 
> the RS to be tightly bound to the AS, if the deployment desires or 
> requires it. I think we can do these advanced distributed trust models 
> without getting in the way of the classical AS-as-the-hub trust model 
> form OAuth 2, and both become options that (importantly) work pretty 
> similarly within the GNAP protocol itself.
>
>  — Justin
>
>> Denis
>>
>>>
>>> that OAuth 2 is bad at, otherwise we’re just going to re-invent 
>>> OAuth 2 and inherit its problems.
>>>
>>>  — Justin
>>>
>>>> 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..
>>>>
>>>>
>>>>         bilateral trust relationship between an authorization
>>>>         server and a resource server:
>>>> This is not how OAuth 2.0 works. See slides 7 and 8 from my 
>>>> original IETF presentation on what became 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 AS can act as the client in many OAuth deployments, as the 
>>>> access token is a bearer token. That does not mean the AS knows 
>>>> what the client is doing.
>>>>
>>>> /Dick
>>>> ᐧ
>>>> -- 
>>>> Txauth mailing list

---

From: Denis <[email-masked]>
Date: Mon, 29 Jun 2020 19:23:53 +0200

Hi Mike,

The following sentence does not describe correctly a trust relationship: 
"There are cases where A trusts Z and  B trusts Z, ..."
since it does not follow the construction indicated in the previous 
email:  entity A trusts entity B *for some action C*.

The following sentence sounds strange to me: "the AS is a personal 
digital identity management service".

A "personal digital identity management service" is fine but I see no 
reason why it can also be an AS
since it does not issue/generate directly access tokens.

Denis

> *From: *Txauth <[email-masked]> on behalf of Denis 
> <[email-masked]>
> know/trust each other directly, and Z is Not the AS (but there is a 
> trust relationship between Z and the AS – this allows for more than 
> one AS in the trust framework). In order for A and B to interact, the 
> AS will act as a ‘locator’ service and subject-representative, but any 
> associated access tokens the AS generate will require assurances from 
> Z that the participants in the transaction are legitimate entities in 
> the transaction.
>
> Here is a for example: A is a rental car company, B is a DMV. The AS 
> is a personal digital identity management service (*cough* wallet 
> **cough**) that interacts with the license holder/Renter. A, B, and AS 
> have a trust relationship and defined role in an organization Z. When 
> the Renter wishes to provide his eligibility to drive to A, the AS 
> must provide:
>
> I see GNAP as an opportunity to support the above model with flexible 
> user agents, AS, discovery, token structures and crypto.
>
> Thanks,
>
> MV
>
> recipients and may be privileged, confidential or otherwise exempt 
> from disclosure under law. Any distribution, printing or other use by 
> anyone other than the intended recipient is prohibited. If you are not 
> an intended recipient, please contact the sender immediately, and 
> permanently delete this email and its attachments.
>