N. Sakimura
J. Bradley
E. Jay
December 22, 2020

Financial-grade API - Part 2: Advanced Security Profile


This document is not an OIDF International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Copyright notice & license

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.


The OpenID Foundation (OIDF) promotes, protects and nurtures the OpenID community and technologies. As a non-profit international standardizing body, it is comprised by over 160 participating entities (workgroup participants). The work of preparing implementer drafts and final international standards is carried out through OIDF workgroups in accordance with the OpenID Process. Participants interested in a subject for which a workgroup has been established has the right to be represented in that workgroup. International organizations, governmental and non-governmental, in liaison with OIDF, also take part in the work. OIDF collaborates closely with other standardizing bodies in the related fields.

Final drafts adopted by the Workgroup through consensus are circulated publicly for the public review for 60 days and for the OIDF members for voting. Publication as an OIDF Standard requires approval by at least 50 % of the members casting a vote. There is a possibility that some of the elements of this document may be the subject to patent rights. OIDF shall not be held responsible for identifying any or all such patent rights.

Financial-grade API consists of the following parts:

Future parts may follow.

These parts are intended to be used with RFC6749, RFC6750, RFC7636, and OIDC.


Fintech is an area of future economic growth around the world and Fintech organizations need to improve the security of their operations and protect customer data. It is common practice of aggregation services to use screen scraping as a method to capture data by storing users' passwords. This brittle, inefficient, and insecure practice creates security vulnerabilities which require financial institutions to allow what appears to be an automated attack against their applications and to maintain a whitelist of aggregators. A new draft standard, proposed by this workgroup would instead utilize an API model with structured data and a token model, such as OAuth [RFC6749, RFC6750].

The Financial-grade API aims to provide specific implementation guidelines for online financial services to adopt by developing a REST/JSON data model protected by a highly secured OAuth profile. The Financial-grade API security profile can be applied to online services in any market area that requires a higher level of security than provided by standard OAuth or OpenID Connect.

This document is Part 2 of FAPI that specifies the Financial-grade API and it provides a profile of OAuth that is suitable to be used for high risk access (read or write), for example, read access to highly sensitive data or write access to financial data (also known as payment initiation). This document specifies the controls against attacks such as: authorization request tampering, authorization response tampering including code injection, state injection, and token request phishing. Additional details are available in the security considerations section.

Although it is possible to code an OpenID Provider and Relying Party from first principles using this specification, the main audience for this specification is parties who already have a certified implementation of OpenID Connect and want to achieve a higher level of security. Implementers are encouraged to understand the security considerations contained in section 8.7 before embarking on a 'from scratch' implementation.

Notational Conventions

The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 ISODIR2. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings.

Table of Contents

1. Scope

This part of the document specifies the method of

This document is applicable to higher risk use cases which includes commercial and investment banking and other similar industries.

2. Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISODIR2 - ISO/IEC Directives Part 2

RFC6749 - The OAuth 2.0 Authorization Framework

RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage

RFC7636 - Proof Key for Code Exchange by OAuth Public Clients

RFC6819 - OAuth 2.0 Threat Model and Security Considerations

RFC7519 - JSON Web Token (JWT)

RFC7591 - OAuth 2.0 Dynamic Client Registration Protocol

RFC7592 - OAuth 2.0 Dynamic Client Registration Management Protocol

BCP195 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

OIDC - OpenID Connect Core 1.0 incorporating errata set 1

OIDD - OpenID Connect Discovery 1.0 incorporating errata set 1

MTLS - OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens

JARM - Financial Services – Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)

PAR - OAuth 2.0 Pushed Authorization Requests

JAR - OAuth 2.0 JWT Secured Authorization Request

3. Terms and definitions

For the purpose of this document, the terms defined in RFC6749, RFC6750, RFC7636, OpenID Connect Core and [ISO29100] apply.

4. Symbols and Abbreviated terms

API – Application Programming Interface

CSRF - Cross Site Request Forgery

FAPI - Financial-grade API

HTTP – Hyper Text Transfer Protocol

OIDF - OpenID Foundation

REST – Representational State Transfer

TLS – Transport Layer Security

5. Advanced security profile

5.1. Introduction

The OIDF Financial-grade API (FAPI) is a REST API that provides JSON data representing higher risk data. These APIs are protected by the OAuth 2.0 Authorization Framework that consists of RFC6749, RFC6750, RFC7636, and other specifications.

There are different levels of risks associated with access to these APIs. For example, read and write access to a bank API has a higher financial risk than read-only access. As such, the security profiles of the authorization framework protecting these APIs are also different.

This profile describes security provisions for the server and client that are appropriate for Financial-grade APIs by defining the measures to mitigate:

This profile does not support public clients.

The following ways are specified to cope with modifications of authorization responses: Implementations can leverage OpenID Connect's Hybrid Flow that returns an ID Token in the authorization response or they can utilize the JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) that returns and protects all authorization response parameters in a JWT.

5.1.1. ID Token as Detached Signature

While the name ID Token (as used in the OpenID Connect Hybrid Flow) suggests that it is something that provides the identity of the resource owner (subject), it is not necessarily so. While it does identify the authorization server by including the issuer identifier, it is perfectly fine to have an ephemeral subject identifier. In this case, the ID Token acts as a detached signature of the issuer to the authorization response and it was an explicit design decision of OpenID Connect Core to make the ID Token act as a detached signature.

This document leverages this fact and protects the authorization response by including the hash of all of the unprotected response parameters, e.g. code and state, in the ID Token.

While the hash of the code is defined in OIDC, the hash of the state is not defined. Thus this document defines it as follows.


5.1.2. JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)

An authorization server may protect authorization responses to clients using the "JWT Secured Authorization Response Mode" JARM.

The JARM allows a client to request that an authorization server encodes the authorization response (of any response type) in a JWT. It is an alternative to utilizing ID Tokens as detached signatures for providing financial-grade security on authorization responses and can be used with plain OAuth.

This specification facilitates use of JARM in conjunction with the response type code.

Note: JARM can be used to protect OpenID Connect authentication responses. In this case, the OpenID RP would use response type code, response mode jwt and scope openid. This means JARM protects the authentication response (instead of the ID Token) and the ID Token containing End-User Claims is obtained from the token endpoint. This facilitates privacy since no End-User Claims are sent through the front channel. It also provides decoupling of message protection and identity providing since a client (or RP) can basically use JARM to protect all authorization responses and turn on OpenID if needed (e.g. to log the user in).

5.2. Advanced security provisions

5.2.1. Introduction

Read and write access carries higher risk; therefore the protection level required is higher than read-only access.

As a profile of The OAuth 2.0 Authorization Framework, this document mandates the following for the advanced profile of the FAPI.

5.2.2. Authorization server

The authorization server shall support the provisions specified in clause 5.2.2 of Financial-grade API - Part 1: Baseline Security Profile, with the exception that section (enforcement of RFC7636) is not required.

In addition, the authorization server

  1. shall require a JWS signed JWT request object passed by value with the request parameter or by reference with the request_uri parameter;
  2. shall require
    1. the response_type value code id_token or
    2. the response_type value code in conjunction with the response_mode value jwt;
  3. (moved to
  4. shall only issue sender-constrained access tokens;
  5. shall support MTLS as mechanism for constraining the legitimate senders of access tokens;
  6. (withdrawn);
  7. (moved to;
  8. (moved to;
  9. shall only use the parameters included in the signed request object passed via the request or request_uri parameter;
  10. may support the pushed authorization request endpoint as described in PAR;
  11. (withdrawn);
  12. shall require the request object to contain an exp claim that has a lifetime of no longer than 60 minutes after the nbf claim; and
  13. shall authenticate the confidential client using one of the following methods (this overrides FAPI Part 1 clause
    1. tls_client_auth or self_signed_tls_client_auth as specified in section 2 of MTLS;
    2. private_key_jwt as specified in section 9 of OIDC;
  14. shall require the aud claim in the request object to be, or to be an array containing, the OP's Issuer Identifier URL;
  15. shall not support public clients;
  16. shall require the request object to contain an nbf claim that is no longer than 60 minutes in the past; and
  17. shall require PAR requests, if supported, to use PKCE (RFC7636) with S256 as the code challenge method.

NOTE: MTLS is currently the only mechanism for sender-constrained access tokens that has been widely deployed. Future versions of this specification are likely to allow other mechanisms for sender-constrained access tokens.

NOTE: PAR does not present any additional security concerns that necessitated the requirement to use PKCE - the reason PKCE is not required in other cases is merely to be backwards compatible with earlier drafts of this standard.

5.2.3. ID Token as detached signature

In addition, if the response_type value code id_token is used, the authorization server

  1. shall support OIDC
  2. shall support signed ID Tokens;
  3. should support signed and encrypted ID Tokens;
  4. shall return ID Token as a detached signature to the authorization response;
  5. shall include state hash, s_hash, in the ID Token to protect the state value if the client supplied a value for state. s_hash may be omitted from the ID Token returned from the Token Endpoint when s_hash is present in the ID Token returned from the Authorization Endpoint;
  6. should not return sensitive PII in the ID Token in the authorization response, but if it needs to, then it should encrypt the ID Token.

NOTE: The authorization server may return more claims in the ID Token from the token endpoint than in the one from the authorization response

5.2.4. JARM

In addition, if the response_type value code is used in conjunction with the response_mode value jwt, the authorization server

  1. shall create JWT-secured authorization responses as specified in JARM, section 4.3;

5.2.5. Confidential client

A confidential client shall support the provisions specified in clause 5.2.3 and 5.2.4 of Financial-grade API - Part 1: Baseline Security Profile, except for RFC7636 support.

In addition, the confidential client

  1. shall support MTLS as mechanism for sender-constrained access tokens;
  2. shall include the request or request_uri parameter as defined in Section 6 of OIDC in the authentication request;
  3. shall ensure the Authorization Server has authenticated the user to an appropriate Level of Assurance for the client's intended purpose;
  4. (moved to;
  5. (withdrawn);
  6. (withdrawn);
  7. (moved;
  8. shall send all parameters inside the authorization request's signed request object;
  9. shall additionally send duplicates of the response_type, client_id, and scope parameters/values using the OAuth 2.0 request syntax as required by section 6.1 of the OpenID Connect specification if not using PAR;
  10. shall send the aud claim in the request object as the OP's Issuer Identifier URL;
  11. shall send an exp claim in the request object that has a lifetime of no longer than 60 minutes;
  12. (moved to;
  13. (moved to;
  14. shall send a nbf claim in the request object;
  15. shall use RFC7636 with S256 as the code challenge method if using PAR;
  16. shall additionally send a duplicate of the client_id parameter/value using the OAuth 2.0 request syntax to the authorization endpoint, as required by section 5 of JAR, if using PAR;

5.2.6. ID Token as detached signature

In addition, if the response_type value code id_token is used, the client

  1. shall include the value openid into the scope parameter in order to activate OIDC support
  2. shall require JWS signed ID Token be returned from endpoints;
  3. shall verify that the authorization response was not tampered using ID Token as the detached signature
  4. shall verify that s_hash value is equal to the value calculated from the state value in the authorization response in addition to all the requirements in of OIDC. Note: this enables the client to verify that the authorization response was not tampered with, using the ID Token as a detached signature.
  5. shall support both signed and signed & encrypted ID Tokens

5.2.7. JARM

In addition, if the response_type value code is used in conjunction with the response_mode value jwt, the client

  1. shall verify the authorization responses as specified in JARM, section 4.4;

5.2.8. (withdrawn)

5.2.9. (withdrawn)

6. Accessing protected resources (using tokens)

6.1. Introduction

The FAPI endpoints are OAuth 2.0 protected resource endpoints that return protected information for the resource owner associated with the submitted access token.

6.2. Advanced access provisions

6.2.1. Protected resources provisions

The protected resources supporting this document

  1. shall support the provisions specified in clause 6.2.1 Financial-grade API - Part 1: Baseline Security Profile;
  2. shall adhere to the requirements in MTLS.

6.2.2. Client provisions

The client supporting this document shall support the provisions specified in clause 6.2.2 of Financial-grade API - Part 1: Baseline Security Profile.

7. (Withdrawn)

8. Security considerations

8.1. Introduction

As a profile of the OAuth 2.0 Authorization Framework, this specification references the security considerations defined in section 10 of RFC6749, as well as RFC6819 - OAuth 2.0 Threat Model and Security Considerations, which details various threats and mitigations. The security of OAuth 2.0 has been proven formally - under certain assumptions - in [OAUTHSEC]. A detailed security analysis of FAPI can be found in [FAPISEC].

8.2. Uncertainty of resource server handling of access tokens

There is no way that the client can find out whether the resource access was granted for a bearer or sender-constrained access token. The two differ in the risk profile and the client may want to differentiate them. The protected resources that conform to this doc differentiate them. The protected resources that conform to this document shall not accept a bearer access token. They shall only support sender-constrained access tokens via MTLS.

8.3. Attacks using weak binding of authorization server endpoints

8.3.1. Introduction

In RFC6749 and RFC6750, the endpoints that the authorization server offers are not tightly bound together. There is no notion of authorization server identifier (issuer identifier) and it is not indicated in the authorization response unless the client uses different redirection URI per authorization server. While it is assumed in the OAuth model, it is not explicitly spelled out and thus many clients use the same redirection URI for different authorization servers exposing an attack surface. Several attacks have been identified and the threats are explained in detail in RFC6819.

8.3.2. Client credential and authorization code phishing at token endpoint

In this attack, the client developer is socially engineered into believing that the token endpoint has changed to the URL that is controlled by the attacker. As a result, the client sends the code and the client secret to the attacker, which will be replayed subsequently.

When the FAPI client uses MTLS, the client's secret (the private key corresponding to its TLS certificate) is not exposed to the attacker, which therefore cannot authenticate towards the token endpoint of the authorization server.

8.3.3. Identity provider (IdP) mix-up attack

In this attack, the client has registered multiple IdPs and one of them is a rogue IdP that returns the same client_id that belongs to one of the honest IdPs. When a user clicks on a malicious link or visits a compromised site, an authorization request is sent to the rogue IdP. The rogue IdP then redirects the client to the honest IdP that has the same client_id. If the user is already logged on at the honest IdP, then the authentication may be skipped and a code is generated and returned to the client. Since the client was interacting with the rogue IdP, the code is sent to the rogue IdP's token endpoint. At the point, the attacker has a valid code that can be exchanged for an access token at the honest IdP. See [OAUTHSEC] for a detailed description of the attack.

This attack is mitigated by the use of OpenID Connect Hybrid Flow in which the honest IdP's issuer identifier is included as the value of iss or JARM where the iss included in the response JWT. On receiving the authorization response, the client compares the iss value from the response with the issuer URL of the IdP it sent the authorization request to (the rogue IdP). The client detects the conflicting issuer values and aborts the transaction.

8.3.4. (removed)

8.3.5. Access token phishing

Various mechanisms in this specification aim at preventing access token phishing, e.g., the requirement of exactly matching redirect URIs and the restriction on response types that do not return access tokens in the front channel. As a second layer of defense, FAPI Advanced clients use MTLS meaning the access token is bound to the client's TLS certificate. Even if an access token is phished, it cannot be used by the attacker. An attacker could try to trick a client under his control to make use of the access token as described in [FAPISEC] ("Cuckoo's Token Attack" and "Access Token Injection with ID Token Replay"), but these attacks additionally require a rogue AS or misconfigured token endpoint.

8.4. Attacks that modify authorization requests and responses

8.4.1. Introduction

In RFC6749 the authorization request and responses are not integrity protected. Thus, an attacker can modify them.

8.4.2. Authorization request parameter injection attack

In RFC6749, the authorization request is sent as a query parameter. Although RFC6749 mandates the use of TLS, the TLS is terminated in the browser and thus not protected within the browser; as a result an attacker can tamper the authorization request and insert any parameter values.

The use of a request object or request_uri in the authorization request will prevent tampering with the request parameters.

The IdP confusion attack reported in SoK: Single Sign-On Security – An Evaluation of OpenID Connect is an example of this kind of attack.

8.4.3. Authorization response parameter injection attack

This attack occurs when the victim and attacker use the same relying party client. The attacker is somehow able to capture the authorization code and state from the victim's authorization response and uses them in his own authorization response.

This can be mitigated by using OpenID Connect Hybrid Flow where the c_hash, at_hash, and s_hash can be used to verify the validity of the authorization code, access token, and state parameters. It can also be mitigated using JARM by verifying the integrity of the authorization response JWT.

The server can verify that the state is the same as what was stored in the browser session at the time of the authorization request.

8.5. TLS considerations

As confidential information is being exchanged, all interactions shall be encrypted with TLS (HTTPS).

Section 7.1 of Financial-grade API - Part 1: Baseline Security Profile shall apply, with the following additional requirements:

  1. For TLS versions below 1.3, only the following 4 cipher suites shall be permitted:
  2. For the authorization_endpoint, the authorization server MAY allow additional cipher suites that are permitted by the latest version of BCP195, if necessary to allow sufficient interoperability with users' web browsers or are required by local regulations. NOTE: Permitted cipher suites are those that BCP195 does not explicity say MUST NOT use.
  3. When using the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 or TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 cipher suites, key lengths of at least 2048 bits are required.

8.6. Algorithm considerations

For JWS, both clients and authorization servers:

  1. shall use PS256 or ES256 algorithms;
  2. should not use algorithms that use RSASSA-PKCS1-v1_5 (e.g. RS256);
  3. shall not use none;

8.7. Encryption algorithm considerations

For JWE, both clients and authorization servers

  1. shall not use the RSA1_5 algorithm.

8.8. Incomplete or incorrect implementations of the specifications

To achieve the full security benefits, it is important the implementation of this specification, and the underlying OpenID Connect and OAuth specifications, are both complete and correct.

The OpenID Foundation provides tools that can be used to confirm that an implementation is correct:


The OpenID Foundation maintains a list of certified implementations:


Deployments that use this specification should use a certified implementation.

8.9. Session Fixation

An attacker could prepare an authorization request URL and trick a victim into authorizing access to the requested resources, e.g. by sending the URL via e-Mail or utilizing it on a fake site.

OAuth 2.0 prevents this kind of attack since the process for obtaining the access token (code exchange, CSRF protection etc.) is designed in a way that the attacker will be unable to obtain and use the token as long as it does not control the victim's browser.

However, if the API allows execution of any privileged action in the course of the authorization process before the access token is issued, these controls are rendered ineffective. Implementers of this specification therefore shall ensure any action is executed using the access token issued by the authorization process.

For example, payments shall not be executed in the authorization process but after the Client has exchanged the authorization code for a token and sent an "execute payment" request with the access token to a protected endpoint.

8.10. JWKS URIs

This profile requires both Clients and Authorization Servers to verify payloads with keys from the other party. The AS verifies request objects and private_key_jwt assertions. The Client verifies ID Tokens and authorization response JWTs. For AS's this profile strongly recommends the use of JWKS URI endpoints to distribute public keys. For Clients this profile recommends either the use of JWKS URI endpoints or the use of the jwks parameter in combination with RFC7591 and RFC7592.

The definition of the AS jwksuri can be found in [RFC8414], while the definition of the Client jwksuri can be found in RFC7591.

In addition, this profile

  1. requires that jwks_uri endpoints shall be served over TLS;
  2. recommends that JOSE headers for x5u and jku should not be used;
  3. recommends that the JWK set does not contain multiple keys with the same kid.

8.11. Multiple clients sharing the same key

The use of MTLS for client authentication and sender constraining access tokens brings significant security benefits over the use of shared secrets. However in some deployments the certificates used for MTLS are issued by a Certificate Authority at an organisation level rather than a client level. In such situations it may be common for an organisation with multiple clients to use the same certificates (or certificates with the same DN) across clients. Implementers should be aware that such sharing means that a compromise of any one client, would result in a compromise of all clients sharing the same key.

8.12. Duplicate Key Identifiers

JWK sets should not contain multiple keys with the same kid. However, to increase interoperability when there are multiple keys with the same kid, the verifier shall consider other JWK attributes, such as kty, use, alg, etc., when selecting the verification key for the particular JWS message. For example, the following algorithm could be used in selecting which key to use to verify a message signature:

  1. Find keys with a kid that matches the kid in the JOSE header;
  2. If a single key is found, use that key;
  3. If multiple keys are found, then the verifier should iterate through the keys until a key is found that has a matching alg, use, kty, or crv that corresponds to the message being verified.

9. Privacy considerations

9.1. Introduction

There are many factors to be considered in terms of privacy when implementing this document. However, since this document is a profile of OAuth and OpenID Connect, all of them are generic and applies to OAuth or OpenID Connect and not specific to this document. Implementers are advised to perform a thorough privacy impact assessment and and manage identified risks appropriately.

NOTE: Implementers can consult documents like [ISO29100] and [ISO29134] for this purpose.

Privacy threats to OAuth and OpenID Connect implementations include the following:

These can be mitigated by choosing appropriate options in OAuth or OpenID, or by introducing some operational rules. For example, "Attacker observing personal data in authorization request" can be mitigated by either using authorization request by reference using request_uri or by encrypting the request object. Similarly, "Attacker observing personal data in authorization endpoint response" can be mitigated by encrypting the ID Token or JARM response.

10. Acknowledgement

The following people contributed to this document:

11. Bibliography

12. IANA Considerations

12.1. Additions to JWT Claims Registry

This specification adds the following values to the "JSON Web Token Claims" registry established by RFC7519.

12.1.1. Registry Contents

Appendix A. Examples

The following are non-normative examples of various objects compliant with this specification, with line wraps within values for display purposes only.

The examples signed by the client may be verified with the following JWK:

  "kty": "RSA",
  "e": "AQAB",
  "use": "sig",
  "kid": "client-2020-08-28",
  "alg": "PS256",
  "n": "i0Ybm4TJyErnD5FIs-6sgAdtP6fG631FXbe5gcOGYgn9aC2BS2h9Ah5cRGQpr3aLLVKCRWU6

The examples signed by the server may be verified with the following JWK:

  "kty": "RSA",
  "e": "AQAB",
  "use": "sig",
  "kid": "server-2020-08-28",
  "alg": "PS256",
  "n": "pz6g0h7Cu63SHE8_Ib4l3hft8XuptZ-Or7v_j1EkCboyAEn_ZCuBrQOmpUIoPKrA0JNWK_fF

The code that generated these examples can be found here:


A.1. Example request object


which when decoded has the following body:

  "aud": "https://fapi-as.example.com/",
  "scope": "openid payments",
  "iss": "52480754053",
  "response_type": "code id_token",
  "redirect_uri": "https://fapi-client.example.org/fapi-as-callback",
  "state": "VgSUIEnflnDxTe1vAtr54o",
  "exp": 1594140390,
  "nonce": "7xDCHviuPMSXJIigkHOcDi",
  "client_id": "52480754053"

A.2. Example signed id_token for authorization endpoint response


which when decoded has the following body:

  "sub": "1001",
  "aud": [
  "c_hash": "QR2zucfYZkiLrbKBKDVpgQ",
  "s_hash": "9s6CBbOxiKE65d9-Qr0QIQ",
  "auth_time": 1594140090,
  "iss": "https://fapi-as.example.com/",
  "exp": 1594140390,
  "iat": 1594140090,
  "nonce": "7xDCHviuPMSXJIigkHOcDi"

A.3. Example signed and encrypted id_token for authorization endpoint response


which when decrypted using the following key:

    "kty": "RSA",
    "d": "OjDe8EkZXgvB-Gy5A4EdU8fBuAjdHLMyHKAtMaS_W_joEJHDvZRhIYbh1jAyHYoR3kFMXu
    "e": "AQAB",
    "use": "enc",
    "kid": "client-enc-2020-08-28",
    "n": "jVc92j0ntTV0V1nwZ3mpGaV2bME4d6AMS2SRrJBM0fLehaTEqDNzGu0warz2SC9bhcBOB5

has the following body:

  "sub": "1001",
  "aud": "2334382354153498",
  "acr": "urn:cds.au:cdr:2",
  "c_hash": "BLfy9hvQUZTDq6_KmF4kDQ",
  "s_hash": "9s6CBbOxiKE65d9-Qr0QIQ",
  "auth_time": 1595827190,
  "iss": "https://fapi-as.example.com/",
  "exp": 1595827490,
  "iat": 1595827190,
  "nonce": "7xDCHviuPMSXJIigkHOcDi"

A.4. Example JARM response


which when decoded has the following body:

  "aud": "469180648039051",
  "code": "zwkGac9juLX8F8frapDISi3K2Fwln4qxwyfNII3Cjz0",
  "iss": "https://fapi-as.example.com/",
  "state": "VgSUIEnflnDxTe1vAtr54o",
  "exp": 1594141090

A.5. Example private_key_jwt client assertion


which when decoded has the following body:

  "sub": "52480754053",
  "aud": "https://fapi-as.example.com/api/token",
  "iss": "52480754053",
  "exp": 1594140151,
  "iat": 1594140091,
  "jti": "4vBctMSkK4wfuOui9Cyc"

Authors' Addresses

Nat Sakimura Nat Consulting EMail: nat@nat.consulting URI: http://nat.sakimura.org/
John Bradley Yubico EMail: ve7jtb@ve7jtb.com URI: http://www.thread-safe.com/
Illumila Illumila EMail: ejay@mgi1.com URI: http://illumi.la/