Subject: [Txauth] About the proposed charter

From: Denis <[email-masked]>
Date: Tue, 16 Jun 2020 15:59:48 +0200

Hello,

I joined this BoF during the last week-end and this is my first post.

The current proposed charter is two pages long, whereas the OAuth 2.0 
charter was half a page long.
We should attempt to make it shorter ... and clearer. Hereafter a full 
rewording of the charter, while
the justification for this rewording is placed after it.

*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
an operation on a resource server, at the time it needs it.

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

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 as narrowly as for a 
single operation.

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 identity attributes, the group is chartered to define such format.

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.

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.

As a difference with OAuth 2.0, there is no bilateral trust relationship 
between authorization servers and resource servers:
for a given category of attributes, a resource server trusts one or more 
authorization servers.

Resource servers only make available to their clients which access token 
formats are acceptable.

As another difference with OAuth 2.0, 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_: For GNAP, this workflow scenario is likely to be incorrect. 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 hat are able to issue such privileges.

I also browsed through previous emails:

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

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 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) and its 
content is meant
to be accessible by the client.

An authorization server / resource server protocol has not been 
explicitly mentioned (but has not been explicitly excluded) because such 
a protocol,
when it is related to a client, may come into contradiction with the 
user's privacy.

Denis

**

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 16 Jun 2020 17:30:37 +0300

Hi Denis,

Welcome to the mailing list and thank you for your proposal.

The charter proposal you read is what the IESG will be reviewing at their telechat next week.

Following their review and hopefully approval, there will be an “external review” period, at which time you’ll be able to offer your suggestions for improving the charter text.

Thanks,

                Yaron

From: Txauth <[email-masked]> on behalf of Denis <[email-masked]>
Date: Tuesday, June 16, 2020 at 17:00
To: <[email-masked]>
Subject: [Txauth] About the proposed charter

Hello,

The current proposed charter is two pages long, whereas the OAuth 2.0 charter was half a page long. 
We should attempt to make it shorter ... and clearer. Hereafter a full rewording of the charter, while 
the justification for this rewording is placed after it. 

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 
an operation on a resource server, at the time it needs it.

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

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 as narrowly as for a single operation.

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 identity attributes, the group is chartered to define such format.

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.

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.

As a difference with OAuth 2.0, there is no bilateral trust relationship between authorization servers and resource servers: 
for a given category of attributes, a resource server trusts one or more authorization servers. 

Resource servers only make available to their clients which access token formats are acceptable.

As another difference with OAuth 2.0, 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 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.

The bad:

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

Comment: For GNAP, this workflow scenario is likely to be incorrect. 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 hat are able to issue such privileges.

The bad:

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, 

About the new proposed text itself

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 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) and its content is meant 
to be accessible by the client.

An authorization server / resource server protocol has not been explicitly mentioned (but has not been explicitly excluded) because such a protocol, 
when it is related to a client, may come into contradiction with the user's privacy.

Denis

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