[Txauth] XYZ-08 vs XAuth-08

[Dick Hardt <[e-mail]>]

Hello

I have just posed some updates on the XAuth draft:

In -07 I added the XYZ features of interaction negotiation, and a Client
Handle for dynamic clients. I also updated the name to GNAP, but preserved
the draft-hardt-xauth-protocol filename for ease of tracking changes.

In -08 I split the doc into: core protocol, advanced features, and JOSE
authentication.

https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html
https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html
https://www.ietf.org/id/draft-hardt-gnap-jose-00.html

IMHO, the main doc is much more readable. :)


*XYZ vs XAuth*

The remaining major differences between XYZ and XAuth are areas I have
concerns about. (I will continue to use XYZ and XAuth refer to each draft).
The concerns are:

*1) API in JSON vs URI and HTTP Verb*

In XYZ, all calls are to the same endpoint as an HTTP POST. The AS must
parse the JSON to determine what to do.

XAuth has a RESTful interface. A Grant Request starts at the GS URI, and
Grants and Authorizations are returned as URI resources. Creating a Grant
is done with a POST, reading a Grant is done with a GET.

With URIs and HTTP verbs, A large scale GS can easily implement independent
services for each  functionality as routing of requests can be done at the
HTTP layer based on the URI and HTTP verb. This allows a separation of
concerns, independent deployment, and resiliency.

*2) Handles for all Clients vs Client ID and Client Handle*

In XYZ, both pre-registered clients and dynamic clients use a handle.

In XAuth, the Client ID refers to a pre-registered client, and the Client
Handle is specific to an instance of a dynamic client. Using separate terms
clearly differentiates which identifier is being presented to the GS.

This allows a GS to use separate mechanisms for managing pre-registered
clients and dynamic clients, an important consideration as there can easily
be millions of instances of a single dynamic client.

Additionally, developers are already familiar with what a Client ID is for
pre-registered clients.

*3) Transaction Handles are One Time Use*

In XYZ, transaction handles are one time use [1]. In the OAuth WG
discussion on one time use refresh tokens, clients are often distributed
across components, which complicates one time use references.

One time use transaction handles also makes them inconsistent with the
display, resource, user, and key handles.

*4) New User Identifier*

XYZ introduces a new identifier for the user, a User Handle. Unclear why a
new type of user identifier is needed, except for the desire to have a
handle for everything.

*5) Interaction Capabilities vs Modes*

In XYZ, the capabilities are expressed by the client, and the GS states
which capabilities it will accept. This can make it difficult for the GS to
enforce the interaction choices as the client can mix and match which
capabilities are returned. For example, a GS may not want to support a
redirect without a callback to protect itself from session fixation
attacks. In XAuth, the interaction modes provide clarity on the mode of
interaction and the security properties. For example the GS may support
both user_code and redirect modes, but not the indirect mode which is
subject to session fixation attacks.

*6) Claims at Top Level vs Namespaced *

In XYZ, there is one schema for claims, and they are requested as:

   "claims": {
       "subject": true,
       "email": true
   }

Whereas in XAuth, claims are in their own namespace:

    "claims": {
        "oidc": {
            "id_token" : {
                "email"          : { "essential" : true },
                "email_verified" : { "essential" : true }
            },
            "userinfo" : {
                "name"           : { "essential" : true },
                "picture"        : null
            }
        }

In this example, the client is requesting OIDC defined claims, the email to
be in an ID Token, and the name and picture to be as text. While the XYZ
schema may be extended, there are already numerous schemas being used. The
XAuth approach is to support existing and new schemas, rather than pick one
and/or create another one, and allows a Grant Request to contain claims
from multiple schemas at the same time.

*7) No Authorization Type*

Similar to (6), XYZ has a single schema for how to request access to a
resource. While that schema is extensible, it requires adaption from any
system with an existing schema. XAuth has a type for each authorization
request (oauth2, rar), allowing existing schemas and new schemas to be
supported.

*Summary*

While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental to the
XYZ architecture.

[1]
https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-7

[2] https://w3c.github.io/vc-data-model/

ᐧ