This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 122 lines
!!! Overview
[{$pagename}] ([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|Delegation] [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|Grant Types] 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|https://gnap-core-protocol-editors-draft.netlify.app/draft-ietf-gnap-core-protocol.html#example-oauth2|target='_blank'].
!! 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.
%%information
[{$applicationname}] this appears to be they are providing [Authorization] to something (a [Protected Resource]) that was requested.
%%
! [Privilege]
right or [attribute] associated with a [subject].
%%information
[{$applicationname}] 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|Resource Action] on a [resource] under the control of an [Resource Server].
%%information
[{$applicationname}] would call this an [Permission] but it is unclear the difference in their usage of RIGHT vs [Privilege]
%%
! [Subject]
[person], [organization|Organizational Entity] or [device]. ([{$applicationname}]: 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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Grant Negotiation and Authorization Protocol|https://gnap-core-protocol-editors-draft.netlify.app/draft-ietf-gnap-core-protocol.html|target='_blank'] - based on information obtained 2021-02-19