[Txauth] About the proposed charter

[Denis <[e-mail]>]

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


**