XYZ: Implementing GNAP

What is XYZ?

XYZ is a set of implementations of the Grant Negotiation Authorization Protocol (GNAP), a draft delegation protocol being developed in the spirit of OAuth 2, but designed with the decade of experience that we have now with OAuth 2 and its extensions. XYZ used to be the name of a proposed protocol that was published as an individual draft, but this proposal has been superseded by GNAP. The GNAP Working Group is a working group of the IETF, and discussion is happening now on the txauth@ietf.org mailing list and at the GNAP issue tracker for the core protocol and resource server documents from the working group.

This website contains a live playground of GNAP based on the XYZ implementations, seeking to explain GNAP in a more interactive way than is often possible with a standard document.

What is GNAP?

GNAP is a delegation protocol for HTTP-based systems.

GNAP is not intended to be directly compatible with OAuth 2, much in the same way that OAuth 2 was not directly compatible with OAuth 1. However, the concepts and many of the goals should feel familiar to developers used to these existing protocols and their extensions. Concepts from OAuth 2, OIDC, PKCE, UMA, CIBA, OBUK, FAPI, and a host of other extensions and profiles are being analyzed and adapted in the design of GNAP, but with a mind toward taking the best aspects of all of them and applying them in a consistent way.

GNAP has several core features that drive its design principles, and these are key to providing a consistent data model:

  • Intent registration. This allows the client to start the process off the same way every time by making a request to the authorization server.
  • Don't assume the user has a browser. Interaction needs to happen in a variety of ways depending on the capabilities of the client, and only sometimes will a browser be involved.
  • Minimize the front channel. When a browser is involved, the protocol seeks to minimize the amount and kind of information that passes through the URLs of the front channel.
  • Polymorphic JSON. The protocol elements have different data types that convey additional contextual meaning, allowing us to avoid mutually exclusive protocol elements and design a more succinct and readable protocol. This lets us pass things by reference or by value using the same element field, among other things.
  • Key proofing and presentation. While OAuth 2 thrived on client secrets and bearer tokens, GNAP seeks to move beyond that at the base level, making use of a variety of security technologies.
  • Ease of transition from OAuth 2. Even though this is not backwards compatible, there should be a clear translation path from OAuth 2 based systems to GNAP.
  • Inline negotiation. Whenever possible, the protocol is designed such that discovery and registration are not needed, but they can still be supported.

And most importantly, GNAP seeks to build out a protocol that doesn't have the same assumptions as OAuth 2 by carefully examining and questioning all aspects of OAuth 2 and its extensions. Nothing is considered sacred, even as we build in a world already full of OAuth 2. This lets us question the utility of protocol elements like the client_id and figure out if and how they fit into the new world.

Presentations and Materials

This website is intended to be a reasonably comprehensive collection of information about the XYZ project and GNAP. As GNAP grows and matures, more information will be available externally as well.

In addition to the website, Justin Richer has been fortunate to present XYZ and its concepts at a few different places so far.

Justin has also written a number of articles on the topic of XYZ, GNAP, and the choices behind the protocol design.

Several others in the wider OAuth community have also provided some great discussions on XYZ, GNAP, and the concepts driving this new work.

Implementations

Protocol proposals without implementations are merely thought experiments, and XYZ has always sought to ground all of its ideas in trial implementations. To date there are several code bases that can be downloaded, examined, and tried out. These have changed as the protocol has changed, and will continue to do so as GNAP takes shape. As such, things might be quirky or in a somewhat unfinished, experimental state at any time.

If you have feedback for this website, please see its repository or get in touch directly.