Overview

To give a quick overview how the flow works when connecting to a rebel-compliant API, a sample case is described in the following sequence diagram:

Protocol Flow

sequenceDiagram
  actor Data Owner

  Data Owner->>Service Consumer: Connect to Service Provider X
  Service Consumer->>+Service Provider X: POST /v1/consents
  Service Provider X-->>-Service Consumer: Response: Psd2Consent

  rect rgb(240,240,240)
  Note over Data Owner, Service Provider X: OAuth 2.0 PKCE

  Service Consumer->>+Service Provider X: GET /.well-known OAuth 2.0 Metadata Discovery

  Service Consumer->>Data Owner: HTTP 301 -> /authorize?consent_id=Psd2ConsentId
  Data Owner->>Service Provider X: Login / Authorize Consent
  Service Provider X-->>Service Consumer: Callback, providing Authorization Code Grant
  Service Consumer->>+Service Provider X: POST /v1/oauth/token
  Service Provider X-->>-Service Consumer: Response: accessToken, refreshToken
  end

  Service Consumer->>+Service Provider X: GET /v1/accounts
  Service Provider X-->>-Service Consumer: Response: accounts: Psd2Account
  Service Consumer-->>Data Owner: Use Case

Service Provider

The service provider must implement the following things:

• Consent APIs (available to authenticated applications, namely service consumers)
• OAuth 2.0 compatible authorization
• AIS APIs (available to authorized applications, namely service consumers with authorization rights for data owners)

Service Consumer

The service consumer must implement the following things:

• Consent APIs (to create new consents)
• Ability to handle OAuth 2.0 PKCE

The service consumer may implement the following things:

• Other rebel endpoints at their own discretion

Data Owner

The data owner will log in during the authorization flow and give consent.