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.
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 account is called the client and be the account holder, another account provider, a third-party or any other entity.
In Open Payments, the account provider is the resource server (and the account is the resource).
The authorization of access to the account can be separated from the account provider if desired. The authorization service can even be fulfilled by multiple federated providers if a use case requires this in future.
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.
Updated 7 months ago