Grant Negotiation and Authorization Protocol

Overview#

Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software. This delegation can include access to a set of APIs as well as information passed directly to the software.

Introduction#

This protocol allows a piece of software, the client instance, to request delegated authorization to Resource Servers and to request direct information. This delegation is facilitated by an Authorization Server usually on behalf of a Resource Owner. The end-user operating the software may interact with the Authorization Server to authenticate, provide consent, and authorize the request.

The process by which the delegation happens is known as a grant, and GNAP allows for the negotiation of the grant process over time by multiple parties acting in distinct roles.

This protocol solves many of the same use cases as OAuth 2.0 RFC 6749, OpenID Connect (OIDC), and the family of protocols that have grown up around that ecosystem. However, GNAP is not an extension of OAuth 2.0 and is not intended to be directly compatible with OAuth 2.0. GNAP seeks to provide functionality and solve use cases that OAuth 2.0 cannot easily or cleanly address. Even so, GNAP and OAuth 2.0 will exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP. Some examples of these can be found in Appendix C.5.

1.2. Roles#

The parties in GNAP perform actions under different roles. Roles are defined by the actions taken and the expectations leveraged on the role by the overall protocol.

Authorization Server (AS)#

Server that grants delegated privileges to a particular instance of client software in the form of an access token and other information (such as subject information).

Client#

Application operated by an end-user that consumes resources from one or several Resource Servers, possibly requiring access privileges from one or several Authorization Servers.

Example: a client can be a mobile application, a web application, etc.

Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.

Resource Server (RS)#

A server that provides operations on Protected Resources, where operations require a valid Access_token issued by an Authorization Server.

Resource Owner (RO)#

Is a subject entity that may grant or deny operations on resources it has authority upon.

Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).

End-user#

A Natural Person that operates a client instance. (Remember a "Client Instance" is an Application)

Note: that Natural Person MAY or MAY NOT be the same entity as the Resource Owner.

1.3. Elements#

In addition to the roles above, the protocol also involves several elements that are acted upon by the roles throughout the process.

Attribute#

characteristics related to a subject.

Access Token#

Is a data artifact representing a set of rights and/or attributes.

Note: an Access Token can be first issued to a client instance (requiring authorization by the Resource Owner) and subsequently rotated.

Grant #

(verb): to permit an instance of client software to receive some attributes at a specific time and valid for a specific duration and/or to exercise some set of delegated rights to access a protected resource (noun): the act of granting.
LDAPWiki this appears to be they are providing Authorization to something (a Protected Resource) that was requested.

Privilege#

right or attribute associated with a subject.
LDAPWiki would call this a Permission. Fail to see how an attribute could ever be a "Privilege" Even though a Privilege could be expressed as an Attribute.

Note: the Resource Owner defines and maintains the rights and attributes associated to the protected resource, and might temporarily delegate some set of those privileges to an end-user. This process is referred to as privilege delegation.

Protected Resource#

protected API (Application Programming Interface) served by an Resource Server and that can be accessed by a client, if and only if a valid Access Token is provided.

Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource.

Right#

ability given to a subject to perform a given operation on a resource under the control of an Resource Server.
LDAPWiki would call this an Permission but it is unclear the difference in their usage of RIGHT vs Privilege

Subject#

person, organization or device. (LDAPWiki: sounds like an entity)

Subject Information#

statement asserted locally by an Authorization Server about a subject.

More Information#

There might be more information for this subject on one of the following:

Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!