The XYZ protocol is an attempt to pull together functionality from many different extensions and deployments of OAuth 2. Here, we'll try to map specific concepts from these different protocols into the XYZ system.
scope parameter in OAuth 2 lets a client specify a set of strings to describe the kind of access it wants. While XYZ allows for a much richer set of authorization details to be requested, scopes are a nice simplification for client developers talking to a known API.
XYZ allows this simplification through the use of resource handles, which can be specified by the AS and used in lieu of a resources object. After all, a scope value is nothing more than a shorthand for a specific set of authorizations being requested. So to translate an OAuth 2 request of
scope=foo bar baz, you simply request
resources=[foo, bar, baz] instead.
redirect interaction mechanism with a
callback return method allows a client to send a user to interact using HTTP redirects, and for the most part this should be indistinguishable from the authorization code flow in OAuth 2. The key difference is what gets sent in the front channel. In OAuth 2, the client has to send a lot of sensitive information through the browser, including the scopes it's asking for and its own identity. In XYZ, the client simply goes to an opaque URL that it is given in direct response to its transaction request. The interaction reference returned is equivalent to the authorization code itself, and this handle is useful only in the context of a current transaction. Furthermore, the interaction reference is cryptographically bound to a set of secrets known to the client and AS at runtime.
This type of interaction can be used for web servers, SPA's, and native applications without modification. In fact, most of the differences between these types of clients are in the ways that they can manage keys and secrets. Since the binding of keys and the mode of interaction are separated in XYZ, they can be combined in ways that make the most sense for the client at hand without changing to a different grant type like in OAuth 2.
Similarly to the authorization code grant, the device grant simply makes use of the
user_code interaction mechanism along with polling. There is no longer a need for a separate "device" endpoint because the transaction endpoint covers both this functionality as well as token endpoint functionality. There also does not need to be a separate URL that combines the user code and its delivery URL because the arbitrary URL in the
redirect method can fill this need without the same security issues that a combined URL would have.
The client credentials grant in XYZ is simply one that does not require user interaction, nor does it require any information about the user. In other words, neither a
interaction section are included in the transaction request.
We could even include the
usersection with a value of
falseto specifically signal this mode.
The resource owner grant could be replicated in XYZ by presenting the user's credentials as part of the
user section of the transaction request. However, even more powerfully, the client can present a wide variety of verifiable assertions in this section for the AS to validate and interpret as it sees fit. Chained authorization and authentication are possible in this way, as are forms of linked delegation for cases where the client already knows who the user is and has the authority to do something on their behalf, but needs to translate the authentication to something that can be used further downstream. Additionally, the client could participate in a challenge-response protocol, prompting the user and user's device. These are all part of the various interaction methods for the client.
OAuth 2 makes the assumption that all clients have been registered with the authorization server ahead of time, and that this registration includes a wide swath of information about the client software, including its capabilities, its keys, its identity, and other items. This assumption lead to the development of the dynamic registration protocol to allow client instances to be managed at runtime, but at the cost of an additional round trip.
In XYZ, the client has the choice of presenting all of this information during the transaction request. This dynamic request can be bound to keys during the transaction itself, and these keys can be created by the client instance (as would be likely in a native application) or supplied during the transaction response (as would potentially be the case with an SPA). These keys identify the instance, and the AS can return a client handle that the client can use to identify itself in future transactions.
Static registration is of course still possible, with the client or developer being issued a client handle out of band and the client presenting that handle during its transaction request. Similarly, this handle can be pre-bound to keys and interaction methods, effectively locking down a client's runtime behavior when such a lock is desired.
UMA's pattern of giving the client a
ticket to present claims for, either proactively or interactively, closely matches XYZ's transactional model. UMA's more complex resource description can be incorporated into XYZ's
resources section. If the client wants to represent the same user over time, the AS can issue a user handle much like UMA's PCT.
The main component that's missing would be to allow an RS to start a transaction and hand that transaction handle to the client, and this could potentially be built up using the resource handle.
The main addition that OpenID Connect brings is the ability to pass identity information to the client. An XYZ-based identity protocol could be as simple as returning an identity assertion alongside the access token using the
claims request, much in the same way the ID Token is returned in OpenID Connect today. Similarly, the UserInfo Endpoint remains a standardized resource server that behaves the same as it does today.
Many of the additional mechanisms in OpenID Connect can be incorporated into the transaction request instead of being passed through the browser, including any
login_hint, or vectors of trust parameters. Additionally, the
claims mechanism can be readily incorporated into the
resources portion of the request.
Other mechanisms in OpenID Connect become unnecessary additions, including the request object and hybrid signed response modes. Many of these components were intend to overcome shortcomings in the OAuth 2 protocol that XYZ does not share.
CIBA maps to XYZ's
device style interaction method, since the user is going to interact with the AS using a secondary application. User information and hints about the intended account can be pushed in the
user section of the transaction request.
OpenID Connect's Request Object was born of a need to protect a client's request through the browser, and the hybrid flow (later generalized into JARM) provided a means to protect the authorization server's response through the browser. Both of these methods additionally allow a more rich data request through the use of a JSON object instead of plain request parameters. XYZ's transaction model protects this same information by not sending it through the browser redirects in the first place.
FAPI's request object endpoint allows a client to pre-register the request object and pass a reference instead. This type of intent registration is much the same as the transactional model and transaction handle.
PKCE effectively creates an ephemeral key that the client can prove possession of at a later part of the process. With XYZ, the same results are an automatic side effect of the transactional process. The transaction handle is something known only to the client and is never passed through the front channel, and any interaction reference returned from the interaction endpoint makes sense only in the context of a specific transaction. Furthermore, the client's own keys can be bound to the transaction, making it even more difficult for an attacker to make use of a stolen interaction reference.
The main goal of of OAuth 2's Proof of Possession extension work is to bind a set of runtime keys that the client can prove possession of to the token issued to the client. XYZ allows a client to bind keys during its transacton request, and these keys can be further bound to the access token.
The JAR specification provides a means to protect content in the front channel, which XYZ avoids in the first place. However, in combination with the PAR specification, the two provide a way to do a back channel intent registration that is in line with XYZ's transaction request pattern.
The RAR specification is being developed in parallel with XYZ, and its internal content is set to mimic the
resources field of an XYZ transaction. A key difference is that XYZ does not also have to contend with
aud, and other values that the RAR spec does in OAuth 2.
The client ID in OAuth 2 is important to the protocol because it allows the client to identify itself during the initial front channel requests where it cannot authenticate itself. In XYZ, the client starts talking in the back channel where it can always authenticate itself. If the AS recognizes the authentication of a specific key, it can tie the request to a set of policies bound to that key's ID. If the key has been registered with the server, the client can send the key handle instead. In this way, the key handle acts much like the client ID used to. If the AS chooses, it can associate an internal identifier to a client, or set of clients, but the protocol no longer needs to be exposed to this detail.