Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) to define a standard mechanism for requesting and granting access tokens for the APIs.

GNAP is the successor to OAuth2.0, designed to fill many of the gaps in OAuth2.0 that have been uncovered through its use in Open Banking and other financial use cases.

Grants in GNAP provide fine-grained control over the operations that a client can perform on the account including control over the amounts of transactions with time-based and velocity based limits. This is distinct from OAuth2.0 which uses scopes and requires clients to create special resources such as payment intents for managing resource access and usage limits.

Roles

GNAP clearly separates the roles of the resource server (where the operations are performed and to which access is granted) and the authorisation server (where the access tokens are requested).

The entity accessing the services is called the client and could be the wallet owner, another wallet, a third-party or any other entity.

In Open Payments, the wallet provider is the resource server (and the wallet is the primary resource).

The authorization of access to the wallet can be separated from the wallet provider if desired. The authorization service can even be fulfilled by multiple federated providers if a use case requires this in future.

API

The APIs implemented by the resource server are defined by the Open Payments API specification. The APIs implemented by the authorization server are a profile of GNAP and defined in this guide.

An open source implementation of an Open Payments resource server, Rafiki, is currently in development.