1.1.Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URIs, query components, keys, and other elements. Whenever possible, the document uses URI as a generic term, since it aligns with the recommendations in[RFC3986] and better matches the intent that the identifier may be reachable through various/generic means (compared to URLs). Some examples use a single trailing backslash (\) to indicate line wrapping for long values, as per[RFC8792]. The\ character and leading spaces on wrapped lines are not part of the value.¶

This document uses the term "mutual TLS" as defined by[RFC8705]. The shortened form "MTLS" is used to mean the same thing.¶

For brevity, the term "signature" on its own is used in this document to refer to both digital signatures (which use asymmetric cryptography) and keyed Message Authentication Codes (MACs) (which use symmetric cryptography). Similarly, the verb "sign" refers to the generation of either a digital signature or a keyed MAC over a given signature base. The qualified term "digital signature" refers specifically to the output of an asymmetric cryptographic signing operation.¶

1.2.Roles

The parties in GNAP perform actions under different roles.Roles are defined by the actions taken and the expectations leveragedon 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 access tokens or other information (such as subject information). The AS is uniquely defined by the grant endpoint URI, which is the absolute URI where grant requests are started by clients.¶

Client:

Application that consumes resources from one or several resource servers, possibly requiring access privileges from one or several ASes. The client is operated by the end user, or it runs autonomously on behalf of a resource owner.¶

For example, a client can be a mobile application, a web application, a backend data processor, 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):

Server that provides an API on protected resources, where operations on the API require a valid access token issued by a trusted AS.¶

Resource Owner (RO):

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:

Natural person that operates a client instance.¶

Note: That natural person may or may not be the same entity as the RO.¶

The design of GNAP does not assume any one deployment architecturebut instead attempts to define roles that can be fulfilled in a numberof different ways for different use cases. As long as a given role fulfillsall of its obligations and behaviors as defined by the protocol, GNAP doesnot make additional requirements on its structure or setup.¶

Multiple roles can be fulfilled by the same party, and a given partycan switch roles in different instances of the protocol. For example, in many instances,the RO and end user are the same person, where a userauthorizes the client instance to act on their own behalf at the RS. In this case,one party fulfills the roles of both RO and end user, but the roles themselvesare still defined separately from each other to allow for otheruse cases where they are fulfilled by different parties.¶

As another example,in some complex scenarios, an RS receiving requests from one client instance can act asa client instance for a downstream secondary RS in order to fulfill theoriginal request. In this case, one piece of software is both anRS and a client instance from different perspectives, and it fulfills theseroles separately as far as the overall protocol is concerned.¶

A single role need not be deployed as a monolithic service. For example,a client instance could have frontend components that are installed on the end user's device aswell as a backend system that the frontend communicates with. If both of thesecomponents participate in the delegation protocol, they are both consideredpart of the client instance. If there are several copies of the client softwarethat run separately but all share the same key material, such as adeployed cluster, then this cluster is considered a single client instance.In these cases, the distinct components of what is considered a GNAP client instancemay use any number of different communication mechanisms between them, all of whichwould be considered an implementation detail of the client instances and out of scope of GNAP.¶

As another example, an AS could likewise be built out of many constituentcomponents in a distributed architecture. The component that the client instancecalls directly could be different from the component that theRO interacts with to drive consent, since API calls and user interactionhave different security considerations in many environments. Furthermore,the AS could need to collect identity claims about the RO from one systemthat deals with user attributes while generating access tokens atanother system that deals with security rights. From the perspective ofGNAP, all of these are pieces of the AS and together fulfill therole of the AS as defined by the protocol. These pieces may have their own internalcommunications mechanisms, which are considered out of scope of GNAP.¶

1.3.Elements

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

Access Token:

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 RO) and subsequently rotated.¶

Grant:

(verb): To permit an instance of client software to receive some attributes at a specific time and with a specific duration of validity and/or to exercise some set of delegated rights to access a protected resource.¶

(noun): The act of granting permission to a client instance.¶

Privilege:

Right or attribute associated with a subject.¶

Note: The RO 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 that is served by an RS and that can be accessed by a client, if and only if a valid and sufficient 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 RS.¶

Subject:

Person or organization. The subject decides whether and under which conditions its attributes can be disclosed to other parties.¶

Subject Information:

Set of statements and attributes asserted by an AS about a subject. These statements can be used by the client instance as part of an authentication decision.¶

1.4.Trust Relationships

GNAP defines its trust objective as follows: the RO trusts the AS to ensure access validation and delegation of protected resources to end users, through third party clients.¶

This trust objective can be decomposed into trust relationships between software elements and roles, especially the pairs end user/RO, end user/client, client/AS, RS/RO, AS/RO, and AS/RS. Trust of an agent by its pair can exist if the pair is informed that the agent has made a promise to follow the protocol in the past (e.g., pre-registration and uncompromised cryptographic components) or if the pair is able to infer by indirect means that the agent has made such a promise (e.g., a compliant client request). Each agent defines its own valuation function of promises given or received. Examples of such valuations can be the benefits from interacting with other agents (e.g., safety in client access and interoperability with identity standards), the cost of following the protocol (including its security and privacy requirements and recommendations), a ranking of promise importance (e.g., a policy decision made by the AS), the assessment of one's vulnerability or risk of not being able to defend against threats, etc. Those valuations may depend on the context of the request. For instance, depending on the specific case in which GNAP is used, the AS may decide to either take into account or discard hints provided by the client, or the RS may refuse bearer tokens. Some promises can be affected by previous interactions (e.g., repeated requests).¶

Below are details of each trust relationship:¶

end user/RO:

This relationship exists only when the end user and the RO are different, in which case the end user needs some out-of-band mechanism of getting the RO consent (seeSection 4). GNAP generally assumes that humans can be authenticated, thanks to identity protocols (for instance, through an id_token assertion as described inSection 2.2).¶

end user/client:

The client acts as a user agent. Depending on the technology used (browser, single-page application (SPA), mobile application, Internet of Things (IoT) device, etc.), some interactions may or may not be possible (as described inSection 2.5.1). Client developers implement requirements and generally some recommendations or best practices, so that the end users may confidently use their software. However, end users might also face an attacker's client software or a poorly implemented client without even realizing it.¶

end user/AS:

When the client supports the interaction feature (seeSection 3.3), the end user interacts with the AS through an AS-provided interface. In many cases, this happens through a front-channel interaction through the end user's browser. SeeSection 11.29 for some considerations in trusting these interactions.¶

client/AS:

An honest AS may face an attacker's client (as discussed just above), or the reverse, and GNAP aims to make common attacks impractical. This specification makes access tokens opaque to the client and defines the request/response scheme in detail, therefore avoiding extra trust hypotheses from this critical piece of software. Yet, the AS may further define cryptographic attestations or optional rules to simplify the access of clients it already trusts, due to past behavior or organizational policies (seeSection 2.3).¶

RS/RO:

On behalf of the RO, the RS promises to protect its resources from unauthorized access and only accepts valid access tokens issued by a trusted AS. In case tokens are key bound, proper validation of the proofing method is expected from the RS.¶

AS/RO:

The AS is expected to follow the decisions made by the RO, through either interactive consent requests, repeated interactions, or automated rules (as described inSection 1.6). Privacy considerations aim to reduce the risk of an honest but too-curious AS or the consequences of an unexpected user data exposure.¶

AS/RS:

The AS promises to issue valid access tokens to legitimate client requests (i.e., after carrying out appropriate due diligence, as defined in the GNAP). Some optional configurations are covered by[GNAP-RS].¶

A global assumption made by GNAP is that authorization requests are security and privacy sensitive, and appropriate measures are detailed in Sections11 and12, respectively.¶

A formal trust model is out of scope of this specification, but one could be developed using techniques such as the Promise Theory[promise-theory].¶

1.5.Protocol Flow

GNAP is fundamentally designed to allow delegated access to APIs and other information, such as subject information, using a multi-stage, stateful process. This process allows different parties to provide information into the system to alter and augment the state of the delegated access and its artifacts.¶

The underlying requested grant moves through several states as different actions take place during the protocol, as shown inFigure 2.¶

The state of the grant request is defined and managed by the AS, though the client instance also needs to manage its view of the grant request over time. The means by which these roles manage their state are outside the scope of this specification.¶

Processing:

When a request for access (Section 2) is received by the AS, a new grant request is created and placed in theprocessing state by the AS. This state is also entered when an existing grant request is updated by the client instance and when interaction is completed. In this state, the AS processes the context of the grant request to determine whether interaction with the end user or RO is required for approval of the request. The grant request has to exit this state before a response can be returned to the client instance. If approval is required, the request moves to thepending state, and the AS returns a continuation response (Section 3.1) along with any appropriate interaction responses (Section 3.3). If no such approval is required, such as when the client instance is acting on its own behalf or the AS can determine that access has been fulfilled, the request moves to theapproved state where access tokens for API access (Section 3.2) and subject information (Section 3.4) can be issued to the client instance. If the AS determines that no additional processing can occur (such as a timeout or an unrecoverable error), the grant request is moved to thefinalized state and is terminated.¶

Pending:

When a request needs to be approved by an RO, or interaction with the end user is required, the grant request enters a state ofpending. In this state, no access tokens can be granted, and no subject information can be released to the client instance. While a grant request is in this state, the AS seeks to gather the required consent and authorization (Section 4) for the requested access. A grant request in this state is always associated with a continuation access token bound to the client instance's key (seeSection 3.1 for details of the continuation access token). If no interaction finish method (Section 2.5.2) is associated with this request, the client instance can send a polling continuation request (Section 5.2) to the AS. This returns a continuation response (Section 3.1) while the grant request remains in this state, allowing the client instance to continue to check the state of the pending grant request. If an interaction finish method (Section 2.5.2) is specified in the grant request, the client instance can continue the request after interaction (Section 5.1) to the AS to move this request to theprocessing state to be re-evaluated by the AS. Note that this occurs whether the grant request has been approved or denied by the RO, since the AS needs to take into account the full context of the request before determining the next step for the grant request. When other information is made available in the context of the grant request, such as through the asynchronous actions of the RO, the AS moves this request to theprocessing state to be re-evaluated. If the AS determines that no additional interaction can occur, e.g., all the interaction methods have timed out or a revocation request (Section 5.4) is received from the client instance, the grant request can be moved to thefinalized state.¶

Approved:

When a request has been approved by an RO and no further interaction with the end user is required, the grant request enters a state ofapproved. In this state, responses to the client instance can include access tokens for API access (Section 3.2) and subject information (Section 3.4). If continuation and updates are allowed for this grant request, the AS can include the continuation response (Section 3.1). In this state, post-interaction continuation requests (Section 5.1) are not allowed and will result in an error, since all interaction is assumed to have been completed. If the client instance sends a polling continuation request (Section 5.2) while the request is in this state, new access tokens (Section 3.2) can be issued in the response. Note that this always creates a new access token, but any existing access tokens could be rotated and revoked using the token management API (Section 6). The client instance can send an update continuation request (Section 5.3) to modify the requested access, causing the AS to move the request back to theprocessing state for re-evaluation. If the AS determines that no additional tokens can be issued and that no additional updates are to be accepted (e.g., the continuation access tokens have expired), the grant is moved to thefinalized state.¶

Finalized:

After the access tokens are issued, if the AS does not allow any additional updates on the grant request, the grant request enters thefinalized state. This state is also entered when an existing grant request is revoked by the client instance (Section 5.4) or otherwise revoked by the AS (such as through out-of-band action by the RO). This state can also be entered if the AS determines that no additional processing is possible, for example, if the RO has denied the requested access or if interaction is required but no compatible interaction methods are available. Once in this state, no new access tokens can be issued, no subject information can be returned, and no interactions can take place. Once in this state, the grant request is dead and cannot be revived. If future access is desired by the client instance, a new grant request can be created, unrelated to this grant request.¶

While it is possible to deploy an AS in a stateless environment, GNAP is a stateful protocol, and such deployments will need a way to manage the current state of the grant request in a secure and deterministic fashion without relying on other components, such as the client software, to keep track of the current state.¶

1.6.Sequences

GNAP can be used in a variety of ways to allow the coredelegation process to take place. Many portions of this process areconditionally present depending on the context of the deployments,and not every step in this overview will happen in all circumstances.¶

Note that a connection between roles in this process does not necessarilyindicate that a specific protocol message is sent across the wirebetween the components fulfilling the roles in question or that aparticular step is required every time. For example, for a client instance interestedin only getting subject information directly and not calling an RS,all steps involving the RS below do not apply.¶

In some circumstances,the information needed at a given stage is communicated out of bandor is pre-configured between the components or entities performingthe roles. For example, one entity can fulfill multiple roles, soexplicit communication between the roles is not necessary within theprotocol flow. Additionally, some components may not be involvedin all use cases. For example, a client instance could be calling theAS just to get direct user information and have no need to getan access token to call an RS.¶

2.1.Requesting Access to Resources

If the client instance is requesting one or more access tokens for thepurpose of accessing an API, the client instanceMUST include anaccess_tokenfield. This fieldMUST be an object (for a single access token (Section 2.1.1)) oran array of these objects (for multiple access tokens (Section 2.1.2)),as described in the following subsections.¶

"access_token": {    "access": [        {            "type": "photo-api",            "actions": [                "read",                "write",                "delete"            ],            "locations": [                "https://server.example.net/",                "https://resource.local/other"            ],            "datatypes": [                "metadata",                "images"            ]        },        {            "type": "walrus-access",            "actions": [                "foo",                "bar"            ],            "locations": [                "https://resource.other/"            ],            "datatypes": [                "data",                "pictures",                "walrus whiskers"            ]        }    ],    "label": "token1-23"}

"access_token": [    {        "label": "token1",        "access": [            {                "type": "photo-api",                "actions": [                    "read",                    "write",                    "dolphin"                ],                "locations": [                    "https://server.example.net/",                    "https://resource.local/other"                ],                "datatypes": [                    "metadata",                    "images"                ]            },            "dolphin-metadata"        ]    },    {        "label": "token2",        "access": [            {                "type": "walrus-access",                "actions": [                    "foo",                    "bar"                ],                "locations": [                    "https://resource.other/"                ],                "datatypes": [                    "data",                    "pictures",                    "walrus whiskers"                ]            }        ],        "flags": [ "bearer" ]    }]

2.2.Requesting Subject Information

If the client instance is requesting information about the RO fromthe AS, it sends asubject field as a JSON object. This objectMAYcontain the following fields.¶

sub_id_formats (array of strings):

An array of Subject Identifier subject formats requested for the RO, as defined by[RFC9493].REQUIRED if Subject Identifiers are requested.¶

assertion_formats (array of strings):

An array of requested assertion formats. Possible values includeid_token for an OpenID Connect ID Token[OIDC] andsaml2 for a Security Assertion Markup Language (SAML) 2 assertion[SAML2]. Additional assertion formats can be defined in the "GNAP Assertion Formats" registry (Section 10.6).REQUIRED if assertions are requested.¶

sub_ids (array of objects):

An array of Subject Identifiers representing the subject for which information is being requested. Each object is a Subject Identifier as defined by[RFC9493]. All identifiers in thesub_ids arrayMUST identify the same subject. If omitted, the ASSHOULD assume that subject information requests are about the current user andSHOULD require direct interaction or proof of presence before releasing information.OPTIONAL.¶

Additional fields can be defined in the "GNAP Subject Information Request Fields" registry (Section 10.5).¶

"subject": {  "sub_id_formats": [ "iss_sub", "opaque" ],  "assertion_formats": [ "id_token", "saml2" ]}

The AS can determine the RO's identity and permission for releasingthis information through interaction with the RO (Section 4),AS policies, or assertions presented by the client instance (Section 2.4). Ifthis is determined positively, the ASMAY return the RO's information in its response (Section 3.4)as requested.¶

Subject Identifier types requested by the client instance serve only to identifythe RO in the context of the AS and can't be used as communicationchannels by the client instance, as discussed inSection 3.4.¶

2.3.Identifying the Client Instance

When sending a new grant request to the AS, the client instanceMUST identifyitself by including its client information in theclient field of the request and by signing therequest with its unique key as described inSection 7.3. Note that once agrant has been created and is in either thepending or theapproved state, the AS candetermine which client is associated with the grant by dereferencing thecontinuation access token sent in the continuation request (Section 5).As a consequence, theclient field is not sent or accepted for continuation requests.¶

Client information is sent by value as an object or by reference as a string (seeSection 2.3.1).¶

When client instance information is sentby value, theclient field of the request consists of a JSONobject with the following fields.¶

key (object / string):

The public key of the client instance to be used in this request as described inSection 7.1 or a reference to a key as described inSection 7.1.1.REQUIRED.¶

class_id (string):

An identifier string that the AS can use to identify the client software comprising this client instance. The contents and format of this field are up to the AS.OPTIONAL.¶

display (object):

An object containing additional information that the ASMAY display to the RO during interaction, authorization, and management.OPTIONAL. SeeSection 2.3.2.¶

"client": {    "key": {        "proof": "httpsig",        "jwk": {            "kty": "RSA",            "e": "AQAB",            "kid": "xyz-1",            "alg": "RS256",            "n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8..."        }    },    "class_id": "web-server-1234",    "display": {        "name": "My Client Display Name",        "uri": "https://example.net/client"    }}

Additional fields can be defined in the "GNAP Client Instance Fields" registry (Section 10.7).¶

Absent additional attestations, profiles, or trust mechanisms, both thedisplay andclass_id fields are self-declarative, presented by the client instance. The AS needs to exercise caution in their interpretation, taking them as a hint but not as absolute truth. Theclass_id field can be used in a variety of ways to help the AS make sense of the particular context in which the client instance is operating. In corporate environments, for example, different levels of trust might apply depending on security policies. This field aims to help the AS adjust its own access decisions for different classes of client software. It is possible to configure a set of values and rules during a pre-registration and then have the client instances provide them later in runtime as a hint to the AS. In other cases, the client runs with a specific AS in mind, so a single hardcoded value would be acceptable (for instance, a set-top box with aclass_id claiming to be "FooBarTV version 4"). While the client instance may not have contacted the AS yet, the value of thisclass_id field can be evaluated by the AS according to a broader context of dynamic use, alongside other related information available elsewhere (for instance, corresponding fields in a certificate). If the AS is not able to interpret or validate the class_id field, itMUST either return aninvalid_client error (Section 3.6) or interpret the request as if the class_id were not present. See additional discussion of client instance impersonation inSection 11.15.¶

The client instanceMUST prove possession of any presented key by the proofing mechanismassociated with the key in the request. Key proofing methodsare defined in the "GNAP Key Proofing Methods" registry (Section 10.16), and an initial set of methodsis described inSection 7.3.¶

If the same public key is sent by value on different access requests, the ASMUSTtreat these requests as coming from the same client instance for purposesof identification, authentication, and policy application.¶

If the AS does not know the client instance's public key ahead of time, the AScan choose how to process the unknown key. Common approaches include:¶

• Allowing the request and requiring RO authorization in a trust-on-first-use model¶

• Limiting the client's requested access to only certain APIs and information¶

• Denying the request entirely by returning aninvalid_client error (Section 3.6)¶

The client instanceMUST NOT send a symmetric key by value in thekey field of the request, as doing so would exposethe key directly instead of simply proving possession of it. See considerations on symmetric keysinSection 11.7. To use symmetric keys, the client instance can send thekey by reference (Section 7.1.1) orsend the entire client identity by reference (Section 2.3.1).¶

The client instance's key can be pre-registered with the AS ahead of time and associatedwith a set of policies and allowable actions pertaining to that client. If this pre-registrationincludes other fields that can occur in theclient request object described in this section,such asclass_id ordisplay, the pre-registered valuesMUST take precedence over any valuesgiven at runtime. Additional fields sent during a request but not present in a pre-registeredclient instance record at the ASSHOULD NOT be added to the client's pre-registered record.See additional considerations regarding client instance impersonation inSection 11.15.¶

A client instance that is capable of talking to multiple ASesSHOULD use a different key for eachAS to prevent a class of mix-up attacks as described inSection 11.31, unless other mechanismscan be used to assure the identity of the AS for a given request.¶

"client": "client-541-ab"

"display": {    "name": "My Client Display Name",    "uri": "https://example.net/client",    "logo_uri": "data:image/png;base64,Eeww...="}

2.4.Identifying the User

If the client instance knows the identity of the end user through one or moreidentifiers or assertions, the client instanceMAY send that information to theAS in theuser field. The client instanceMAY pass this information by valueor by reference (seeSection 2.4.1).¶

sub_ids (array of objects):

An array of Subject Identifiers for the end user, as defined by[RFC9493].OPTIONAL.¶

assertions (array of objects):

An array containing assertions as objects, each containing the assertion format and the assertion value as the JSON string serialization of the assertion, as defined inSection 3.4.OPTIONAL.¶

"user": {  "sub_ids": [ {    "format": "opaque",    "id": "J2G8G8O4AZ"  } ],  "assertions": [ {    "format": "id_token",    "value": "eyj..."  } ]}

Subject Identifiers are hints to the AS in determining theRO andMUST NOT be taken as authoritative statements that a particularRO is present at the client instance and acting as the end user.¶

Assertions presented by the client instanceSHOULD be validated by the AS. While the details ofsuch validation are outside the scope of this specification, common validation steps includeverifying the signature of the assertion against a trusted signing key, verifying the audienceand issuer of the assertion map to expected values, and verifying the time window for theassertion itself. However, note that in many use cases, some of these common steps are relaxed.For example, an AS acting as an identity provider (IdP) could expect that assertions being presented using thismechanism were issued by the AS to the client software. The AS would verify that the AS is theissuer of the assertion, not the audience, and that the client instance is instead the audience ofthe assertion. Similarly, an AS might accept a recently expired assertion in order to helpbootstrap a new session with a specific end user.¶

If the identified end user does not match the RO present at the ASduring an interaction step and the AS is not explicitly allowing a cross-userauthorization, the ASSHOULD reject the request with anunknown_user error (Section 3.6).¶

If the AS trusts the client instance to present verifiable assertions or known Subject Identifiers,such as an opaque identifier issued by the AS for this specific client instance, the ASMAYdecide, based on its policy, to skip interaction with the RO, evenif the client instance provides one or more interaction modes in its request.¶

SeeSection 11.30 for considerations for the AS when accepting andprocessing assertions from the client instance.¶

"user": "XUT2MFM1XBIKJKSDU8QM"

2.5.Interacting with the User

Often, the AS will require interaction with the RO (Section 4) in order toapprove a requested delegation to the client instance for both access to resources and directsubject information. Many times, the end user using the client instance is the same person asthe RO, and the client instance can directly drive interaction with the end user by facilitatingthe process through means such as redirection to a URI or launching an application. Other times, theclient instance can provide information to start the RO's interaction on a secondarydevice, or the client instance will wait for the RO to approve the request asynchronously.The client instance could also be signaled that interaction has concluded through acallback mechanism.¶

The client instance declares the parameters for interaction methods that it can supportusing theinteract field.¶

Theinteract field is a JSON object with three keys whose values declare how the client can initiateand complete the request, as well as provide hints to the AS about user preferences such as locale.A client instanceMUST NOT declare an interaction mode it does not support.The client instanceMAY send multiple modes in the same request.There is no preference order specified in this request. An ASMAY respond to any, all, or none of the presented interaction modes (Section 3.3) in a request, depending onits capabilities and what is allowed to fulfill the request.¶

start (array of objects/strings):

Indicates how the client instance can start an interaction.REQUIRED. SeeSection 2.5.1.¶

finish (object):

Indicates how the client instance can receive an indication that interaction has finished at the AS.OPTIONAL. SeeSection 2.5.2.¶

hints (object):

Provides additional information to inform the interaction process at the AS.OPTIONAL. SeeSection 2.5.3.¶

In the following non-normative example, the client instance is indicating that it can redirect (Section 2.5.1.1)the end user to an arbitrary URI and can receive a redirect (Section 2.5.2.1) througha browser request. Note that the client instance does not accept a push-style callback.The pattern of using a redirect for both interaction start and finish is common for web-based client software.¶

"interact": {    "start": ["redirect"],    "finish": {        "method": "redirect",        "uri": "https://client.example.net/return/123455",        "nonce": "LKLTI25DK82FX4T4QFZC"    }}

In the following non-normative example, the client instance is indicating that it candisplay a user code (Section 2.5.1.3) and direct the end userto an arbitrary URI (Section 2.5.1.1), but it cannot accept a redirect or push-style callback.This pattern is common for devices that have robust display capabilities but expectthe use of a secondary device to facilitate end-user interaction with the AS, suchas a set-top box capable of displaying an interaction URL as a QR code.¶

"interact": {    "start": ["redirect", "user_code"]}

In the following non-normative example, the client instance is indicating that it cannot start any interaction with the end user but that the AS canpush an interaction finish message (Section 2.5.2.2) whenauthorization from the RO is received asynchronously. This pattern iscommon for scenarios where a service needs to be authorized, but the RO isable to be contacted separately from the GNAP transaction itself, such as through a pushnotification or existing interactive session on a secondary device.¶

"interact": {    "start": [],    "finish": {        "method": "push",        "uri": "https://client.example.net/return/123455",        "nonce": "LKLTI25DK82FX4T4QFZC"    }}

If all of the following conditions are true, the ASMUST return aninvalid_interaction error (Section 3.6) since the client instance will be unable to complete the request without authorization:¶

• The client instance does not provide a suitable interaction mechanism.¶
• The AS cannot contact the RO asynchronously.¶
• The AS determines that interaction is required.¶

"interact": {  "start": ["redirect"]}

"interact": {  "start": ["app"]}

"interact": {    "start": ["user_code"]}

"interact": {    "start": ["user_code_uri"]}

"interact": {    "finish": {        "method": "redirect",        "uri": "https://client.example.net/return/123455",        "nonce": "LKLTI25DK82FX4T4QFZC"    }}

"interact": {    "finish": {        "method": "push",        "uri": "https://client.example.net/return/123455",        "nonce": "LKLTI25DK82FX4T4QFZC"    }}

"interact": {    "hints": {        "ui_locales": ["en-US", "fr-CA"]    }}

3.1.Request Continuation

If the AS determines that the grant request can be continued by theclient instance, the AS responds with thecontinue field. This fieldcontains a JSON object with the following properties.¶

uri (string):

The URI at which the client instance can make continuation requests. This URIMAY vary per request orMAY be stable at the AS. This URIMUST be an absolute URI. The client instanceMUST use this value exactly as given when making a continuation request (Section 5).REQUIRED.¶

wait (integer):

The amount of time in integer seconds the client instanceMUST wait after receiving this request continuation response and calling the continuation URI. The valueSHOULD NOT be less than five seconds, and omission of the valueMUST be interpreted as five seconds.RECOMMENDED.¶

access_token (object):

A unique access token for continuing the request, called the "continuation access token". The value of this propertyMUST be an object in the format specified inSection 3.2.1. This access tokenMUST be bound to the client instance's key used in the request andMUST NOT be a bearer token. As a consequence, theflags array of this access tokenMUST NOT contain the stringbearer, and thekey fieldMUST be omitted. This access tokenMUST NOT have amanage field. The client instanceMUST present the continuation access token in all requests to the continuation URI as described inSection 7.2.REQUIRED.¶

{    "continue": {        "access_token": {            "value": "80UPRY5NM33OMUKMKSKU"        },        "uri": "https://server.example.com/continue",        "wait": 60    }}

This field isREQUIRED if the grant request is in thepending state, asthe field contains the information needed by the client request to continue therequest as described inSection 5. Note that thecontinuation access token is bound to the client instance's key; therefore, theclient instanceMUST sign all continuation requests with its key as describedinSection 7.3 andMUST present the continuation access token in its continuation request.¶

3.2.Access Tokens

If the AS has successfully granted one or more access tokens to the client instance,the AS responds with theaccess_token field. This field contains either a singleaccess token as described inSection 3.2.1 or an array of access tokensas described inSection 3.2.2.¶

The client instance uses any access tokens in this response to call the RS asdescribed inSection 7.2.¶

The grant requestMUST be in theapproved state to include this field in the response.¶

NOTE: '\' line wrapping per RFC 8792"access_token": {    "value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",    "manage": {        "uri": "https://server.example.com/token/PRY5NM33O",        "access_token": {            "value": "B8CDFONP21-4TB8N6.BW7ONM"        }    },    "access": [        {            "type": "photo-api",            "actions": [                "read",                "write",                "dolphin"            ],            "locations": [                "https://server.example.net/",                "https://resource.local/other"            ],            "datatypes": [                "metadata",                "images"            ]        },        "read", "dolphin-metadata"    ]}

"access_token": {    "value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",    "flags": ["bearer"],    "access": [        "finance", "medical"    ]}

NOTE: '\' line wrapping per RFC 8792"access_token": [    {        "label": "token1",        "value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",        "manage": {            "uri": "https://server.example.com/token/PRY5NM33O",            "access_token": {                "value": "B8CDFONP21-4TB8N6.BW7ONM"            }        },        "access": [ "finance" ]    },    {        "label": "token2",        "value": "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",        "access": [ "medical" ]    }}

"access_token": [    {        "label": "token2",        "value": "8N6BW7OZB8CDFONP219-OS9M2PMHKUR64TBRP1LT0",        "manage": {            "uri": "https://server.example.com/token/PRY5NM33O",            "access_token": {                "value": "B8CDFONP21-4TB8N6.BW7ONM"            }        },        "access": [ "fruits" ]    }]

3.3.Interaction Modes

If the client instance has indicated a capability to interact with the RO in its request (Section 2.5)and the AS has determined that interaction is bothsupported and necessary, the AS responds to the client instance with any of thefollowing values in theinteract field of the response. There isno preference order for interaction modes in the response,and it is up to the client instance to determine which ones to use. All supportedinteraction methods are included in the sameinteract object.¶

redirect (string):

Redirect to an arbitrary URI.REQUIRED if theredirect interaction start mode is possible for this request. SeeSection 3.3.1.¶

app (string):

Launch of an application URI.REQUIRED if theapp interaction start mode is possible for this request. SeeSection 3.3.2.¶

user_code (string):

Display a short user code.REQUIRED if theuser_code interaction start mode is possible for this request. SeeSection 3.3.3.¶

user_code_uri (object):

Display a short user code and URI.REQUIRED if theuser_code_uri interaction start mode is possible for this request.Section 3.3.4¶

finish (string):

A unique ASCII string value provided by the AS as a nonce. This is used by the client instance to verify the callback after interaction is completed.REQUIRED if the interaction finish method requested by the client instance is possible for this request. SeeSection 3.3.5.¶

expires_in (integer):

The number of integer seconds after which this set of interaction responses will expire and no longer be usable by the client instance. If the interaction methods expire, the clientMAY restart the interaction process for this grant request by sending an update (Section 5.3) with a new interaction request field (Section 2.5).OPTIONAL. If omitted, the interaction response modes returned do not expire butMAY be invalidated by the AS at any time.¶

Additional interaction mode responses can be defined in the "GNAP Interaction Mode Responses" registry (Section 10.13).¶

The ASMUST NOT respond with any interaction mode that theclient instance did not indicate in its request, and the ASMUST NOT respond withany interaction mode that the AS does not support. Since interactionresponses include secret or unique information, the ASSHOULDrespond to each interaction mode only once in an ongoing request,particularly if the client instance modifies its request (Section 5.3).¶

The grant requestMUST be in thepending state to include this field in the response.¶

"interact": {    "redirect": "https://interact.example.com/4CF492MLVMSW9MKMXKHQ"}

"interact": {    "app": "https://app.example.com/launch?tx=4CF492MLV"}

"interact": {    "user_code": "A1BC3DFF"}

"interact": {    "user_code_uri": {        "code": "A1BC3DFF",        "uri": "https://s.example/device"    }}

"interact": {    "finish": "MBDOFXG4Y5CVJCX821LH"}

3.4.Returning Subject Information

If information about the RO is requested and the ASgrants the client instance access to that data, the AS returns the approvedinformation in the "subject" response field. The ASMUST return thesubject field only in cases where the AS is sure thatthe RO and the end user are the same party. This can be accomplished through some forms ofinteraction with the RO (Section 4).¶

This field is an object with the following properties.¶

sub_ids (array of objects):

An array of Subject Identifiers for the RO, as defined by[RFC9493].REQUIRED if returning Subject Identifiers.¶

assertions (array of objects):

An array containing assertions as objects, each containing the assertion object described below.REQUIRED if returning assertions.¶

updated_at (string):

Timestamp as a date string as described in[RFC3339], indicating when the identified account was last updated. The client instanceMAY use this value to determine if it needs to request updated profile information through an identity API. The definition of such an identity API is out of scope for this specification.RECOMMENDED.¶

Assertion objects contain the following fields:¶

format (string):

The assertion format. Possible formats are listed inSection 3.4.1. Additional assertion formats can be defined in the "GNAP Assertion Formats" registry (Section 10.6).REQUIRED.¶

value (string):

The assertion value as the JSON string serialization of the assertion.REQUIRED.¶

The following non-normative example contains an opaque identifier and an OpenID Connect ID Token:¶

"subject": {  "sub_ids": [ {    "format": "opaque",    "id": "XUT2MFM1XBIKJKSDU8QM"  } ],  "assertions": [ {    "format": "id_token",    "value": "eyj..."  } ]}

Subject Identifiers returned by the ASSHOULD uniquely identify the RO at theAS. Some forms of Subject Identifiers are opaque to the client instance (such as the subject of anissuer and subject pair), while other forms (such as email address and phone number) areintended to allow the client instance to correlate the identifier with other account informationat the client instance. The client instanceMUST NOT request or use any returned Subject Identifiers for communicationpurposes (seeSection 2.2). That is, a Subject Identifier returned in the format of an email address ora phone number only identifies the RO to the AS and does not indicate that theAS has validated that the represented email address or phone number in the identifieris suitable for communication with the current user. To get such information,the client instanceMUST use an identity protocol to request and receive additional identityclaims. The details of an identity protocol and associated schemaare outside the scope of this specification.¶

The ASMUST ensure that the returned subject information represents the RO. In most cases,the AS will also ensure that the returned subject information represents the end user authenticatedinteractively at the AS.The ASSHOULD NOT reuse Subject Identifiers for multiple different ROs.¶

The "sub_ids" and "assertions" response fields are independent of each other. That is, areturned assertionMAY use a different Subject Identifier than other assertions andSubject Identifiers in the response. However, all Subject Identifiers and assertions returnedMUST refer to the same party.¶

The client instanceMUST interpret all subject information in the context of the AS from which thesubject information is received, as is discussed in Section 6 of[SP80063C]. For example, one AS couldreturn an email identifier of "user@example.com" for one RO, and a different AS could return thatsame email identifier of "user@example.com" for a completely different RO. A client instance talking toboth ASes needs to differentiate between these two accounts by accounting for the AS sourceof each identifier and not assuming that either has a canonical claim on the identifier withoutadditional configuration and trust agreements. Otherwise, a rogue AS could exploit this totake over a targeted account asserted by a different AS.¶

Extensions to this specificationMAY define additional responseproperties in the "GNAP Subject Information Response Fields" registry (Section 10.14).¶

The grant requestMUST be in theapproved state to return this field in the response.¶

SeeSection 11.30 for considerations that the client instance has to make when acceptingand processing assertions from the AS.¶

3.5.Returning a Dynamically Bound Client Instance Identifier

Many parts of the client instance's request can be passed as either a valueor a reference. The use of a reference in place of a value allowsfor a client instance to optimize requests to the AS.¶

Some references, such as for the client instance's identity (Section 2.3.1)or the requested resources (Section 8.1), can be managed statically through anadmin console or developer portal provided by the AS or RS. The developerof the client software can include these values in their code for a moreefficient and compact request.¶

If desired, the ASMAY also generate and return an instance identifierdynamically to the client instance in the response to facilitate multipleinteractions with the same client instance over time. The client instanceSHOULD use thisinstance identifier in future requests in lieu of sending the associated datavalues in theclient field.¶

Dynamically generated client instance identifiers are string values thatMUST beprotected by the client instance as secrets. Instance identifier valuesMUST be unguessableandMUST NOT contain any information that would compromise any party if revealed. Instance identifier values areopaque to the client instance, and their content is determined by the AS. The instanceidentifierMUST be unique per client instance at the AS.¶

instance_id (string):

A string value used to represent the information in theclient object that the client instance can use in a future request, as described inSection 2.3.1.OPTIONAL.¶

The following non-normative example shows an instance identifier alongside an issued access token.¶

{    "instance_id": "7C7C4AZ9KHRS6X63AJAO",    "access_token": {        "value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0"    }}

3.6.Error Response

If the AS determines that the request cannot be completed for any reason, it responds to the client instance with anerror field in the response message. This field is either an object or a string.¶

When returned as an object, the object contains the following fields:¶

code (string):

A single ASCII error code defining the error.The valueMUST be defined in the "GNAP Error Codes" registry (Section 10.15).REQUIRED.¶

description (string):

A human-readable string description of the error intended for thedeveloper of the client. The value is chosen by the implementation.OPTIONAL.¶

This specification defines the followingcode values:¶

"invalid_request":

The request is missing a required parameter, includes an invalid parameter value, or is otherwise malformed.¶

"invalid_client":

The request was made from a client that was not recognized or allowed by the AS, or the client's signature validation failed.¶

"invalid_interaction":

The client instance has provided an interaction reference that is incorrect for this request, or the interaction modes in use have expired.¶

"invalid_flag":

The flag configuration is not valid.¶

"invalid_rotation":

The token rotation request is not valid.¶

"key_rotation_not_supported":

The AS does not allow rotation of this access token's key.¶

"invalid_continuation":

The continuation of the referenced grant could not be processed.¶

"user_denied":

The RO denied the request.¶

"request_denied":

The request was denied for an unspecified reason.¶

"unknown_user":

The user presented in the request is not known to the AS or does not match the user present during interaction.¶

"unknown_interaction":

The interaction integrity could not be established.¶

"too_fast":

The client instance did not respect the timeout in the wait response before the next call.¶

"too_many_attempts":

A limit has been reached in the total number of reasonable attempts. This number is either defined statically or adjusted based on runtime conditions by the AS.¶

Additional error codes can be defined in the "GNAP Error Codes" registry (Section 10.15).¶

For example, if the RO denied the request while interacting with the AS,the AS would return the following error when the client instance tries tocontinue the grant request:¶

{    "error": {        "code": "user_denied",        "description": "The RO denied the request"    }}

Alternatively, the ASMAY choose to only return the error as codes and provide the error as a string. Since thedescription field is not intended to be machine-readable, the following response is considered functionally equivalent to the previous example for the purposes of the client software's understanding:¶

{    "error": "user_denied"}

If an error state is reached but the grant is in thepending state (and therefore the client instance can continue), the ASMAY include thecontinue field in the response along with theerror, as defined inSection 3.1. This allows the client instance to modify its request for access, potentially leading to prompting the RO again. Other fieldsMUST NOT be included in the response.¶

4.1.Starting Interaction with the End User

When a grant request is in thepending state, the interaction start methods sent bythe client instance can be used to facilitate interaction with the end user.To initiate an interaction start method indicated by theinteraction start responses (Section 3.3) from the AS, the client instancefollows the steps defined by that interaction start mode. The actions of the client instancerequired for the interaction start modes defined in this specification are describedin the following subsections. Interaction start modes defined in extensions to this specificationMUST define the expected actions of the client software when that interaction start mode is used.¶

If the client instance does not start an interaction start mode within an AS-determined amount oftime, the ASMUST reject attempts to use the interaction start modes. If the client instance hasalready begun one interaction start mode and the interaction has been successfully completed, the ASMUST reject attempts to use other interactionstart modes. For example, if a user code has been successfully entered for a grant request, the ASwill need to reject requests to an arbitrary redirect URI on the same grant request in order to prevent anattacker from capturing and altering an active authorization process.¶

4.2.Post-Interaction Completion

If an interaction "finish" method (Section 3.3.5) isassociated with the current request, the ASMUST follow the appropriatemethod upon completion of interaction in order to signal the clientinstance to continue, except for some limited error cases discussed below.If a finish method is not available, the ASSHOULD instruct the RO toreturn to the client instance upon completion. In such cases, it is expectedthat the client instance will poll the continuation endpoint as described inSection 5.2.¶

The ASMUST create an interaction reference and associate thatreference with the current interaction and the underlying pendingrequest. The interaction reference value is an ASCII string consisting of onlyunreserved characters perSection 2.3 of [RFC3986].The interaction reference valueMUST be sufficiently random so as not to beguessable by an attacker. The interaction referenceMUST beone-time-use to prevent interception and replay attacks.¶

The ASMUST calculate a hash value based on the client instance, AS nonces, and theinteraction reference, as described inSection 4.2.3. The client instance will use this value tovalidate the "finish" call.¶

All interaction finish methodsMUST define a wayto convey the hash and interaction reference back to the client instance. When aninteraction finish method is used, the client instanceMUST present the interactionreference back to the AS as part of its continuation request (Section 5.1).¶

Note that in many error cases, such as when the RO has deniedaccess, the "finish" method is still enacted by the AS.This pattern allows the client instance to potentially recover from the errorstate by modifying its request or providing additional information directly to the AS in acontinuation request. The ASMUST NOT follow the "finish" method in thefollowing circumstances:¶

• The AS has determined that any URIs involved with the finish method are dangerous or blocked.¶

• The AS cannot determine which ongoing grant request is being referenced.¶

• The ongoing grant request has been canceled or otherwise blocked.¶

NOTE: '\' line wrapping per RFC 8792https://client.example.net/return/123455\  ?hash=x-gguKWTj8rQf7d7i3w3UhzvuJ5bpOlKyAlVpLxBffY\  &interact_ref=4IFWWIKYBC2PQ6U56NL1

POST /push/554321 HTTP/1.1Host: client.example.netContent-Type: application/json{  "hash": "pjdHcrti02HLCwGU3qhUZ3wZXt8IjrV_BtE3oUyOuKNk",  "interact_ref": "4IFWWIKYBC2PQ6U56NL1"}

VJLO6A4CATR0KROMBDOFXG4Y5CVJCX821LH4IFWWIKYB2PQ6U56NL1https://server.example.com/tx

x-gguKWTj8rQf7d7i3w3UhzvuJ5bpOlKyAlVpLxBffY

NOTE: '\' line wrapping per RFC 8792pyUkVJSmpqSJMaDYsk5G8WCvgY91l-agUPe1wgn-cc5rUtN69gPI2-S_s-Eswed8iB4\  PJ_a5Hg6DNi7qGgKwSQ

5.1.Continuing after a Completed Interaction

When the AS responds to the client instance'sfinish method as inSection 4.2.1, thisresponse includes an interaction reference. The client instanceMUST include that value as the fieldinteract_ref in a POST request to the continuation URI.¶

POST /continue HTTP/1.1Host: server.example.comContent-Type: application/jsonAuthorization: GNAP 80UPRY5NM33OMUKMKSKUSignature-Input: sig1=...Signature: sig1=...Content-Digest: sha-256=...{  "interact_ref": "4IFWWIKYBC2PQ6U56NL1"}

Since the interaction reference is a one-time-use value as described inSection 4.2.1,if the client instance needs to make additional continuation calls after this request, the client instanceMUST NOT include the interaction reference in subsequent calls. If the AS detects a client instancesubmitting an interaction reference when the request is not in thepending state, the ASMUSTreturn atoo_many_attempts error (Section 3.6) andSHOULD invalidatethe ongoing request by moving it to thefinalized state.¶

If the grant request is in theapproved state, the grant response (Section 3)MAY contain anynewly created access tokens (Section 3.2) ornewly released subject information (Section 3.4). The responseMAY containa new continuation response (Section 3.1) as described above. The responseSHOULD NOT contain any interaction responses (Section 3.3).¶

If the grant request is in thepending state, the grant response (Section 3)MUST NOT contain access tokens or subject information andMAY contain a new interaction response (Section 3.3) to any interaction methods that have not been exhausted at the AS.¶

For example, if the request is successful in causing the AS to issue access tokens andrelease opaque subject claims, the response could look like this:¶

NOTE: '\' line wrapping per RFC 8792{    "access_token": {        "value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",        "manage": {            "uri": "https://server.example.com/token/PRY5NM33O",            "access_token": {                "value": "B8CDFONP21-4TB8N6.BW7ONM"            }        }    },    "subject": {        "sub_ids": [ {          "format": "opaque",          "id": "J2G8G8O4AZ"        } ]    }}

With the above example, the client instance cannot make an additional continuation request becauseacontinue field is not included.¶

In the following non-normative example, the RO has denied the client instance's request, and the AS responds with the following response:¶

{    "error": "user_denied",    "continue": {        "access_token": {            "value": "33OMUKMKSKU80UPRY5NM"        },        "uri": "https://server.example.com/continue",        "wait": 30    }}

In the preceding example, the AS includes thecontinue field in the response. Therefore, the client instance can continue the grant negotiation process, perhaps modifying the request as discussed inSection 5.3.¶

5.2.Continuing during Pending Interaction (Polling)

When the client instance does not include afinish parameter, the client instance will often need topoll the AS until the RO has authorized the request. To do so, the client instance makes a POSTrequest to the continuation URI as inSection 5.1 but does notinclude message content.¶

POST /continue HTTP/1.1Host: server.example.comAuthorization: GNAP 80UPRY5NM33OMUKMKSKUSignature-Input: sig1=...Signature: sig1=...

If the grant request is in theapproved state, the grant response (Section 3)MAY contain anynewly created access tokens (Section 3.2) ornewly released subject claims (Section 3.4). The responseMAY containa new continuation response (Section 3.1) as described above. If acontinuefield is included, itSHOULD include await field to facilitate a reasonable polling rate bythe client instance. The responseSHOULD NOT contain interaction responses (Section 3.3).¶

If the grant request is in thepending state, the grant response (Section 3)MUST NOT contain access tokens or subject information andMAY contain a new interaction response (Section 3.3) to any interaction methods that have not been exhausted at the AS.¶

For example, if the request has not yet been authorized by the RO, the AS could respondby telling the client instance to make another continuation request in the future. In the following non-normative example,a new, unique access token has been issued for the call, which the client instance will use in itsnext continuation request.¶

{    "continue": {        "access_token": {            "value": "33OMUKMKSKU80UPRY5NM"        },        "uri": "https://server.example.com/continue",        "wait": 30    }}

If the request is successful in causing the AS to issue access tokens andrelease subject information, the response could look like the following non-normative example:¶

NOTE: '\' line wrapping per RFC 8792{    "access_token": {        "value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",        "manage": {            "uri": "https://server.example.com/token/PRY5NM33O",            "access_token": {                "value": "B8CDFONP21-4TB8N6.BW7ONM"            }        }    },    "subject": {        "sub_ids": [ {          "format": "opaque",          "id": "J2G8G8O4AZ"        } ]    }}

SeeSection 11.23 for considerations on polling for continuation without an interactionfinish method.¶

In error conditions, the AS responds to the client instance with an error code as discussed inSection 3.6.For example, if the client instance has polled too many times before the RO has approved the request, the AS would respond with a message like the following:¶

{    "error": "too_many_attempts"}

Since this response does not include acontinue field, the client instance cannot continue topoll the AS for additional updates and the grant request isfinalized. If the client instancestill needs access to the resource, it will need to start with a new grant request.¶

5.3.Modifying an Existing Request

The client instance might need to modify an ongoing request, whether or not tokens have already beenissued or subject information has already been released. In such cases, the client instance makes an HTTP PATCHrequest to the continuation URI and includes any fields it needs to modify. Fieldsthat aren't included in the request are considered unchanged from the original request.¶

A grant request associated with a modification requestMUST be in theapproved orpending state.When the AS receives a valid modification request, the ASMUST place the grant request into theprocessing state and re-evaluate the authorization in the new context created by the updaterequest, since the extent and context of the request could have changed.¶

The client instanceMAY include theaccess_token andsubject fields as described in Sections2.1and2.2. Inclusion of these fields override any values in the initial request,whichMAY trigger additional requirements and policies by the AS. For example, if the client instance is asking formore access, the AS could require additional interaction with the RO to gather additional consent.If the client instance is asking for more limited access, the AS could determine that sufficient authorizationhas been granted to the client instance and return the more limited access rights immediately.If the grant request was previously in theapproved state, the AS could decide to remember the larger scale of access rights associatedwith the grant request, allowing the client instance to make subsequent requests of differentsubsets of granted access. The details of this processing are out of scope for this specification,but a one possible approach is as follows:¶

1. A client instance requests access toFoo, and this is granted by the RO. This results in an access token:AT1.¶

2. The client instance later modifies the grant request to includeFoo andBar together. Since the client instance was previously grantedFoo under this grant request, the RO is prompted to allow the client instance access toFoo andBar together. This results in a new access token:AT2. This access token has access to bothFoo andBar. The rights of the original access tokenAT1 are not modified.¶

3. The client instance makes another grant modification to ask only forBar. Since the client instance was previously grantedFoo andBar together under this grant request, the RO is not prompted, and the access toBar is granted in a new access token:AT3. This new access token does not allow access toFoo.¶

4. The original access tokenAT1 expires, and the client seeks a new access token to replace it. The client instance makes another grant modification to ask only forFoo. Since the client instance was previously grantedFoo andBar together under this grant request, the RO is not prompted, and the access toFoo is granted in a new access token:AT4. This new access token does not allow access toBar.¶

All four access tokens are independent of each other and associated with the same underlying grant request. Each of these access tokens could possibly also be rotated using token management, if available. For example, instead of asking for a new token to replaceAT1, the client instance could ask for a refresh ofAT1 using the rotation method of the token management API. This would result in a refreshedAT1 with a different token value and expiration from the originalAT1 but with the same access rights of allowing only access toFoo.¶

The client instanceMAY include theinteract field as described inSection 2.5.Inclusion of this field indicates that the client instance is capable of driving interaction withthe end user, and this field replaces any values from a previous request. The ASMAY respond to anyof the interaction responses as described inSection 3.3, just like it would to a newrequest.¶

The client instanceMAY include theuser field as described inSection 2.4 to present new assertionsor information about the end user. The ASSHOULD check that this presented user information isconsistent with any user information previously presented by the client instance or otherwiseassociated with this grant request.¶

The client instanceMUST NOT include theclient field of the request, since the clientinstance is assumed not to have changed. Modification of client instance information, includingrotation of keys associated with the client instance, is outside thescope of this specification.¶

The client instanceMUST NOT include post-interaction responses such as those described inSection 5.1.¶

Modification requestsMUST NOT alter previously issued access tokens. Instead, any accesstokens issued from a continuation are considered new, separate access tokens. The ASMAY revoke previously issued access tokens after a modification has occurred.¶

If the modified request can be granted immediately by the AS (the grant request is in theapproved state),the grant response (Section 3)MAY contain any newly created access tokens (Section 3.2) ornewly released subject claims (Section 3.4). The responseMAY containa new continuation response (Section 3.1) as described above. If interactioncan occur, the responseSHOULD contain interaction responses (Section 3.3) as well.¶

For example, a client instance initially requests a set of resources using references:¶

POST /tx HTTP/1.1Host: server.example.comContent-Type: application/jsonSignature-Input: sig1=...Signature: sig1=...Content-Digest: sha-256=...{    "access_token": {        "access": [            "read", "write"        ]    },    "interact": {        "start": ["redirect"],        "finish": {            "method": "redirect",            "uri": "https://client.example.net/return/123455",            "nonce": "LKLTI25DK82FX4T4QFZC"        }    },    "client": "987YHGRT56789IOLK"}

Access is granted by the RO, and a token is issued by the AS.In its final response, the AS includes acontinue field, which includesa separate access token for accessing the continuation API:¶

{    "continue": {        "access_token": {            "value": "80UPRY5NM33OMUKMKSKU"        },        "uri": "https://server.example.com/continue",        "wait": 30    },    "access_token": {        "value": "RP1LT0-OS9M2P_R64TB",        "access": [            "read", "write"        ]    }}

Thiscontinue field allows the client instance to make an eventual continuation call.Some time later, the client instance realizes that it no longer needs"write" access and therefore modifies its ongoing request, here asking for just "read" accessinstead of both "read" and "write" as before.¶

PATCH /continue HTTP/1.1Host: server.example.comContent-Type: application/jsonAuthorization: GNAP 80UPRY5NM33OMUKMKSKUSignature-Input: sig1=...Signature: sig1=...Content-Digest: sha-256=...{    "access_token": {        "access": [            "read"        ]    }    ...}

The AS replaces the previousaccess from the first request, allowing the AS todetermine if any previously granted consent already applies. In this case, the AS woulddetermine that reducing the breadth of the requested access means that new accesstokens can be issued to the client instance without additional interaction or consent. The AS would likely revoke previously issued access tokensthat had the greater access rights associated with them, unless they had been issuedwith thedurable flag.¶

{    "continue": {        "access_token": {            "value": "M33OMUK80UPRY5NMKSKU"        },        "uri": "https://server.example.com/continue",        "wait": 30    },    "access_token": {        "value": "0EVKC7-2ZKwZM_6N760",        "access": [            "read"        ]    }}

As another example, the client instance initially requests read-only access but laterneeds to step up its access. The initial request could look like the following HTTP message:¶

POST /tx HTTP/1.1Host: server.example.comContent-Type: application/jsonSignature-Input: sig1=...Signature: sig1=...Content-Digest: sha-256=...{    "access_token": {        "access": [            "read"        ]    },    "interact": {        "start": ["redirect"],        "finish": {            "method": "redirect",            "uri": "https://client.example.net/return/123455",            "nonce": "LKLTI25DK82FX4T4QFZC"        }    },    "client": "987YHGRT56789IOLK"}

Access is granted by the RO, and a token is issued by the AS.In its final response, the AS includes acontinue field:¶

{    "continue": {        "access_token": {            "value": "80UPRY5NM33OMUKMKSKU"        },        "uri": "https://server.example.com/continue",        "wait": 30    },    "access_token": {        "value": "RP1LT0-OS9M2P_R64TB",        "access": [            "read"        ]    }}

This allows the client instance to make an eventual continuation call. The client instance later realizes that it nowneeds "write" access in addition to the "read" access. Since this is an expansion of whatit asked for previously, the client instance also includes a new interaction field in case the AS needsto interact with the RO again to gather additional authorization. Note that the client instance'snonce and callback are different from the initial request. Since the original callback wasalready used in the initial exchange and the callback is intended for one-time use, a new oneneeds to be included in order to use the callback again.¶

PATCH /continue HTTP/1.1Host: server.example.comContent-Type: application/jsonAuthorization: GNAP 80UPRY5NM33OMUKMKSKUSignature-Input: sig1=...Signature: sig1=...Content-Digest: sha-256=...{    "access_token": {        "access": [            "read", "write"        ]    },    "interact": {        "start": ["redirect"],        "finish": {            "method": "redirect",            "uri": "https://client.example.net/return/654321",            "nonce": "K82FX4T4LKLTI25DQFZC"        }    }}

From here, the AS can determine that the client instance is asking for more than it was previously granted,but since the client instance has also provided a mechanism to interact with the RO, the AS can use thatto gather the additional consent. The protocol continues as it would with a new request.Since the old access tokens are good for a subset of the rights requested here, theAS might decide to not revoke them. However, any access tokens granted after this updateprocess are new access tokens and do not modify the rights of existing access tokens.¶

5.4.Revoking a Grant Request

If the client instance wishes to cancel an ongoing grant request and place it into thefinalizedstate, the client instance makes anHTTP DELETE request to the continuation URI.¶

DELETE /continue HTTP/1.1Host: server.example.comContent-Type: application/jsonAuthorization: GNAP 80UPRY5NM33OMUKMKSKUSignature-Input: sig1=...Signature: sig1=...

If the request is successfully revoked, the AS responds with HTTP status code 204 (No Content).The ASSHOULD revoke all associated access tokens, if possible. The ASSHOULD disable alltoken rotation and other token management functions on such access tokens, if possible.Once the grant request is in thefinalized state, itMUST NOT be moved to any other state.¶

If the request is not revoked, the AS responds with aninvalid_continuation error (Section 3.6).¶

6.1.Rotating the Access Token Value

If the client instance has an access token and that access token expires, theclient instance might want to rotate the access token to a new value without expiration.Rotating an access token consists of issuing a new access token in place of anexisting access token, with the same rights and properties as the original token,apart from an updated token value and expiration time.¶

To rotate an access token, the client instance makes an HTTP POST to the token management URIwith no message content,sending the access token in the authorization header as described inSection 7.2 and signing the requestwith the appropriate key.¶

POST /token/PRY5NM33O HTTP/1.1Host: server.example.comAuthorization: GNAP B8CDFONP21-4TB8N6.BW7ONMSignature-Input: sig1=...Signature: sig1=...Content-Digest: sha-256=...

The client instance cannot request to alter the access rightsassociated with the access token during a rotation request. To get an access token with differentaccess rights for this grant request, the client instance has to call the continuation API's update functionality (Section 5.3)to get a new access token. The client instance can also create a new grant requestwith the required access rights.¶

The AS validates that the token management access token presented is associated with the managementURI, that the AS issued the token to the given client instance, and thatthe presented key is the correct key for the token management access token. The AS determineswhich access token is being rotated from the token management URI, the token management access token, or both.¶

If the token is validated and the key is appropriate for therequest, the ASMUST invalidate the current access token value associatedwith this URI, if possible. Note that stateless access tokens can make proactiverevocation difficult within a system; seeSection 11.32.¶

For successful rotations, the AS responds with an HTTP status code 200 (OK) with JSON-formatted message content consisting of the rotated access tokenin theaccess_token field described inSection 3.2.1. The value of theaccess tokenMUST NOT be the same as the current value of the accesstoken used to access the management API. The responseMUST include anaccess token management URI, and the value of this URIMAY be differentfrom the URI used by the client instance to make the rotation call. The client instanceMUST use this new URI to manage the rotated access token.¶

The access rights in theaccess array for the rotated access tokenMUSTbe included in the response andMUST be the sameas the token before rotation.¶

NOTE: '\' line wrapping per RFC 8792{    "access_token": {        "value": "FP6A8H6HY37MH13CK76LBZ6Y1UADG6VEUPEER5H2",        "manage": {            "uri": "https://server.example.com/token/PRY5NM33O",            "access_token": {                "value": "B8CDFONP21-4TB8N6.BW7ONM"            }        },        "expires_in": 3600,        "access": [            {                "type": "photo-api",                "actions": [                    "read",                    "write",                    "dolphin"                ],                "locations": [                    "https://server.example.net/",                    "https://resource.local/other"                ],                "datatypes": [                    "metadata",                    "images"                ]            },            "read", "dolphin-metadata"        ]    }}

If the AS is unable or unwilling to rotate the value of the access token, the AS responds with aninvalid_rotation error (Section 3.6). Upon receiving such an error, the client instanceMUST consider the access token to not have changed its state.¶

POST /token/PRY5NM33O HTTP/1.1Host: server.example.comAuthorization: GNAP B8CDFONP21-4TB8N6.BW7ONMSignature-Input: \  sig1=("@method" "@target-uri" "content-digest" \        "authorization"),\  sig2=("@method" "@target-uri" "content-digest" \        "authorization" "signature";key="sig1" \        "signature-input";key="sig1")Signature: sig1=..., sig2=...Content-Digest: sha-256=...{    "key": {        "proof": "httpsig",        "jwk": {            "kty": "RSA",            "e": "AQAB",            "kid": "xyz-2",            "alg": "RS256",            "n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY..."        }    }}

6.2.Revoking the Access Token

If the client instance wishes to revoke the access token proactively, such as whena user indicates to the client instance that they no longer wish for it to haveaccess or the client instance application detects that it is being uninstalled,the client instance can use the token management URI to indicate to the AS thatthe ASSHOULD invalidate the access token for all purposes.¶

The client instance makes an HTTP DELETE request to the token managementURI, presenting the access token and signing the request withthe appropriate key.¶

DELETE /token/PRY5NM33O HTTP/1.1Host: server.example.comAuthorization: GNAP B8CDFONP21-4TB8N6.BW7ONMSignature-Input: sig1=...Signature: sig1=...

If the key presented is associated with the token (or the client instance, inthe case of a bearer token), the ASMUST invalidate the access token, ifpossible, and return an HTTP response code 204.¶

204 No Content

Though the ASMAY revoke an access token at any time forany reason, the token management function is specifically for the client instance's use.If the access token has already expired or has been revoked through othermeans, the ASSHOULD honor the revocation request tothe token management URI as valid, since the end result is that the token is still not usable.¶

7.1.Key Formats

Several different places in GNAP require the presentation of key materialby value or by reference. Key material sent by value is sent using a JSON object with several fields described in this section.¶

All keys are associated with a specific key proofing method.The proofing method associated with the keyis indicated using theproof field of the key object.¶

proof (string or object):

The form of proof that the client instance will use when presenting the key. The valid values of this field and the processing requirements for each are detailed inSection 7.3.REQUIRED.¶

A key presented by valueMUST be a public key andMUST be presented in only onesupported format, as discussed inSection 11.35. Note thatwhile most formats present the full value of the public key, someformats present a value cryptographically derived from the public key. Seeadditional discussion of the presentation of public keys inSection 11.7.¶

jwk (object):

The public key and its properties represented as a JSON Web Key (JWK)[RFC7517]. A JWKMUST contain thealg (Algorithm) andkid (Key ID) parameters. Thealg parameterMUST NOT be "none". Thex5c (X.509 Certificate Chain) parameterMAY be used to provide the X.509 representation of the provided public key.OPTIONAL.¶

cert (string):

The Privacy-Enhanced Mail (PEM) serialized value of the certificate used to sign the request, with optional internal whitespace per[RFC7468]. The PEM header and footer are optionally removed.OPTIONAL.¶

cert#S256 (string):

The certificate thumbprint calculated as per MTLS for OAuth[RFC8705] in base64url encoding. Note that this format does not include the full public key.OPTIONAL.¶

Additional key formats can be defined in the "GNAP Key Formats" registry (Section 10.17).¶

The following non-normative example shows a single key presented in two different formats. The example key is intended to be used with the HTTP message signatures proofing mechanism (Section 7.3.1), as indicated by thehttpsig value of theproof field.¶

As a JWK:¶

"key": {    "proof": "httpsig",    "jwk": {        "kty": "RSA",        "e": "AQAB",        "kid": "xyz-1",        "alg": "RS256",        "n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY..."    }}

As a certificate in PEM format:¶

"key": {    "proof": "httpsig",    "cert": "MIIEHDCCAwSgAwIBAgIBATANBgkqhkiG9w0BAQsFA..."}

When the key is presented in GNAP, proof of this key materialMUST be used to bind the request, the nature of which varies withthe location in the protocol where the key is used. For a key used as part of a client instance's initial requestinSection 2.3, the key value represents the client instance's public key, andproof of that keyMUST be presented in that request. For a key used as part of anaccess token response inSection 3.2.1, the proof of that keyMUSTbe used when the client instance later presents the access token to the RS.¶

    "key": "S-P4XJQ_RYJCRTSU1.63N3E"

7.2.Presenting Access Tokens

Access tokens are issued to client instances in GNAP to allow the client instance to makean authorized call to an API.The method the client instance uses to send an access token depends on whetherthe token is bound to a key and, if so, which proofing method is associatedwith the key. This information is conveyed by thekey parameter and thebearer flag in the access token response structure (Section 3.2.1).¶

If theflags field does not contain thebearer flag and thekey is absent, the access tokenMUST be sent using the same key and proofing mechanism that the client instance usedin its initial request (or its most recent rotation).¶

If theflags field does not contain thebearer flag and thekey value is an object asdescribed inSection 7.1, the access tokenMUST be sent using the key and proofingmechanism defined by the value of theproof field within the key object.¶

The access tokenMUST be sent using the HTTP Authorization request header field andthe "GNAP" authorization scheme along with a key proof as described inSection 7.3for the key bound to the access token. For example, an access token bound using HTTP message signatures would be sent as follows:¶

NOTE: '\' line wrapping per RFC 8792GET /stuff HTTP/1.1Host: resource.example.comAuthorization: GNAP 80UPRY5NM33OMUKMKSKUSignature-Input: sig1=("@method" "@target-uri" "authorization")\  ;created=1618884473;keyid="gnap-rsa";nonce="NAOEJF12ER2";tag="gnap"Signature: sig1=:FQ+EjWqc38uLFByKa5y+c4WyYYwCTGUhidWKfr5L1Cha8FiPEw\  DxG7nWttpBLS/B6VLfkZJogPbclySs9MDIsAIJwHnzlcJjwXWR2lfvm2z3X7EkJHm\  Zp4SmyKOS34luAiKR1xwf32NYFolHmZf/SbHZJuWvQuS4U33C+BbsXz8MflFH1Dht\  H/C1E5i244gSbdLCPxzABc/Q0NHVSLo1qaouYIvnxXB8OT3K7mwWjsLh1GC5vFThb\  3XQ363r6f0OPRa4qWHhubR/d/J/lNOjbBdjq9AJ69oqNJ+A2XT+ZCrVasEJE0OBvD\  auQoiywhb8BMB7+PEINsPk5/8UvaNxbw==:

If theflags field contains thebearer flag, the access token is a bearer tokenthatMUST be sent using the Authorization request header field method defined in[RFC6750].¶

Authorization: Bearer OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0

TheForm-Encoded Body Parameter andURI Query Parameter methods of[RFC6750]MUST NOTbe used for GNAP access tokens.¶

7.3.Proving Possession of a Key with a Request

Any keys presented by the client instance to the AS or RSMUST be validated aspart of the request in which they are presented. The type of bindingused is indicated by theproof parameter of the key object inSection 7.1.Key proofing methods are specified either by a string, which consists of the key proofingmethod name on its own, or by a JSON object with the required fieldmethod:¶

method:

The name of the key proofing method to be used.REQUIRED.¶

Individual methods defined as objectsMAY define additional parameters as members in this object.¶

Values for themethod defined by this specification are as follows:¶

"httpsig" (string or object):

HTTP message signing. SeeSection 7.3.1.¶

"mtls" (string):

MTLS certificate verification. SeeSection 7.3.2.¶

"jwsd" (string):

A detached JWS signature header. SeeSection 7.3.3.¶

"jws" (string):

Attached JWS Payload. SeeSection 7.3.4.¶

Additional proofing methods can be defined in the "GNAP Key Proofing Methods" registry (Section 10.16).¶

Proofing methodsMAY be defined as both an object and a string. For example, thehttpsig method can be specified as anobject with its parameters explicitly declared, such as:¶

{    "proof": {        "method": "httpsig",        "alg": "ecdsa-p384-sha384",        "content-digest-alg": "sha-256"    }}

Thehttpsig method also defines default behavior when it is passed as a string form,using the signature algorithm specified by the associated keymaterial and the content digest is calculated using sha-256. This configuration can be selectedusing the following shortened form:¶

{    "proof": "httpsig"}

All key binding methods used by this specificationMUST cover all relevant portionsof the request, including anything that would change the nature of the request, to allowfor secure validation of the request. Relevant aspects includethe URI being called, the HTTP method being used, any relevant HTTP headers andvalues, and the HTTP message content itself. The verifier of the signed messageMUST validate all components of the signed message to ensure that nothinghas been tampered with or substituted in a way that would change the nature ofthe request. Definitions of key binding methodsMUST enumerate how theserequirements are fulfilled.¶

When a key proofing mechanism is bound to an access token, the key being presentedMUSTbe the key associated with the access token, and the access tokenMUST be coveredby the signature method of the proofing mechanism.¶

The key binding methods in this sectionMAY be used by othercomponents making calls as part of GNAP, such as the extensions allowing theRS to make calls to the AS defined in[GNAP-RS]. To facilitate this extended use,"signer" and "verifier" are used as generic terms in the subsections below.In the core functions of GNAP specified in this document, the "signer" is theclient instance, and the "verifier" is the AS (for grant requests) or RS (forresource requests), as appropriate.¶

When used for delegation in GNAP, these key binding mechanisms allowthe AS to ensure that the keys presented by the client instance in the initial request are incontrol of the party calling any follow-up or continuation requests. To facilitatethis requirement, the continuation response (Section 3.1) includesan access token bound to the client instance's key (Section 2.3), and that key (or its most recent rotation)MUST be proved in all continuation requests(Section 5). Token management requests (Section 6) are similarly boundto either the access token's own key or, in the case of bearer tokens, the client instance's key.¶

In the following subsections, unless otherwise noted, theRS256 JSON Object Signing and Encryption (JOSE) signature algorithm (defined inSection 3.3 of [RFC7518]) is appliedusing the following RSA key (presented here in JWK format):¶

NOTE: '\' line wrapping per RFC 8792{    "kid": "gnap-rsa",    "p": "xS4-YbQ0SgrsmcA7xDzZKuVNxJe3pCYwdAe6efSy4hdDgF9-vhC5gjaRk\        i1wWuERSMW4Tv44l5HNrL-Bbj_nCJxr_HAOaesDiPn2PnywwEfg3Nv95Nn-\        eilhqXRaW-tJKEMjDHu_fmJBeemHNZI412gBnXdGzDVo22dvYoxd6GM",    "kty": "RSA",    "q": "rVdcT_uy-CD0GKVLGpEGRR7k4JO6Tktc8MEHkC6NIFXihk_6vAIOCzCD6\        LMovMinOYttpRndKoGTNdJfWlDFDScAs8C5n2y1STCQPRximBY-bw39-aZq\        JXMxOLyPjzuVgiTOCBIvLD6-8-mvFjXZk_eefD0at6mQ5qV3U1jZt88",    "d": "FHlhdTF0ozTliDxMBffT6aJVKZKmbbFJOVNten9c3lXKB3ux3NAb_D2dB\        7inp9EV23oWrDspFtvCvD9dZrXgRKMHofkEpo_SSvBZfgtH-OTkbY_TqtPF\        FLPKAw0JX5cFPnn4Q2xE4n-dQ7tpRCKl59vZLHBrHShr90zqzFp0AKXU5fj\        b1gC9LPwsFA2Fd7KXmI1drQQEVq9R-o18Pnn4BGQNQNjO_VkcJTiBmEIVT_\        KJRPdpVJAmbgnYWafL_hAfeb_dK8p85yurEVF8nCK5oO3EPrqB7IL4UqaEn\        5Sl3u0j8x5or-xrrAoNz-gdOv7ONfZY6NFoa-3f8q9wBAHUuQ",    "e": "AQAB",    "qi": "ogpNEkDKg22Rj9cDV_-PJBZaXMk66Fp557RT1tafIuqJRHEufSOYnsto\        bWPJ0gHxv1gVJw3gm-zYvV-wTMNgr2wVsBSezSJjPSjxWZtmT2z68W1DuvK\        kZy15vz7Jd85hmDlriGcXNCoFEUsGLWkpHH9RwPIzguUHWmTt8y0oXyI",    "dp": "dvCKGI2G7RLh3WyjoJ_Dr6hZ3LhXweB3YcY3qdD9BnxZ71mrLiMQg4c_\        EBnwqCETN_5sStn2cRc2JXnvLP3G8t7IFKHTT_i_TSTacJ7uT04MSa053Y3\        RfwbvLjRNPR0UKAE3ZxROUoIaVNuU_6-QMf8-2ilUv2GIOrCN87gP_Vk",    "alg": "RS256",    "dq": "iMZmELaKgT9_W_MRT-UfDWtTLeFjIGRW8aFeVmZk9R7Pnyt8rNzyN-IQ\        M40ql8u8J6vc2GmQGfokLlPQ6XLSCY68_xkTXrhoU1f-eDntkhP7L6XawSK\        Onv5F2H7wyBQ75HUmHTg8AK2B_vRlMyFKjXbVlzKf4kvqChSGEz4IjQ",    "n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8BfYdHsFzAt\        YKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZGYX\        jHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZx\        e0jRETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0\        bunS0K3bA_3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kO\        zywzwPTuq-cVQDyEN7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"}

Key proofing methodsSHOULD define a mechanism to allow the rotation of keys discussedinSection 6.1.1. Key rotation mechanismsMUST define a way for presentingproof of two keys simultaneously with the following attributes:¶

• The value of or reference to the new key materialMUST be signed by the existing key. Generally speaking, this amounts to using the existing key to sign the content of the message that contains the new key.¶

• The signature of the old keyMUST be signed by the new key. Generally speaking, this means including the signature value of the old key under the coverage of the new key.¶

{    "proof": {        "method": "httpsig",        "alg": "ecdsa-p384-sha384",        "content-digest-alg": "sha-512"    }}

{    "proof": "httpsig"}

NOTE: '\' line wrapping per RFC 8792{    "access_token": {        "access": [            "dolphin-metadata"        ]    },    "interact": {        "start": ["redirect"],        "finish": {            "method": "redirect",            "uri": "https://client.foo/callback",            "nonce": "VJLO6A4CAYLBXHTR0KRO"        }    },    "client": {      "key": {        "proof": "httpsig",        "jwk": {            "kid": "gnap-rsa",            "kty": "RSA",            "e": "AQAB",            "alg": "PS512",            "n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\  YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\  YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\  ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\  3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\  N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"        }      }      "display": {        "name": "My Client Display Name",        "uri": "https://client.foo/"      },    }}

sha-256=:q2XBmzRDCREcS2nWo/6LYwYyjrlN1bRfv+HKLbeGAGg=:

NOTE: '\' line wrapping per RFC 8792"@method": POST"@target-uri": https://server.example.com/gnap"content-digest": \  sha-256=:q2XBmzRDCREcS2nWo/6LYwYyjrlN1bRfv+HKLbeGAGg=:"content-length": 988"content-type": application/json"@signature-params": ("@method" "@target-uri" "content-digest" \  "content-length" "content-type");created=1618884473\  ;keyid="gnap-rsa";nonce="NAOEJF12ER2";tag="gnap"

NOTE: '\' line wrapping per RFC 8792POST /gnap HTTP/1.1Host: server.example.comContent-Type: application/jsonContent-Length: 988Content-Digest: sha-256=:q2XBmzRDCREcS2nWo/6LYwYyjrlN1bRfv+HKLbeGAG\  g=:Signature-Input: sig1=("@method" "@target-uri" "content-digest" \  "content-length" "content-type");created=1618884473\  ;keyid="gnap-rsa";nonce="NAOEJF12ER2";tag="gnap"Signature: sig1=:c2uwTa6ok3iHZsaRKl1ediKlgd5cCAYztbym68XgX8gSOgK0Bt\  +zLJ19oGjSAHDjJxX2gXP2iR6lh9bLMTfPzbFVn4Eh+5UlceP+0Z5mES7v0R1+eHe\  OqBl0YlYKaSQ11YT7n+cwPnCSdv/6+62m5zwXEEftnBeA1ECorfTuPtau/yrTYEvD\  9A/JqR2h9VzAE17kSlSSsDHYA6ohsFqcRJavX29duPZDfYgkZa76u7hJ23yVxoUpu\  2J+7VUdedN/72N3u3/z2dC8vQXbzCPTOiLru12lb6vnBZoDbUGsRR/zHPauxhj9T+\  218o5+tgwYXw17othJSxIIOZ9PkIgz4g==:{    "access_token": {        "access": [            "dolphin-metadata"        ]    },    "interact": {        "start": ["redirect"],        "finish": {            "method": "redirect",            "uri": "https://client.foo/callback",            "nonce": "VJLO6A4CAYLBXHTR0KRO"        }    },    "client": {      "key": {        "proof": "httpsig",        "jwk": {            "kid": "gnap-rsa",            "kty": "RSA",            "e": "AQAB",            "alg": "PS512",            "n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\  YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\  YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\  ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\  3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\  N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"        }      }      "display": {        "name": "My Client Display Name",        "uri": "https://client.foo/"      },    }}

NOTE: '\' line wrapping per RFC 8792POST /token/PRY5NM33 HTTP/1.1Host: server.example.comAuthorization: GNAP 4398.34-12-asvDa.aContent-Digest: sha-512=:Fb/A5vnawhuuJ5xk2RjGrbbxr6cvinZqd4+JPY85u/\  JNyTlmRmCOtyVhZ1Oz/cSS4tsYen6fzpCwizy6UQxNBQ==:Signature-Input: old-key=("@method" "@target-uri" "content-digest" \  "authorization");created=1618884475;keyid="test-key-ecc-p256"\  ;tag="gnap"Signature: old-key=:vN4IKYsJl2RLFe+tYEm4dHM4R4BToqx5D2FfH4ge5WOkgxo\  dI2QRrjB8rysvoSEGvAfiVJOWsGcPD1lU639Amw==:{    "key": {        "proof": "httpsig",        "jwk": {            "kty": "RSA",            "e": "AQAB",            "kid": "xyz-2",            "alg": "RS256",            "n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY..."        }    }}

NOTE: '\' line wrapping per RFC 8792"@method": POST"@target-uri": https://server.example.com/token/PRY5NM33"content-digest": sha-512=:Fb/A5vnawhuuJ5xk2RjGrbbxr6cvinZqd4+JPY85\  u/JNyTlmRmCOtyVhZ1Oz/cSS4tsYen6fzpCwizy6UQxNBQ==:"authorization": GNAP 4398.34-12-asvDa.a"signature";key="old-key": :YdDJjDn2Sq8FR82e5IcOLWmmf6wILoswlnRcz+n\  M+e8xjFDpWS2YmiMYDqUdri2UiJsZx63T1z7As9Kl6HTGkQ==:"signature-input";key="old-key": ("@method" "@target-uri" \  "content-digest" "authorization");created=1618884475\  ;keyid="test-key-ecc-p256";tag="gnap""@signature-params": ("@method" "@target-uri" "content-digest" \  "authorization" "signature";key="old-key" "signature-input"\  ;key="old-key");created=1618884480;keyid="xyz-2"  ;tag="gnap-rotate"

NOTE: '\' line wrapping per RFC 8792POST /token/PRY5NM33 HTTP/1.1Host: server.example.comAuthorization: GNAP 4398.34-12-asvDa.aContent-Digest: sha-512=:Fb/A5vnawhuuJ5xk2RjGrbbxr6cvinZqd4+JPY85u/\  JNyTlmRmCOtyVhZ1Oz/cSS4tsYen6fzpCwizy6UQxNBQ==:Signature-Input: old-key=("@method" "@target-uri" "content-digest" \    "authorization");created=1618884475;keyid="test-key-ecc-p256"\    ;tag="gnap", \  new-key=("@method" "@target-uri" "content-digest" \    "authorization" "signature";key="old-key" "signature-input"\    ;key="old-key");created=1618884480;keyid="xyz-2"    ;tag="gnap-rotate"Signature: old-key=:vN4IKYsJl2RLFe+tYEm4dHM4R4BToqx5D2FfH4ge5WOkgxo\    dI2QRrjB8rysvoSEGvAfiVJOWsGcPD1lU639Amw==:, \  new-key=:VWUExXQ0geWeTUKhCfDT7WJyT++OHSVbfPA1ukW0o7mmstdbvIz9iOuH\    DRFzRBm0MQPFVMpLDFXQdE3vi2SL3ZjzcX2qLwzAtyRB9+RsV2caAA80A5ZGMoo\    gUsKPk4FFDN7KRUZ0vT9Mo9ycx9Dq/996TOWtAmq5z0YUYEwwn+T6+NcW8rFtms\    s1ZfXG0EoAfV6ve25p+x40Y1rvDHsfkakTRB4J8jWVDybSe39tjIKQBo3uicDVw\    twewBMNidIa+66iF3pWj8w9RSb0cncEgvbkHgASqaZeXmxxG4gM8p1HH9v/OqQT\    Oggm5gTWmCQs4oxEmWsfTOxefunfh3X+Qw==:{    "key": {        "proof": "httpsig",        "jwk": {            "kty": "RSA",            "e": "AQAB",            "kid": "xyz-2",            "alg": "RS256",            "n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY..."        }    }}

{    "proof": "mtls"}

POST /gnap HTTP/1.1Host: server.example.comContent-Type: application/joseContent-Length: 1567Client-Cert: \  :MIIC6jCCAdKgAwIBAgIGAXjw74xPMA0GCSqGSIb3DQEBCwUAMDYxNDAyBgNVBAMM\  K05JWU15QmpzRGp5QkM5UDUzN0Q2SVR6a3BEOE50UmppOXlhcEV6QzY2bVEwHhcN\  MjEwNDIwMjAxODU0WhcNMjIwMjE0MjAxODU0WjA2MTQwMgYDVQQDDCtOSVlNeUJq\  c0RqeUJDOVA1MzdENklUemtwRDhOdFJqaTl5YXBFekM2Nm1RMIIBIjANBgkqhkiG\  9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhYOJ+XOKISdMMShn/G4W9m20mT0VWtQBsmBB\  kI2cmRt4Ai8BfYdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8I\  kZ8NMwSrcUIBZGYXjHpwjzvfGvXH/5KJlnR3/uRUp4Z4Ujk2bCaKegDn11V2vxE4\  1hqaPUnhRZxe0jRETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo+\  uv4BC0bunS0K3bA/3UgVp7zBlQFoFnLTO2uWp/muLEWGl67gBq9MO3brKXfGhi3k\  OzywzwPTuq+cVQDyEN7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQIDAQABMA0GCSqG\  SIb3DQEBCwUAA4IBAQBnYFK0eYHy+hVf2D58usj39lhL5znb/q9G35GBd/XsWfCE\  wHuLOSZSUmG71bZtrOcx0ptle9bp2kKl4HlSTTfbtpuG5onSa3swRNhtKtUy5NH9\  W/FLViKWfoPS3kwoEpC1XqKY6l7evoTCtS+kTQRSrCe4vbNprCAZRxz6z1nEeCgu\  NMk38yTRvx8ihZpVOuU+Ih+dOtVe/ex5IAPYxlQsvtfhsUZqc7IyCcy72WHnRHlU\  fn3pJm0S5270+Yls3Iv6h3oBAP19i906UjiUTNH3g0xMW+V4uLxgyckt4wD4Mlyv\  jnaQ7Z3sR6EsXMocAbXHIAJhwKdtU/fLgdwL5vtx:{    "access_token": {        "access": [            "dolphin-metadata"        ]    },    "interact": {        "start": ["redirect"],        "finish": {            "method": "redirect",            "uri": "https://client.foo/callback",            "nonce": "VJLO6A4CAYLBXHTR0KRO"        }    },    "client": {      "key": {        "proof": "mtls",        "cert": "MIIC6jCCAdKgAwIBAgIGAXjw74xPMA0GCSqGSIb3DQEBCwUAMD\  YxNDAyBgNVBAMMK05JWU15QmpzRGp5QkM5UDUzN0Q2SVR6a3BEOE50UmppOXlhcEV\  6QzY2bVEwHhcNMjEwNDIwMjAxODU0WhcNMjIwMjE0MjAxODU0WjA2MTQwMgYDVQQD\  DCtOSVlNeUJqc0RqeUJDOVA1MzdENklUemtwRDhOdFJqaTl5YXBFekM2Nm1RMIIBI\  jANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhYOJ+XOKISdMMShn/G4W9m20mT\  0VWtQBsmBBkI2cmRt4Ai8BfYdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8\  KowlyVy8IkZ8NMwSrcUIBZGYXjHpwjzvfGvXH/5KJlnR3/uRUp4Z4Ujk2bCaKegDn\  11V2vxE41hqaPUnhRZxe0jRETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDad\  z8BkPo+uv4BC0bunS0K3bA/3UgVp7zBlQFoFnLTO2uWp/muLEWGl67gBq9MO3brKX\  fGhi3kOzywzwPTuq+cVQDyEN7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQIDAQABMA0\  GCSqGSIb3DQEBCwUAA4IBAQBnYFK0eYHy+hVf2D58usj39lhL5znb/q9G35GBd/Xs\  WfCEwHuLOSZSUmG71bZtrOcx0ptle9bp2kKl4HlSTTfbtpuG5onSa3swRNhtKtUy5\  NH9W/FLViKWfoPS3kwoEpC1XqKY6l7evoTCtS+kTQRSrCe4vbNprCAZRxz6z1nEeC\  guNMk38yTRvx8ihZpVOuU+Ih+dOtVe/ex5IAPYxlQsvtfhsUZqc7IyCcy72WHnRHl\  Ufn3pJm0S5270+Yls3Iv6h3oBAP19i906UjiUTNH3g0xMW+V4uLxgyckt4wD4Mlyv\  jnaQ7Z3sR6EsXMocAbXHIAJhwKdtU/fLgdwL5vtx"      }      "display": {        "name": "My Client Display Name",        "uri": "https://client.foo/"      },    },    "subject": {        "formats": ["iss_sub", "opaque"]    }}

{    "proof": "jwsd"}

{    "alg": "RS256",    "kid": "gnap-rsa",    "uri": "https://server.example.com/gnap",    "htm": "POST",    "typ": "gnap-binding-jwsd",    "created": 1618884475}

NOTE: '\' line wrapping per RFC 8792{    "access_token": {        "access": [            "dolphin-metadata"        ]    },    "interact": {        "start": ["redirect"],        "finish": {            "method": "redirect",            "uri": "https://client.foo/callback",            "nonce": "VJLO6A4CAYLBXHTR0KRO"        }    },    "client": {      "key": {        "proof": "jwsd",        "jwk": {            "kid": "gnap-rsa",            "kty": "RSA",            "e": "AQAB",            "alg": "RS256",            "n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\  YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\  YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\  ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\  3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\  N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"        }      }      "display": {        "name": "My Client Display Name",        "uri": "https://client.foo/"      },    }}

PGiVuOZUcN1tRtUS6tx2b4cBgw9mPgXG3IPB3wY7ctc

NOTE: '\' line wrapping per RFC 8792POST /gnap HTTP/1.1Host: server.example.comContent-Type: application/jsonContent-Length: 983Detached-JWS: eyJhbGciOiJSUzI1NiIsImNyZWF0ZWQiOjE2MTg4ODQ0NzUsImh0b\  SI6IlBPU1QiLCJraWQiOiJnbmFwLXJzYSIsInR5cCI6ImduYXAtYmluZGluZytqd3\  NkIiwidXJpIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vZ25hcCJ9.PGiVuO\  ZUcN1tRtUS6tx2b4cBgw9mPgXG3IPB3wY7ctc.fUq-SV-A1iFN2MwCRW_yolVtT2_\  TZA2h5YeXUoi5F2Q2iToC0Tc4drYFOSHIX68knd68RUA7yHqCVP-ZQEd6aL32H69e\  9zuMiw6O_s4TBKB3vDOvwrhYtDH6fX2hP70cQoO-47OwbqP-ifkrvI3hVgMX9TfjV\  eKNwnhoNnw3vbu7SNKeqJEbbwZfpESaGepS52xNBlDNMYBQQXxM9OqKJaXffzLFEl\  -Xe0UnfolVtBraz3aPrPy1C6a4uT7wLda3PaTOVtgysxzii3oJWpuz0WP5kRujzDF\  wX_EOzW0jsjCSkL-PXaKSpZgEjNjKDMg9irSxUISt1C1T6q3SzRgfuQ{    "access_token": {        "access": [            "dolphin-metadata"        ]    },    "interact": {        "start": ["redirect"],        "finish": {            "method": "redirect",            "uri": "https://client.foo/callback",            "nonce": "VJLO6A4CAYLBXHTR0KRO"        }    },    "client": {      "key": {        "proof": "jwsd",        "jwk": {            "kid": "gnap-rsa",            "kty": "RSA",            "e": "AQAB",            "alg": "RS256",            "n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\  YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\  YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\  ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\  3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\  N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"        }      }      "display": {        "name": "My Client Display Name",        "uri": "https://client.foo/"      },    }}

{    "proof": "jws"}

{    "alg": "RS256",    "kid": "gnap-rsa",    "uri": "https://server.example.com/gnap",    "htm": "POST",    "typ": "gnap-binding-jws",    "created": 1618884475}

NOTE: '\' line wrapping per RFC 8792{    "access_token": {        "access": [            "dolphin-metadata"        ]    },    "interact": {        "start": ["redirect"],        "finish": {            "method": "redirect",            "uri": "https://client.foo/callback",            "nonce": "VJLO6A4CAYLBXHTR0KRO"        }    },    "client": {      "key": {        "proof": "jws",        "jwk": {            "kid": "gnap-rsa",            "kty": "RSA",            "e": "AQAB",            "alg": "RS256",            "n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\  YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\  YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\  ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\  3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\  N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"        }      }      "display": {        "name": "My Client Display Name",        "uri": "https://client.foo/"      },    },    "subject": {        "formats": ["iss_sub", "opaque"]    }}

NOTE: '\' line wrapping per RFC 8792POST /gnap HTTP/1.1Host: server.example.comContent-Type: application/joseContent-Length: 1047eyJhbGciOiJSUzI1NiIsImNyZWF0ZWQiOjE2MTg4ODQ0NzUsImh0bSI6IlBPU1QiLCJ\raWQiOiJnbmFwLXJzYSIsInR5cCI6ImduYXAtYmluZGluZytqd3NkIiwidXJpIjoiaH\R0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vZ25hcCJ9.CnsKICAgICJhY2Nlc3NfdG9r\ZW4iOiB7CiAgICAgICAgImFjY2VzcyI6IFsKICAgICAgICAgICAgImRvbHBoaW4tbWV\0YWRhdGEiCiAgICAgICAgXQogICAgfSwKICAgICJpbnRlcmFjdCI6IHsKICAgICAgIC\Aic3RhcnQiOiBbInJlZGlyZWN0Il0sCiAgICAgICAgImZpbmlzaCI6IHsKICAgICAgI\CAgICAgIm1ldGhvZCI6ICJyZWRpcmVjdCIsCiAgICAgICAgICAgICJ1cmkiOiAiaHR0\cHM6Ly9jbGllbnQuZm9vL2NhbGxiYWNrIiwKICAgICAgICAgICAgIm5vbmNlIjogIlZ\KTE82QTRDQVlMQlhIVFIwS1JPIgogICAgICAgIH0KICAgIH0sCiAgICAiY2xpZW50Ij\ogewogICAgICAicHJvb2YiOiAiandzIiwKICAgICAgImtleSI6IHsKICAgICAgICAia\ndrIjogewogICAgICAgICAgICAia2lkIjogImduYXAtcnNhIiwKICAgICAgICAgICAg\Imt0eSI6ICJSU0EiLAogICAgICAgICAgICAiZSI6ICJBUUFCIiwKICAgICAgICAgICA\gImFsZyI6ICJSUzI1NiIsCiAgICAgICAgICAgICJuIjogImhZT0otWE9LSVNkTU1TaG\5fRzRXOW0yMG1UMFZXdFFCc21CQmtJMmNtUnQ0QWk4QmZZZEhzRnpBdFlLT2pwQlIxU\nBLcEptVkt4SUdOeTBnNlozYWQyWFlzaDhLb3dseVZ5OElrWjhOTXdTcmNVSUJaR1lY\akhwd2p6dmZHdlhIXzVLSmxuUjNfdVJVcDRaNFVqazJiQ2FLZWdEbjExVjJ2eEU0MWh\xYVBVbmhSWnhlMGpSRVRkZHpzRTNtdTFTSzhkVENST2p3VWwxNG1VTm84aVRyVG00bj\BxRGFkejhCa1BvLXV2NEJDMGJ1blMwSzNiQV8zVWdWcDd6QmxRRm9GbkxUTzJ1V3Bfb\XVMRVdHbDY3Z0JxOU1PM2JyS1hmR2hpM2tPenl3endQVHVxLWNWUUR5RU43YUwwU3hD\YjNIYzRJZHFEYU1nOHFIVXlPYnBQaXREUSIKICAgICAgICB9CiAgICAgIH0KICAgICA\gImRpc3BsYXkiOiB7CiAgICAgICAgIm5hbWUiOiAiTXkgQ2xpZW50IERpc3BsYXkgTm\FtZSIsCiAgICAgICAgInVyaSI6ICJodHRwczovL2NsaWVudC5mb28vIgogICAgICB9L\AogICAgfSwKICAgICJzdWJqZWN0IjogewogICAgICAgICJmb3JtYXRzIjogWyJpc3Nf\c3ViIiwgIm9wYXF1ZSJdCiAgICB9Cn0K.MwNoVMQp5hVxI0mCs9LlOUdFtkDXaA1_eT\vOXq7DOGrtDKH7q4vP2xUq3fH2jRAZqnobo0WdPP3eM3NH5QUjW8pa6_QpwdIWkK7r-\u_52puE0lPBp7J4U2w4l9gIbg8iknsmWmXeY5F6wiGT8ptfuEYGgmloAJd9LIeNvD3U\LW2h2dz1Pn2eDnbyvgB0Ugae0BoZB4f69fKWj8Z9wvTIjk1LZJN1PcL7_zT8Lrlic9a\PyzT7Q9ovkd1s-4whE7TrnGUzFc5mgWUn_gsOpsP5mIIljoEEv-FqOW2RyNYulOZl0Q\8EnnDHV_vPzrHlUarbGg4YffgtwkQhdK72-JOxYQ

8.1.Requesting Resources by Reference

Instead of sending an object describing the requested resource (Section 8),access rightsMAY be communicated as a string known tothe AS representing the access being requested. Just like access rights communicatedas an object, access rights communicated as reference strings indicate a specificaccess at a protected resource. In the following non-normative example,three distinct resource access rights are being requested.¶

"access": [    "read", "dolphin-metadata", "some other thing"]

This value is opaque to the client instance andMAY be anyvalid JSON string; therefore, it could include spaces, Unicodecharacters, and properly escaped string sequences. However, in somesituations, the value is intended to beseen and understood by the client software's developer. In such cases, theAPI designer choosing any such human-readable stringsSHOULD take stepsto ensure the string values are not easily confused by a developer,such as by limiting the strings to easily disambiguated characters.¶

This functionality is similar in practice to OAuth 2.0'sscope parameter[RFC6749], where a single stringrepresents the set of access rights requested by the client instance. As such, the referencestring could contain any valid OAuth 2.0 scope value, as inAppendix B.5. Note that the referencestring here is not bound to the same character restrictions as OAuth 2.0'sscope definition.¶

A singleaccess arrayMAY include both object-type andstring-type resource items. In this non-normative example,the client instance is requesting access to aphoto-api andfinancial-transaction API typeas well as the reference values ofread,dolphin-metadata, andsome other thing.¶

"access": [    {        "type": "photo-api",        "actions": [            "read",            "write",            "delete"        ],        "locations": [            "https://server.example.net/",            "https://resource.local/other"        ],        "datatypes": [            "metadata",            "images"        ]    },    "read",    "dolphin-metadata",    {        "type": "financial-transaction",        "actions": [            "withdraw"        ],        "identifier": "account-14-32-32-3",        "currency": "USD"    },    "some other thing"]

The requested access is the union of all elements of the array, including both objects andreference strings.¶

In order to facilitate the use of both object and reference strings to access the samekind of APIs, the API designer can define a clear mapping between these forms.One possible approach for choosing reference string values is to use the same value as thetype parameter from the fully specified object, with the API defining a set of defaultbehaviors in this case. For example, an API definition could declare the following string:¶

"access": [    "photo-api"]

As being equivalent to the following fully defined object:¶

"access": [    {        "type": "photo-api",        "actions": [ "read", "write", "delete" ],        "datatypes": [ "metadata", "image" ]    }]

The exact mechanisms for relating reference strings is up to the API designer. These are enforcedby the AS, and the details are out of scope for this specification.¶

9.1.RS-First Method of AS Discovery

If the client instance calls an RS without an access token or with an invalid access token, the RSSHOULD be explicit about the fact that GNAP needs to be used to access the resource by responding with the WWW-Authenticate header field and a GNAP challenge.¶

In some situations, the client instance might want to know with which specific AS it needs to negotiate for access to that RS.The RSMAY additionally return the followingOPTIONAL parameters:¶

as_uri:

The URI of the grant endpoint of the GNAP AS. Used by the client instance to call the AS to request an access token.¶

referrer:

The URI of the GNAP RS. Sent by the client instance in the Referer header as part of the grant request.¶

access:

An opaque access reference as defined inSection 8.1.MUST be sufficient for at least the action the client instance was attempting to take at the RS andMAY allow additional access rights as well. Sent by the client as an access right in the grant request.¶

The client instanceSHOULD then use both thereferrer andaccess parameters in its access token request. The client instanceMUST check that thereferrer parameter is equal to the URI of the RS using the simple string comparison method inSection 6.2.1 of [RFC3986].¶

The means for the RS to determine the value for theaccess reference are out of scope of this specification, but some dynamic methods are discussed in[GNAP-RS].¶

When receiving the following response from the RS:¶

NOTE: '\' line wrapping per RFC 8792WWW-Authenticate: \  GNAP as_uri=https://as.example/tx\  ;access=FWWIKYBQ6U56NL1\  ;referrer=https://rs.example

The client instance then makes a request to theas_uri as described inSection 2, with the value ofreferrer passed as an HTTP Referer header field and theaccess reference passed unchanged into theaccess array in theaccess_token portion of the request. The client instanceMAY request additional resources and other information.¶

In the following non-normative example, the client instance is requesting a single access token using the opaque access referenceFWWIKYBQ6U56NL1 received from the RS in addition to thedolphin-metadata that the client instance has been configured with out of band.¶

POST /tx HTTP/1.1Host: as.exampleReferer: https://rs.example/resourceContent-Type: application/jsonSignature-Input: sig1=...Signature: sig1=...Content-Digest: sha-256=...{    "access_token": {        "access": [            "FWWIKYBQ6U56NL1",            "dolphin-metadata"        ]    },    "client": "KHRS6X63AJ7C7C4AZ9AO"}

The client instance includes the Referer header field as a way for the AS to know that the process is initiated through a discovery process at the RS.¶

If issued, the resulting access token would contain sufficient access to be used at both referenced resources.¶

Security considerations, especially related to the potential of a compromised RS (Section 11.37) redirecting the requests of an otherwise properly authenticated client, need to be carefully considered when allowing such a discovery process. This risk can be mitigated by an alternative pre-registration process so that the client knows which AS protects which RS. There are also privacy considerations related to revealing which AS is protecting a given resource; these are discussed inSection 12.4.1.¶

9.2.Dynamic Grant Endpoint Discovery

Additional methods of discovering the appropriate grant endpoint for a given applicationare outside the scope of this specification. This limitation is intentional, as many applicationsrely on static configuration between the client instance and AS, as is common in OAuth 2.0.However, the dynamic nature of GNAP makes it a prime candidate for other extensions defining methodsfor discovery of the appropriate AS grant endpoint at runtime. Advanced use cases could definecontextual methods for securely providing this endpoint to the client instance.Furthermore, GNAP's design intentionally requires the client instance to only know the grantendpoint and not additional parameters, since other functions and values can be disclosedand negotiated during the grant process.¶

10.1.HTTP Authentication Scheme Registration

IANA has registered of the following scheme in the"HTTP Authentication Schemes" registry[Auth-Schemes] defined inSection 18.5 of [HTTP]:¶

Authentication Scheme Name:

GNAP¶

Reference:

Section 7.2 of RFC 9635¶

10.2.Media Type Registration

Per this section, IANA has registered the following media types[RFC2046] inthe "Media Types" registry[MediaTypes] as describedin[RFC6838].¶

10.3.GNAP Grant Request Parameters

This document defines a GNAP grant request, for which IANA has created and maintains a new registry titled "GNAP Grant Request Parameters". Initial values for this registry are given inSection 10.3.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The designated expert (DE) is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.3.1.¶
• The request parameter's definition is sufficiently orthogonal to existing functionality provided by existing parameters.¶
• Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.¶
• The request parameter's definition specifies the expected behavior of the AS in response to the request parameter for each potential state of the grant request.¶

10.4.GNAP Access Token Flags

This document defines GNAP access token flags, for which IANA has created and maintains a new registry titled "GNAP Access Token Flags". Initial values for this registry are given inSection 10.4.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.4.1.¶
• The flag specifies whether it applies to requests for tokens to the AS, responses with tokens from the AS, or both.¶

10.5.GNAP Subject Information Request Fields

This document defines a means to request subject information from the AS to the client instance, for which IANA has created and maintains a new registry titled "GNAP Subject Information Request Fields". Initial values for this registry are given inSection 10.5.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.5.1.¶
• Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.¶

10.6.GNAP Assertion Formats

This document defines a means to pass identity assertions between the AS and client instance, for which IANA has created and maintains a new registry titled "GNAP Assertion Formats". Initial values for this registry are given inSection 10.6.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.6.1.¶
• The definition specifies the serialization format of the assertion value as used within GNAP.¶

10.7.GNAP Client Instance Fields

This document defines a means to send information about the client instance, for which IANA has created and maintains a new registry titled "GNAP Client Instance Fields". Initial values for this registry are given inSection 10.7.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.7.1.¶
• Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.¶

10.8.GNAP Client Instance Display Fields

This document defines a means to send end-user-facing displayable information about the client instance, for which IANA has created and maintains a new registry titled "GNAP Client Instance Display Fields". Initial values for this registry are given inSection 10.8.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.8.1.¶
• Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.¶

10.9.GNAP Interaction Start Modes

This document defines a means for the client instance to begin interaction between the end user and the AS, for which IANA has created and maintains a new registry titled "GNAP Interaction Start Modes". Initial values for this registry are given inSection 10.9.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.9.1.¶
• Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.¶
• Any registration using an "object" type declares all additional parameters, their optionality, and their purpose.¶
• The start mode clearly defines what actions the client is expected to take to begin interaction, what the expected user experience is, and any security considerations for this communication from either party.¶
• The start mode documents incompatibilities with other start modes or finish methods, if applicable.¶
• The start mode provides enough information to uniquely identify the grant request during the interaction. For example, in theredirect andapp modes, this is done using a unique URI (including its parameters). In theuser_code anduser_code_uri modes, this is done using the value of the user code.¶

10.10.GNAP Interaction Finish Methods

This document defines a means for the client instance to be notified of the end of interaction between the end user and the AS, for which IANA has created and maintains a new registry titled "GNAP Interaction Finish Methods". Initial values for this registry are given inSection 10.10.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.10.1.¶
• All finish methods clearly define what actions the AS is expected to take, what listening methods the client instance needs to enable, and any security considerations for this communication from either party.¶
• All finish methods document incompatibilities with any start modes, if applicable.¶

10.11.GNAP Interaction Hints

This document defines a set of hints that a client instance can provide to the AS to facilitate interaction with the end user, for which IANA has created and maintains a new registry titled "GNAP Interaction Hints". Initial values for this registry are given inSection 10.11.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.11.1.¶
• All interaction hints clearly document the expected behaviors of the AS in response to the hint, and an AS not processing the hint does not impede the operation of the AS or client instance.¶

10.12.GNAP Grant Response Parameters

This document defines a GNAP grant response, for which IANA has created and maintains a new registry titled "GNAP Grant Response Parameters". Initial values for this registry are given inSection 10.12.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.12.1.¶
• The response parameter's definition is sufficiently orthogonal to existing functionality provided by existing parameters.¶
• Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.¶
• The response parameter's definition specifies grant states for which the client instance can expect this parameter to appear in a response message.¶

10.13.GNAP Interaction Mode Responses

This document defines a means for the AS to provide the client instance with information that is required to complete a particular interaction mode, for which IANA has created and maintains a new registry titled "GNAP Interaction Mode Responses". Initial values for this registry are given inSection 10.13.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.13.1.¶
• If the name of the registration matches the name of an interaction start mode, the response parameter is unambiguously associated with the interaction start mode of the same name.¶

10.14.GNAP Subject Information Response Fields

This document defines a means to return subject information from the AS to the client instance, for which IANA has created and maintains a new registry titled "GNAP Subject Information Response Fields". Initial values for this registry are given inSection 10.14.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.14.1.¶
• Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.¶

10.15.GNAP Error Codes

This document defines a set of errors that the AS can return to the client instance, for which IANA has created and maintains a new registry titled "GNAP Error Codes". Initial values for this registry are given inSection 10.15.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.15.1.¶
• The error response is sufficiently unique from other errors to provide actionable information to the client instance.¶
• The definition of the error response specifies all conditions in which the error response is returned and the client instance's expected action.¶

10.16.GNAP Key Proofing Methods

This document defines methods that the client instance can use to prove possession of a key, for which IANA has created and maintains a new registry titled "GNAP Key Proofing Methods". Initial values for this registry are given inSection 10.16.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.16.1.¶
• Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.¶
• The proofing method provides sufficient coverage of and binding to the protocol messages to which it is applied.¶
• The proofing method definition clearly enumerates how all requirements inSection 7.3 are fulfilled by the definition.¶

10.17.GNAP Key Formats

This document defines formats for a public key value, for which IANA has created and maintains a new registry titled "GNAP Key Formats". Initial values for this registry are given inSection 10.17.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.17.1.¶
• The key format specifies the structure and serialization of the key material.¶

10.18.GNAP Authorization Server Discovery Fields

This document defines a discovery document for an AS, for which IANA has created and maintains a new registry titled "GNAP Authorization Server Discovery Fields". Initial values for this registry are given inSection 10.18.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy[RFC8126].¶

The DE is expected to ensure the following:¶

• All registrations follow the template presented inSection 10.18.1.¶
• Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.¶
• The values in the discovery document are sufficient to provide optimization and hints to the client instance, but knowledge of the discovered value is not required for starting a transaction with the AS.¶

11.1.TLS Protection in Transit

All requests in GNAP made over untrusted network connections have to be made over TLS as outlined in[BCP195]to protect the contents of the request and response from manipulation and interception by an attacker.This includes all requests from a client instance to the AS, all requests from the client instance toan RS, and any requests back to a client instance such as the push-based interaction finish method.Additionally, all requests between a browser and other components, such as during redirect-basedinteraction, need to be made over TLS or use equivalent protection such as a network connection local to the browser ("localhost").¶

Even though requests from the client instance to the AS are signed, the signature method alone does not protectthe request from interception by an attacker. TLS protects the response as well as the request,preventing an attacker from intercepting requested information as it is returned. This is particularlyimportant in this specification for security artifacts such as nonces and forpersonal information such as subject information.¶

The use of key-bound access tokens does not negate the requirement for protecting calls to the RS with TLS.The keys and signatures associated with a bound access token will prevent an attacker from using a stolentoken; however, without TLS, an attacker would be able to watch the data being sent to the RS and returned from the RSduring legitimate use of the client instance under attack. Additionally, without TLS, an attacker would beable to profile the calls made between the client instance and RS, possibly gaining information about the functioningof the API between the client software and RS software that would otherwise be unknown to the attacker.¶

Note that connections from the end user and RO's browser also need to be protected with TLS. This applies during initialredirects to an AS's components during interaction, during any interaction with the RO, and duringany redirect back to the client instance. Without TLS protection on these portions of the process, anattacker could wait for a valid request to start and then take over the RO's interaction session.¶

11.2.Signing Requests from the Client Software

Even though all requests in GNAP need to be transmitted over TLS or its equivalent, the use of TLSalone is not sufficient to protect all parts of a multi-party and multi-stage protocol like GNAP,and TLS is not targeted at tying multiple requests to each other over time.To account for this, GNAP makes use of message-level protection and key presentation mechanismsthat strongly associate a request with a key held by the client instance (seeSection 7).¶

During the initial request from a client instance to the AS, the client instance has to identify andprove possession of a cryptographic key. If the key is known to the AS, e.g., previouslyregistered or dereferenceable to a trusted source, the AS can associate a set of policies to theclient instance identified by the key. Without the requirement that the client instance prove that it holdsthat key, the AS could not trust that the connection came from any particular client and couldnot apply any associated policies.¶

Even more importantly, the client instance proving possession of a key on the first request allows the AS to associate future requests with each other by binding all future requests in that transaction to the same key. The access token used for grant continuation is bound to the same key and proofing mechanism used by the client instance in its initial request; this means that the client instance needs to prove possession of that same key in future requests, which allows the AS to be sure that the same client instance is executing the follow-ups for a given ongoing grant request. Therefore, the AS has to ensure that all subsequent requests for a grant are associated with the same key that started the grant or with the most recent rotation of that key. This need holds true even if the initial key is previously unknown to the AS, such as would be the case when a client instance creates an ephemeral key for its request. Without this ongoing association, an attacker would be able to impersonate a client instance in the midst of a grant request, potentially stealing access tokens and subject information with impunity.¶

Additionally, all access tokens in GNAP default to be associated with the key that was presentedduring the grant request that created the access token. This association allows an RS to know thatthe presenter of the access token is the same party that the token was issued to, as identifiedby their keys. While non-bound bearer tokens are an option in GNAP, these types of tokenshave their own trade-offs, which are discussed inSection 11.9.¶

TLS functions at the transport layer, ensuring that only the parties on either end of thatconnection can read the information passed along that connection. Each time a new connectionis made, such as for a new HTTP request, a new trust that is mostly unrelated to previousconnections is re-established. While modern TLS does make use of session resumption, this still needs to be augmentedwith authentication methods to determine the identity of parties on theconnections. In other words, it is not possible with TLS alone to know that the same party is makinga set of calls over time, since each time a new TLS connection is established, both the client and the server (or the server only when using MTLS (Section 7.3.2)) have to validatethe other party's identity. Such a verification can be achieved via methods described in[RFC9525], but these are not enough to establish the identity of the client instance in many cases.¶

To counter this, GNAP defines a set of key binding methods inSection 7.3 that allows authentication andproof of possession by the caller, which is usually the client instance. These methods are intended to be used inaddition to TLS on all connections.¶

11.3.MTLS Message Integrity

The MTLS key proofing mechanism (Section 7.3.2) provides a means for a client instance to present a keyusing a certificate at the TLS layer. Since TLS protects the entire HTTP message in transit,verification of the TLS client certificate presented with the message provides a sufficient bindingbetween the two. However, since TLS is functioning at a separate layer from HTTP, there is nodirect connection between the TLS key presentation and the message itself, other than the fact thatthe message was presented over the TLS channel. That is to say, any HTTP message can be presentedover the TLS channel in question with the same level of trust. The verifier is responsible forensuring the key in the TLS client certificate is the one expected for a particular request. Forexample, if the request is a grant request (Section 2), the AS needs to compare the TLS clientcertificate presented at the TLS layer to the key identified in the request content itself (eitherby value or through a referenced identifier).¶

Furthermore, the prevalence of the TLS terminating reverse proxy (TTRP) pattern in deployments addsa wrinkle to the situation. In this common pattern, the TTRP validates the TLS connection and then forwards the HTTP message contents onward to an internal system for processing. The systemprocessing the HTTP message no longer has access to the original TLS connection's information andcontext.To compensate for this, the TTRP could inject the TLS client certificate intothe forwarded request using the HTTP Client-Cert header field[RFC9111], giving the downstream system access to the certificateinformation. The TTRP has to be trusted to provide accurate certificateinformation, and the connection between the TTRP and the downstream systemalso has to be protected. The TTRP could provide some additional assurance,for example, by adding its own signature to the Client-Cert header field usingHTTP message signatures[RFC9421]. This signature would beeffectively ignored by GNAP (since it would not use GNAP'stagparameter value) but would be understood by the downstream service as part ofits deployment.¶

Additional considerations for different types of deployment patterns and key distributionmechanisms for MTLS are found inSection 11.4.¶

11.4.MTLS Deployment Patterns

GNAP does not specify how a client instance's keys could be made known to the AS ahead of time.The Public Key Infrastructure (PKI) can be used to manage the keys used by client instances when callingthe AS, allowing the AS to trust a root key from a trusted authority. This method is particularlyrelevant to the MTLS key proofing method, where the client instancepresents its certificate to the AS as part of the TLS connection. An AS using PKI to validate theMTLS connection would need to ensure that the presented certificate was issued by a trusted certificateauthority before allowing the connection to continue. PKI-based certificates would allow a key to be revokedand rotated through management at the certificate authority without requiring additional registrationor management at the AS. The PKI required to manage mutually authenticated TLS has historically beendifficult to deploy, especially at scale, but it remains an appropriate solution for systems wherethe required management overhead is not an impediment.¶

MTLS in GNAP need not use a PKI backing, as self-signed certificates and certificates from untrustedauthorities can still be presented as part of a TLS connection. In this case, the verifier wouldvalidate the connection but accept whatever certificate was presented by the client software. Thisspecific certificate can then be bound to all future connections from that client software bybeing bound to the resulting access tokens, in a trust-on-first-use pattern. SeeSection 11.3for more considerations on MTLS as a key proofing mechanism.¶

11.5.Protection of Client Instance Key Material

Client instances are identified by their unique keys, and anyone with access to a client instance's key materialwill be able to impersonate that client instance to all parties. This is true for both calls to the ASas well as calls to an RS using an access token bound to the client instance's unique key. As a consequence, it is of utmost importance for a client instance to protect its private key material.¶

Different types of client software have different methods for creating, managing, and registeringkeys. GNAP explicitly allows for ephemeral clients such as single-page applications (SPAs) and single-user clients (such asmobile applications) to create and present their own keys during the initial grant request without any explicit pre-registration step. The clientsoftware can securely generate a key pair on the device and present the public key, along with proof of holding the associatedprivate key, to the AS as part of the initial request. To facilitate trust in these ephemeral keys,GNAP further allows for an extensible set of client information to be passed with the request. Thisinformation can include device posture and third-party attestations of the client software's provenanceand authenticity, depending on the needs and capabilities of the client software and its deployment.¶

From GNAP's perspective, each distinct key is a different client instance. However, multiple clientinstances can be grouped together by an AS policy and treated similarly to each other. For instance,if an AS knows of several different keys for different servers within a cluster, the AS candecide that authorization of one of these servers applies to all other servers within the cluster. An ASthat chooses to do this needs to be careful with how it groups different client keys together in its policy,since the breach of one instance would have direct effects on the others in the cluster.¶

Additionally, if an end user controls multiple instances of a single type of client software, such ashaving an application installed on multiple devices, each of these instances is expected to have aseparate key and be issued separate access tokens. However, if the AS is able to group these separateinstances together as described above, it can streamline the authorization process for new instancesof the same client software. For example, if two client instances can present proof of a valid installationof a piece of client software, the AS would be able to associate the approval of the first instance of thissoftware to all related instances. The AS could then choose to bypass an explicit prompt of the RO for approval during authorization, since such approval has already been given. An AS doing sucha process would need to take assurance measures that the different instances are in fact correlatedand authentic, as well as ensure that the expected RO is in control of the client instance.¶

Finally, if multiple instances of client software each have the same key, then from GNAP's perspective,these are functionally the same client instance as GNAP has no reasonable way to differentiate betweenthem. This situation could happen if multiple instances within a cluster can securely share secretinformation among themselves. Even though there are multiple copies of the software, the shared keymakes these copies all present as a single instance. It is considered bad practice to share keys betweencopies of software unless they are very tightly integrated with each other and can be closely managed.It is particularly bad practice to allow an end user to copy keys between client instances and towillingly use the same key in multiple instances.¶

11.6.Protection of Authorization Server

The AS performs critical functions in GNAP, including authenticating client software, managing interactionswith end users to gather consent and provide notice, and issuing access tokens for client instancesto present to RSs. As such, protecting the AS is central to any GNAP deployment.¶

If an attacker is able to gain control over an AS, they would be able to create fraudulent tokens andmanipulate registration information to allow for malicious clients. These tokens and clients wouldbe trusted by other components in the ecosystem under the protection of the AS.¶

If the AS uses signed access tokens, an attacker in control of the AS's signing keys wouldbe able to manufacture fraudulent tokens for use at RSs under the protection of the AS.¶

If an attacker is able to impersonate an AS, they would be able to trick legitimate client instancesinto making signed requests for information that could potentially be proxied to a real AS. To combatthis, all communications to the AS need to be made over TLS or its equivalent, and the softwaremaking the connection has to validate the certificate chain of the host it is connecting to.¶

Consequently, protecting, monitoring, and auditing the AS is paramount to preserving the securityof a GNAP-protected ecosystem. The AS presents attackers with a valuable target for attack.Fortunately, the core focus and function of the AS is to provide security for the ecosystem, unlikethe RS whose focus is to provide an API or the client software whose focus is to access the API.¶

11.7.Symmetric and Asymmetric Client Instance Keys

Many of the cryptographic methods used by GNAP for key proofing can support both asymmetric and symmetriccryptography, and they can be extended to use a wide variety of mechanisms.Implementors will find the available guidelines on cryptographic key management provided in[RFC4107] useful. While symmetriccryptographic systems have some benefits in speed and simplicity, they have a distinct drawback --both parties need access to the same key in order to do both signing and verification ofthe message.When more than two parties share the same symmetric key,data origin authentication is not provided. Any party that knows thesymmetric key can compute a valid MAC; therefore, thecontents could originate from any one of the parties.¶

Use of symmetric cryptography means that when the client instance calls the AS to request a token, theAS needs to know the exact value of the client instance's key (or be able to derive it) inorder to validate the key proof signature. With asymmetric keys, the client needs to onlysend its public key to the AS to allow for verification that the client holds the associatedprivate key, regardless of whether or not that key was pre-registered with the AS.¶

Symmetric keys also have the expected advantage of providing better protection against quantumthreats in the future. Also, these types of keys (and their secure derivations) are widelysupported among many cloud-based key management systems.¶

When used to bind to an access token, a key value must be known by the RS in orderto validate the proof signature on the request. Common methods for communicating these proofingkeys include putting information in a structured access token and allowing the RS to lookup the associated key material against the value of the access token. With symmetric cryptography,both of these methods would expose the signing key to the RS and, in the case of a structuredaccess token, potentially to any party that can see the access token itself unless the token'spayload has been encrypted. Any of these parties would then be able to make calls using theaccess token by creating a valid signature using the shared key. With asymmetric cryptography, the RS needsto only know the public key associated with the token in order to validate the request; therefore, the RS cannotcreate any new signed calls.¶

While both signing approaches are allowed, GNAP treats these two classes of keys somewhatdifferently. Only the public portion of asymmetric keys are allowed to be sent by valuein requests to the AS when establishing a connection. Since sending a symmetric key (orthe private portion of an asymmetric key) would expose the signing material to any partieson the request path, including any attackers, sending these kinds of keys by value is prohibited.Symmetric keys can still be used by client instances, but only if the client instance can send a reference to the key andnot its value. This approach allows the AS to use pre-registered symmetric keys as wellas key derivation schemes to take advantage of symmetric cryptography without requiringkey distribution at runtime, which would expose the keys in transit.¶

Both the AS and client software can use systems such as hardware security modules to strengthentheir key security storage and generation for both asymmetric and symmetric keys (see alsoSection 7.1.2).¶

11.8.Generation of Access Tokens

The contents of access tokens need to be such that only the generating AS would be able tocreate them, and the contents cannot be manipulated by an attacker to gain different or additionalaccess rights.¶

One method for accomplishing this is to use a cryptographically random value for the access token,generated by the AS using a secure randomization function with sufficiently high entropy. The odds ofan attacker guessing the output of the randomization function to collide with a valid access tokenare exceedingly small, and even then, the attacker would not have any control over what theaccess token would represent since that information would be held close by the AS.¶

Another method for accomplishing this is to use a structured token that is cryptographically signed.In this case, the payload of the access token declares to the RS what the token is good for, butthe signature applied by the AS during token generation covers this payload. Only the AS can createsuch a signature; therefore, only the AS can create such a signed token. The odds of an attackerbeing able to guess a signature value with a useful payload are exceedingly small. This techniqueonly works if all targeted RSs check the signature of the access token. Any RS that does notvalidate the signature of all presented tokens would be susceptible to injection of a modifiedor falsified token. Furthermore, an AS has to carefully protect the keys used to sign accesstokens, since anyone with access to these signing keys would be able to create seemingly validaccess tokens using them.¶

11.9.Bearer Access Tokens

Bearer access tokens can be used by any party that has access to the token itself, without any additionalinformation. As a natural consequence, any RS that a bearer token is presented to has the technicalcapability of presenting that bearer token to another RS, as long as the token is valid. It alsomeans that any party that is able to capture the token value in storage or in transit is able touse the access token. While bearer tokens are inherently simpler, this simplicity has been misappliedand abused in making needlessly insecure systems. The downsides of bearer tokens have become morepertinent lately as stronger authentication systems have caused some attacks to shift to targettokens and APIs.¶

In GNAP, key-bound access tokens are the default due to their higher security properties. Whilebearer tokens can be used in GNAP, their use should be limited to cases where the simplicitybenefits outweigh the significant security downsides. One common deployment pattern is to use agateway that takes in key-bound tokens on the outside and verifies the signatures on the incomingrequests but translates the requests to a bearer token for use by trusted internal systems. Thebearer tokens are never issued or available outside of the internal systems, greatly limiting theexposure of the less-secure tokens but allowing the internal deployment to benefit from theadvantages of bearer tokens.¶

11.10.Key-Bound Access Tokens

Key-bound access tokens, as the name suggests, are bound to a specific key and must bepresented along with proof of that key during use. The key itself is not presented at the sametime as the token, so even if a token value is captured, it cannot be used to make a new request. Thisis particularly true for an RS, which will see the token value but will not see the keys usedto make the request (assuming asymmetric cryptography is in use, seeSection 11.7).¶

Key-bound access tokens provide this additional layer of protection only when the RS checks thesignature of the message presented with the token. Acceptance of an invalid presentation signature,or failure to check the signature entirely, would allow an attacker to make calls with a capturedaccess token without having access to the related signing key material.¶

In addition to validating the signature of the presentation message itself,the RS also needs to ensure that the signing key used is appropriate for the presented token.If an RS does not ensure that the right keys were used to sign a message with a specifictoken, an attacker would be able to capture an access token and sign the request with their ownkeys, thereby negating the benefits of using key-bound access tokens.¶

The RS also needs to ensure that sufficient portions of the message are covered by thesignature. Any items outside the signature could still affect the API's processing decisions,but these items would not be strongly bound to the token presentation. As such, an attackercould capture a valid request and then manipulate portions of the request outside of thesignature envelope in order to cause unwanted actions at the protected API.¶

Some key-bound tokens are susceptible to replay attacks, depending on the details of the signing methodused. Therefore, key proofing mechanisms used with access tokens needto use replay-protection mechanisms covered under the signature such as a per-message nonce, areasonably short time validity window, or other uniqueness constraints. The details of using thesewill vary depending on the key proofing mechanism in use. For example, HTTP message signatureshave both acreated andnonce signature parameter as well as the ability to cover significantportions of the HTTP message. All of these can be used to limit the attack surface.¶

11.11.Exposure of End-User Credentials to Client Instance

As a delegation protocol, one of the main goals of GNAP is to prevent the client software from beingexposed to any credentials or information about the end user or RO as a requirementof the delegation process. By using the variety of interaction mechanisms, the RO caninteract with the AS without ever authenticating to the client software and without the clientsoftware having to impersonate the RO through replay of their credentials.¶

Consequently, no interaction methods defined in this specification require the end user to enter theircredentials, but it is technologically possible for an extension to be defined to carry such values.Such an extension would be dangerous as it would allow rogue client software to directly collect, store,and replay the end user's credentials outside of any legitimate use within a GNAP request.¶

The concerns of such an extension could be mitigated through use of a challenge and responseunlocked by the end user's credentials. For example, the AS presents a challenge as part ofan interaction start method, and the client instance signs that challenge using a key derivedfrom a password presented by the end user. It would be possible for the client software tocollect this password in a secure software enclave without exposing the password to the restof the client software or putting it across the wire to the AS. The AS can validate this challengeresponse against a known password for the identified end user. While an approach such as this doesnot remove all of the concerns surrounding such a password-based scheme, it is at leastpossible to implement in a more secure fashion than simply collecting and replayingthe password. Even so, such schemes should only ever be used by trusted clients due tothe ease of abusing them.¶

11.12.Mixing Up Authorization Servers

If a client instance is able to work with multiple ASes simultaneously, it is possiblefor an attacker to add a compromised AS to the client instance's configuration and cause theclient software to start a request at the compromised AS. This AS could then proxy the client'srequest to a valid AS in order to attempt to get the RO to approve access forthe legitimate client instance.¶

A client instance needs to always be aware of which AS it is talking to throughout a grant process and ensurethat any callback for one AS does not get conflated with the callback to different AS. The interaction finishhash calculation inSection 4.2.3 allows a client instance to protect against this kind of substitution, but only ifthe client instance validates the hash. If the client instance does not use an interaction finish methodor does not check the interaction finish hash value, the compromised AS can be granted a validaccess token on behalf of the RO. See Sections 4.5.5 and 5.5 of[AXELAND2021] for detailsof one such attack, which has been addressed in this document by including the grant endpointin the interaction hash calculation. Note that the client instance still needs to validate the hash forthe attack to be prevented.¶

11.13.Processing of Client-Presented User Information

GNAP allows the client instance to present assertions and identifiers of the current user to the AS aspart of the initial request. This information should only ever be taken by the AS as a hint, since theAS has no way to tell if the represented person is present at the client software without usingan interaction mechanism. This information does not guarantee the given user is there, but it doesconstitute a statement by the client software that the AS can take into account.¶

For example, if a specific user is claimed to be present prior to interaction, but a different useris shown to be present during interaction, the AS can either determine this to be an error or signalto the client instance through returned subject information that the current user has changed fromwhat the client instance thought. This user information can also be used by the AS to streamline theinteraction process when the user is present. For example, instead of having the user type in theiraccount identifier during interaction at a redirected URI, the AS can immediately challenge the userfor their account credentials. Alternatively, if an existing session is detected, the AS candetermine that it matches the identifier provided by the client and subsequently skip an explicitauthentication event by the RO.¶

In cases where the AS trusts the client software more completely, due to policyor previous approval of a given client instance, the AS can take this user information as astatement that the user is present and could issue access tokens and release subject informationwithout interaction. The AS should only take such action in very limited circumstances, as aclient instance could assert whatever it likes for the user's identifiers in its request. The AScan limit the possibility of this by issuing randomized opaque identifiers to client instances torepresent different end-user accounts after an initial login.¶

When a client instance presents an assertion to the AS, the AS needs to evaluate that assertion. Sincethe AS is unlikely to be the intended audience of an assertion held by the client software, the AS willneed to evaluate the assertion in a different context. Even in this case, the AS can still evaluatethat the assertion was generated by a trusted party, was appropriately signed, and is withinany time validity windows stated by the assertion. If the client instance's audience identifieris known to the AS and can be associated with the client instance's presented key, the AS can alsoevaluate that the appropriate client instance is presenting the claimed assertion. All of thiswill prevent an attacker from presenting a manufactured assertion or one captured from anuntrusted system. However, without validating the audience of the assertion, a captured assertioncould be presented by the client instance to impersonate a given end user. In such cases, the assertionoffers little more protection than a simple identifier would.¶

A special case exists where the AS is the generator of the assertion being presented by theclient instance. In these cases, the AS can validate that it did issue the assertion andit is associated with the client instance presenting the assertion.¶

11.14.Client Instance Pre-registration

Each client instance is identified by its own unique key, and for some kinds of client software such as aweb server or backend system, this identification can be facilitated by registering a single key for a pieceof client software ahead of time. This registration can be associated with a set of display attributes tobe used during the authorization process to identify the client software to the user. In these cases,it can be assumed that only one instance of client software will exist, likely to serve many differentusers.¶

A client's registration record needs to include its identifying key. Furthermore, it is the case thatany clients using symmetric cryptography for key proofing mechanisms need to have their keys pre-registered.The registration should also include any information that would aid in the authorization process, such asa display name and logo.The registration record can also limit a given client toask for certain kinds of information or usespecific interaction mechanisms at runtime.¶

It also is sensible to pre-register client instances when the software is acting autonomously, withoutthe need for a runtime approval by an RO or any interaction with an end user. In these cases,an AS needs to rely on the trust decisions that have been determined prior to runtime to determinewhat rights and tokens to grant to a given client instance.¶

However, it does not make sense to pre-register many types of clients. Single-page applications (SPAs) andmobile/desktop applications in particular present problems with pre-registration. For SPAs, the instancesare ephemeral in nature, and long-term registration of a single instance leads to significant storage andmanagement overhead at the AS. For mobile applications, each installation of the client software isa separate instance, and sharing a key among all instances would be detrimental to security as thecompromise of any single installation would compromise all copies for all users.¶

An AS can treat these classes of client software differently from each other, perhaps by allowing accessto certain high-value APIs only to pre-registered known clients or by requiring an active end-userdelegation of authority to any client software not pre-registered.¶

An AS can also provide warnings and caveats to ROs during the authorization process, allowingthe user to make an informed decision regarding the software they are authorizing. For example, if the AShas vetted the client software and this specific instance, it can present a different authorizationscreen compared to a client instance that is presenting all of its information at runtime.¶

Finally, an AS can use platform attestations and other signals from the client instance at runtimeto determine whether or not the software making the request is legitimate. The details of suchattestations are outside the scope of this specification, but theclient portion of a grant requestprovides a natural extension point to such information through the "GNAP Client Instance Fields" registry (Section 10.7).¶

11.15.Client Instance Impersonation

If client instances are allowed to set their own user-facing display information, such as a display name and websiteURL, a malicious client instance could impersonate legitimate client software for the purposes of trickingusers into authorizing the malicious client.¶

Requiring clients to pre-register does not fully mitigate this problem since many pre-registrationsystems have self-service portals for management of client registration, allowing authenticated developersto enter self-asserted information into the management portal.¶

An AS can mitigate this by actively filtering all self-asserted values presented by client software,both dynamically as part of GNAP and through a registration portal, to limit the kinds of impersonation that could be done.¶

An AS can also warn the RO about the provenance of the information it is displaying, allowingthe RO to make a more informed delegation decision. For example, an AS can visually differentiatebetween a client instance that can be traced back to a specific developer's registration and aninstance that has self-asserted its own display information.¶

11.16.Client-Hosted Logo URI

Thelogo_uri client display field defined inSection 2.3.2 allows the client instance to specifya URI from which an image can be fetched for display during authorization decisions. When the URI points toan externally hosted resource (as opposed to a data: URI), thelogo_uri field presents challenges in addition to theconsiderations inSection 11.15.¶

When alogo_uri is externally hosted, the client software (or the host of the asset) can change the contents ofthe logo without informing the AS. Since the logo is considered an aspect of the client software's identity,this flexibility allows for a more dynamically managed client instance that makes use of the distributed systems.¶

However, this same flexibility allows the host of the asset to change the hosted file in a malicious way,such as replacing the image content with malicious software for download or imitating a different pieceof client software. Additionally, the act of fetching the URI could accidentally leak information to the image hostin the HTTP Referer header field, if one is sent. Even though GNAP intentionally does not include securityparameters in front-channel URIs wherever possible, the AS still should take steps to ensure thatthis information does not leak accidentally, such as setting a referrer policy on image links ordisplaying images only from pages served from a URI with no sensitive security or identity information.¶

To avoid these issues, the AS can insist on the use of data: URIs, though that might not be practical for alltypes of client software. Alternatively, the AS could pre-fetch the content of the URI and present its own copyto the RO instead. This practice opens the AS to potential SSRF attacks, as discussed inSection 11.34.¶

11.17.Interception of Information in the Browser

Most information passed through the web browser is susceptible to interception and possible manipulation byelements within the browser such as scripts loaded within pages. Information in the URI is exposedthrough browser and server logs, and it can also leak to other parties through HTTPReferer headers.¶

GNAP's design limits the information passed directly through the browser, allowing for opaque URIs in most circumstances.For the redirect-based interaction finish mechanism, named query parameters are used to carryunguessable opaque values. For these, GNAP requires creation and validation of a cryptographichash to protect the query parameters added to the URI and associate them with an ongoing grantprocess and values not passed in the URI. The client instance has to properly validate this hash to prevent an attacker frominjecting an interaction reference intended for a different AS or client instance.¶

Several interaction start mechanisms use URIs created by the AS and passed to the client instance.While these URIs are opaque to the client instance, it's possible for the AS to include parameters,paths, and other pieces of information that could leak security data or be manipulated by a partyin the middle of the transaction. An AS implementation can avoid this problem by creating URIsusing unguessable values that are randomized for each new grant request.¶

11.18.Callback URI Manipulation

The callback URI used in interaction finish mechanisms is defined by the client instance. This URI isopaque to the AS but can contain information relevant to the client instance's operations. Inparticular, the client instance can include state information to allow the callback request tobe associated with an ongoing grant request.¶

Since this URI is exposed to the end user's browser, it is susceptible to both logging and manipulationin transit before the request is made to the client software. As such, a client instance shouldnever put security-critical or private information into the callback URI in a cleartext form. For example,if the client software includes a post-redirect target URI in its callback URI to the AS, this target URIcould be manipulated by an attacker, creating an open redirector at the client. Instead,a client instance can use an unguessable identifier in the URI that can then be used by the clientsoftware to look up the details of the pending request. Since this approach requires some form of statefulnessby the client software during the redirection process, clients that are not capable of holding statethrough a redirect should not use redirect-based interaction mechanisms.¶

11.19.Redirection Status Codes

As described in[OAUTH-SEC-TOPICS], a server should never use HTTP status code 307 (Temporary Redirect) to redirect a request that potentially contains user credentials. If an HTTP redirect is used for such a request, HTTP status code 303 (See Other) should be used instead.¶

Status code 307 (Temporary Redirect), as defined in the HTTP standard[HTTP], requires the user agent to preserve the method and content of a request, thus submitting the content of the POST request to the redirect target. In the HTTP standard[HTTP], only status code 303 (See Other) unambiguously enforces rewriting the HTTP POST request to an HTTP GET request, which eliminates the POST content from the redirected request. For all other status codes, including status code 302 (Found), user agents are allowed to keep a redirected POST request as a POST and thus can resubmit the content.¶

The use of status code 307 (Temporary Redirect) results in a vulnerability when using theredirect interaction finish method (Section 3.3.5). With this method, the ASpotentially prompts the RO to enter their credentials in a form that is then submitted back to theAS (using an HTTP POST request). The AS checks the credentials and, if successful, may immediatelyredirect the RO to the client instance's redirect URI. Due to the use of status code 307 (Temporary Redirect), the RO'suser agent now transmits the RO's credentials to the client instance. A malicious client instancecan then use the obtained credentials to impersonate the RO at the AS.¶

Redirection away from the initial URI in an interaction session could also leak information found in thatinitial URI through the HTTP Referer header field, which would be sent by the user agent to the redirecttarget. To avoid such leakage, a server can first redirect to an internal interstitial page without any identifyingor sensitive information on the URI before processing the request. When the user agent is ultimatelyredirected from this page, no part of the original interaction URI will be found in the Referer header.¶

11.20.Interception of Responses from the AS

Responses from the AS contain information vital to both the security and privacy operations ofGNAP. This information includes nonces used in cryptographic calculations, Subject Identifiers,assertions, public keys, and information about what client software is requesting and was granted.¶

In addition, if bearer tokens are used or keys are issued alongside a bound access token, theresponse from the AS contains all information necessary for use of the contained access token. Anyparty that is capable of viewing such a response, such as an intermediary proxy, would be ableto exfiltrate and use this token. If the access token is instead bound to the client instance'spresented key, intermediaries no longer have sufficient information to use the token. They canstill, however, gain information about the end user as well as the actions of the client software.¶

11.21.Key Distribution

GNAP does not define ways for the client instances keys to be provided to the client instances,particularly in light of how those keys are made known to the AS. These keys could begenerated dynamically on the client software or pre-registered at the AS in a static developer portal.The keys for client instances could also be distributed as part of the deployment process of instancesof the client software. For example, an application installation framework could generatea key pair for each copy of client software and then both install it into the client softwareupon installation and register that instance with the AS.¶

Alternatively, it's possible for the AS to generate keys to be used with access tokens thatare separate from the keys used by the client instance to request tokens. In this method,the AS would generate the asymmetric key pair or symmetric key and return the public key or keyreference to the client instance alongside the accesstoken itself. The means for the AS to return generated key values to the client instanceare out of scope, since GNAP does not allow the transmission of private or shared keyinformation within the protocol itself.¶

Additionally, if the token is bound to a key other than the client instance's presented key, thisopens a possible attack surface for an attacker's AS to request an access token and then substitutetheir own key material in the response to the client instance. The attacker's AS would need tobe able to use the same key as the client instance, but this setup would allow an attacker's ASto make use of a compromised key within a system. This attack can be prevented by only bindingaccess tokens to the client instance's presented keys and by having client instances have a strongassociation between which keys they expect to use and the AS they expect to use them on.This attack is also only able to be propagated on client instances that talk to more thanone AS at runtime, which can be limited by the client software.¶

11.22.Key Rotation Policy

When keys are rotated, there could be a delay in the propagation of that rotation to various components in the AS's ecosystem. The AS can define its own policy regarding the timeout of the previously bound key, either making it immediately obsolete or allowing for a limited grace period during which both the previously bound key and the current key can be used for signing requests. Such a grace period can be useful when there are multiple running copies of the client that are coordinated with each other. For example, the client software could be deployed as a cloud service with multiple orchestrated nodes. Each of these copies is deployed using the same key; therefore, all the nodes represent the same client instance to the AS. In such cases, it can be difficult, or even impossible, to update the keys on all these copies in the same instant.¶

The need to accommodate such known delays in the system needs to be balanced with the risk of allowing an old key to still be used. Narrowly restricting the exposure opportunities for exploit at the AS in terms of time, place, and method makes exploit significantly more difficult, especially if the exception happens only once. For example, the AS can reject requests from the previously bound key (or any previous one before it) to cause rotation to a new key or at least ensure that the rotation happens in an idempotent way to the same new key.¶

See also the related considerations for token values inSection 11.33.¶

11.23.Interaction Finish Modes and Polling

During the interaction process, the client instance usually hands control of the user experienceover to another component, be it the system browser, another application, or some actionthe RO is instructed to take on another device. By using an interaction finishmethod, the client instance can be securely notified by the AS when the interaction is completedand the next phase of the protocol should occur. This process includes information that theclient instance can use to validate the finish call from the AS and prevent some injection,session hijacking, and phishing attacks.¶

Some types of client deployment are unable to receive an interaction finish message.Without an interaction finish method to notify it, the client instance will need to poll thegrant continuation API while waiting for the RO to approve or deny the request.An attacker could take advantage of this situation by capturing the interaction startparameters and phishing a legitimate user into authorizing the attacker's waitingclient instance, which would in turn have no way of associating the completed interactionfrom the targeted user with the start of the request from the attacker.¶

However, it is important to note that this pattern is practically indistinguishablefrom some legitimate use cases. For example, a smart device emits a code forthe RO to enter on a separate device. The smart device has to pollbecause the expected behavior is that the interaction will take place on the separatedevice, without a way to return information to the original device's context.¶

As such, developers need to weigh the risks of forgoing an interaction finishmethod against the deployment capabilities of the client software and itsenvironment. Due to the increased security, an interaction finish method shouldbe employed whenever possible.¶

11.24.Session Management for Interaction Finish Methods

When using an interaction finish method such asredirect orpush, the client instance receivesan unsolicited inbound request from an unknown party over HTTPS. The clientinstance needs to be able to successfully associate this incoming request with a specific pendinggrant request being managed by the client instance. If the client instance is not careful and precise aboutthis, an attacker could associate their own session at the client instance with a stolen interactionresponse. The means of preventing this vary by the type of client software and interaction methods in use.Some common patterns are enumerated here.¶

If the end user interacts with the client instance through a web browser and theredirectinteraction finish method is used, the client instance can ensure that the incoming HTTP requestfrom the finish method is presented in the same browser session that the grant request wasstarted in. This technique is particularly useful when theredirect interaction start modeis used as well, since in many cases, the end user will follow the redirection with thesame browser that they are using to interact with the client instance.The client instance can then store the relevant pending grant information in thesession, either in the browser storage directly (such as with a single-page application) orin an associated session store on a backend server. In both cases, when the incoming requestreaches the client instance, the session information can be used to ensure that the same partythat started the request is present as the request finishes.¶

Ensuring that the same party that started a request is present when that request finishes canprevent phishing attacks, where an attacker starts a request at an honest client instance andtricks an honest RO into authorizing it. For example, if an honest end user (that also acts as theRO) wants to start a request through a client instance controlled by the attacker, the attacker canstart a request at an honest client instance and then redirect the honest end user to theinteraction URI from the attackers session with the honest client instance. If the honest end userthen fails to realize that they are not authorizing the attacker-controlled client instance (with whichit started its request) but instead the honest client instance when interacting with the AS, the attacker'ssession with the honest client instance would be authorized. This would give the attacker access tothe honest end user's resources that the honest client instance is authorized to access. However,if after the interaction, the AS redirects the honest end user back to the client instance whosegrant request the end user just authorized, the honest end user is redirected to the honest clientinstance. The honest client instance can then detect that the end user is not the party that started therequest, since the request at the honest client instance was started by theattacker. This detection can prevent the attack. This is related to the discussion inSection 11.15, because againthe attack can be prevented by the AS informing the user as much as possible about the clientinstance that is to be authorized.¶

If the end user does not interact with the client instance through a web browser or the interactionstart method does not use the same browser or device that the end user is interacting through(such as the launch of a second device through a scannable code or presentation of a user code), theclient instance will not be able to strongly associate an incoming HTTP request with an establishedsession with the end user. This is also true when thepush interaction finish method is used,since the HTTP request comes directly from the interaction component of the AS. In thesecircumstances, the client instance can at least ensure that the incoming HTTPrequest can be uniquely associated with an ongoing grant request by making the interaction finishcallback URI unique for the grant when making the interaction request (Section 2.5.2).Mobile applications and other client instances that generally serve only a single end user at a timecan use this unique incoming URL to differentiate between a legitimate incoming request andan attacker's stolen request.¶

11.25.Calculating Interaction Hash

While the use of GNAP's signing mechanisms and token-protected grant API providessignificant security protections to the protocol, the interaction reference mechanismis susceptible to monitoring, capture, and injection by an attacker. To combat this, GNAPrequires the calculation and verification of an interaction hash. A client instancemight be tempted to skip this step, but doing so leaves the client instance open toinjection and manipulation by an attacker that could lead to additional issues.¶

The calculation of the interaction hash value provides defense in depth, allowing a clientinstance to protect itself from spurious injection of interaction references when using aninteraction finish method. The AS is protected during this attack through thecontinuation access token being bound to the expected interaction reference,but without hash calculation, the attacker could cause the client to make anHTTP request on command, which could itself be manipulated -- for example, by includinga malicious value in the interaction reference designed to attack the AS.With both of these in place, an attacker attempting to substitute the interaction referenceis stopped in several places.¶

Prerequisites: The client instance can allow multiple end users to access the same AS. The attacker is attempting to associate their rights with the target user's session.¶

• (1) The attacker starts a session at the client instance.¶

• (2) The client instance creates a grant request with nonce CN1.¶

• (3) The AS responds to the grant request with a need to interact, nonce SN1, and a continuation token, CT1.¶

• (4) The client instructs the attacker to interact at the AS.¶

• (5) The attacker interacts at the AS.¶

• (6) The AS completes the interact finish with interact reference IR1 and interact hash IH1 calculated from (CN1 + SN1 + IR1 + AS). The attacker prevents IR1 from returning to the client instance.¶

• (A) The target user starts a session at the client instance.¶

• (B) The client instance creates a grant request with nonce CN2.¶

• (C) The AS responds to the grant request with a need to interact, nonce SN2, and a continuation token, CT2.¶

• (D) The client instance instructs the user to interact at the AS.¶

• (E) The target user interacts at the AS.¶

• (7) Before the target user can complete their interaction, the attacker delivers their own interact reference IR1 into the user's session. The attacker cannot calculate the appropriate hash because the attacker does not have access to CN2 and SN2.¶

• (F) The target user triggers the interaction finish in their own session with the attacker's IR1.¶

• (G) If the client instance is checking the interaction hash, the attack stops here because the hash calculation of (CN2 + SN2 + IR1 + AS) will fail. If the client instance does not check the interaction hash, the client instance will be tricked into submitting the interaction reference to the AS. Here, the AS will reject the interaction request because it is presented against CT2 and not CT1 as expected. However, an attacker who has potentially injected CT1 as the value of CT2 would be able to continue the attack.¶

Even with additional checks in place, client instances using interaction finish mechanisms are responsiblefor checking the interaction hash to provide security to the overall system.¶

11.26.Storage of Information during Interaction and Continuation

When starting an interactive grant request, a client application has a number of protocol elementsthat it needs to manage, including nonces, references, keys, access tokens, and other elements.During the interaction process, the client instance usually hands control of the user experienceover to another component, be it the system browser, another application, or some actionthe RO is instructed to take on another device. In order for the client instanceto make its continuation call, it will need to recall all of these protocol elements at a future time. Usually,this means the client instance will need to store these protocol elements in some retrievablefashion.¶

If the security protocol elements are stored on the end user's device, such as in browserstorage or in local application data stores, capture and exfiltration of this information couldallow an attacker to continue a pending transaction instead of the client instance. Clientsoftware can make use of secure storage mechanisms, including hardware-based key and datastorage, to prevent such exfiltration.¶

Note that in GNAP, the client instance has to choose its interaction finish URI prior to makingthe first call to the AS. As such, the interaction finish URI will often have a unique identifierfor the ongoing request, allowing the client instance to access the correct portion of itsstorage. Since this URI is passed to other parties and often used through a browser,this URI should not contain any security-sensitive information that would bevaluable to an attacker, such as any token identifier, nonce, or user information. Instead, acryptographically random value is suggested, and that value should be used to index intoa secure session or storage mechanism.¶

11.27.Denial of Service (DoS) through Grant Continuation

When a client instance starts off an interactive process, it will eventually need to continue the grantrequest in a subsequent message to the AS. It's possible for a naive client implementation to continuouslysend continuation requests to the AS while waiting for approval, especially if no interactionfinish method is used. Such constant requests could overwhelm the AS's ability to respond to boththese and other requests.¶

To mitigate this for well-behaved client software, the continuation response contains await parameterthat is intended to tell the client instance how long it should wait until making its next request.This value can be used to back off client software that is checking too quickly by returning increasingwait times for a single client instance.¶

If client software ignores thewait value and makes its continuation calls too quickly or if theclient software assumes the absence of thewait values means it should poll immediately, the AScan choose to return errors to the offending client instance, including possibly canceling theongoing grant request. With well-meaning client software, these errors can indicate a need to changethe client software's programmed behavior.¶

11.28.Exhaustion of Random Value Space

Several parts of the GNAP process make use of unguessable randomized values, such as nonces,tokens, user codes, and randomized URIs. Since these values are intended to be unique, a sufficientlypowerful attacker could make a large number of requests to trigger generation of randomizedvalues in an attempt to exhaust the random number generation space. While this attack isparticularly applicable to the AS, client software could likewise be targeted by an attackertriggering new grant requests against an AS.¶

To mitigate this, software can ensure that its random values are chosen from a significantlylarge pool so that exhaustion of that pool is prohibitive for an attacker. Additionally, therandom values can be time-boxed in such a way that their validity windows are reasonably short.Since many of the random values used within GNAP are used within limited portions of the protocol,it is reasonable for a particular random value to be valid for only a small amount of time.For example, the nonces used for interaction finish hash calculation need only to be valid whilethe client instance is waiting for the finish callback and can be functionally expiredwhen the interaction has completed. Similarly, artifacts like access tokens and the interactionreference can be limited to have lifetimes tied to their functional utility. Finally, eachdifferent category of artifact (nonce, token, reference, identifier, etc.) can begenerated from a separate random pool of values instead of a single global value space.¶

11.29.Front-Channel URIs

Some interaction methods in GNAP make use of URIs accessed through the end user's browser,known collectively as front-channel communication. These URIs are most notably present intheredirect interactionstart method and theredirect interactionfinish mode. Sincethese URIs are intended to be given to the end user, the end user and their browser will besubjected to anything hosted at that URI including viruses, malware, and phishing scams. Thiskind of risk is inherent to all redirection-based protocols, including GNAP, when used in this way.¶

When talking to a new or unknown AS, a client instance might want to check the URI from theinteractionstart against a blocklist and warn the end user before redirecting them. Manyclient instances will provide an interstitial message prior to redirection in order to preparethe user for control of the user experience being handed to the domain of the AS, and such amethod could be used to warn the user of potential threats (for instance, a rogue AS impersonatinga well-known service provider). Client software can also prevent this by managing an allowlistof known and trusted ASes.¶

Alternatively, an attacker could start a GNAP request with a known and trusted AS but includetheir own attack site URI as the callback for the redirectfinish method. The attacker would then sendthe interactionstart URI to the victim and get them to click on it. Since the URI is atthe known AS, the victim is inclined to do so. The victim will then be prompted to approve theattacker's application, and in most circumstances, the victim will then be redirected to theattacker's site whether or not the user approved the request. The AS could mitigate this partiallyby using a blocklist and allowlist of interactionfinish URIs during the client instance'sinitial request, but this approach can be especially difficult if the URI has any dynamic portionchosen by the client software. The AS can couple these checks with policies associated with theclient instance that has been authenticated in the request. If the AS has any doubt about theinteraction finish URI, the AS can provide an interstitial warning to the end user beforeprocessing the redirect.¶

Ultimately, all protocols that use redirect-based communication through the user's browser aresusceptible to having an attacker try to co-opt one or more of those URIs in order to harm theuser. It is the responsibility of the AS and the client software to provide appropriate warnings,education, and mitigation to protect end users.¶

11.30.Processing Assertions

Identity assertions can be used in GNAP to convey subject information, both from the AS to theclient instance in a response (Section 3.4) and from the client instance to the AS ina request (Section 2.2). In both of these circumstances, when an assertion is passed inGNAP, the receiver of the assertion needs to parse and process the assertion. As assertions arecomplex artifacts with their own syntax and security, special care needs to be taken to prevent theassertion values from being used as an attack vector.¶

All assertion processing needs to account for the security aspects of the assertion format inuse. In particular, the processor needs to parse the assertion from a JSON string objectand apply the appropriate cryptographic processes to ensure the integrity of the assertion.¶

For example, when SAML 2.0 assertions are used, the receiver has to parse an XML document. There aremany well-known security vulnerabilities in XML parsers, and the XML standard itself can beattacked through the use of processing instructions and entity expansions to cause problemswith the processor. Therefore, any system capable of processing SAML 2.0 assertions also needs tohave a secure and correct XML parser. In addition to this, the SAML 2.0 specification uses XMLSignatures, which have their own implementation problems that need to be accounted for. Similarrequirements exist for OpenID Connect ID Token, which is based on the JWT formatand the related JOSE cryptography suite.¶