connectid-fapi-ciba-profile-02 December 2025
Postnikov Standards Track [Page]
Workgroup:
ConnectID Security
Published:
Author:
DP. Postnikov
ConnectID

ConnectID FAPI Client Initiated Backchannel Authentication Profile 1.0 Implementers' Draft 2

Foreword

This part is intended to be used with ConnectID-FAPI and FAPI-CIBA.

Introduction

The ConnectID Client Initiated Backchannel Authentication (CIBA) profile aims to provide specific implementation guidelines for regarding use of CIBA within in the ConnectID ecosystem.

Notational Conventions

The key words "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2. 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 document specifies the method for an application to:

2. Normative references

FAPI-CIBA - FAPI: Client-Initiated Backchannel Authentication Profile

RAR - OAuth 2.0 Rich Authorization Requests

ConnectID-FAPI - ConnectID FAPI Security Profile

ConnectID-Id-Assurance ConnectID Identity Assurance Profile

ConnectID-Cert-Std - ConnectID Certificate Standards

ConnectID-Client-Reg - ConnectID Client Registration Profile

OAuth2-Purpose - OAuth 2 Purpose extension (individual draft)

ISODIR2 - ISO/IEC Directives Part 2

RFC6749 - The OAuth 2.0 Authorization Framework

OIDC - OpenID Connect Core 1.0 incorporating errata set 1

RFC9493 - Subject Identifiers for Security Event Tokens

3. Terms and definitions

For this standard, the terms defined in the OAuth 2 Authorization framework, OpenID Connect Core, and OpenID Connect Client Initiated Backchannel Authentication Core apply.

4. Client-Initiated Backchannel Authentication Security Profile

4.1. Use cases

4.1.1. Decoupled Identity attribute provisioning - generic

This section defines requirements for one-off identity attribute provisioning via the OIDC claims request parameter. Any claims defined in ConnectID-Id-Assurance can be requested.

4.1.1.1. CIBA Parameters

For this use case, FAPI-CIBA request has the following parameters:

Table 1
Parameter Mandatory Description
binding_message Y Human-readable purpose statement as described in OAuth2-Purpose following constraints in FAPI-CIBA
login_hint Y One of the values defined in this specification. To be defined for each use case.
request_expiry N To be reviewed for each use case. Default value is 300 seconds
request_context TBC To be defined for each specific use case

4.1.2. Decoupled Identity attribute provisioning - for use with 3DS Extended Attribute specification (EMVCO)

In addition to "Decoupled Identity attribute provisioning - generic" requirements, the following requirements apply.

4.1.2.1. CIBA Parameters

For this use case, FAPI-CIBA request has the following parameters:

Table 2
Parameter Mandatory Description
binding_message Y Human-readable purpose statement as described in OAuth2-Purpose following constraints in FAPI-CIBA. This value shall contain the name of the actual 3DS merchant familiar to a user (cardholder).
login_hint Y card_primary_account_number, 6-digit PAN (account number) communicated in a standard-based format described in RFC9493
request_expiry N TBC Is default 300 seconds appropriate for 3DS
request_context TBC TBC To inform fraud and threat decisions. For example, an ecosystem may require relying parties to provide geolocation for the consumption device

4.1.3. Decoupled Payment Authentication - 3DS (EMVCO)

This specification only supports one-off 3DS payment authorisation at this stage.

In addition to "Decoupled Identity attribute provisioning - generic" requirements, the following requirements apply.

4.1.3.1. CIBA Parameters

For this use case, FAPI-CIBA request has the following parameters:

Table 3
Parameter Mandatory Description
authorization_details Y Payment details (see below for details)
binding_message Y Human-readable purpose statement as described in OAuth2-Purpose following constraints in FAPI-CIBA
login_hint Y card_primary_account_number, 6-digit PAN (account number) communicated in a standard-based format described in RFC9493
request_expiry N TBC Is default 300 seconds appropriate for 3DS
request_context TBC TBC To inform fraud and threat decisions. For example, an ecosystem may require relying parties to provide geolocation for the consumption device

Authorisation details shall follow RAR specification and the following schema:

Table 4
Parameter Description
type 3ds:payment_authorisation
instructed_amount Payment details (see below for details)
amount Amount to be authorised
currency Currency code
source_account card_primary_account_number
beneficiary_name Human-readable merchant name
payment_desc Human-readable purpose statement as described in OAuth2-Purpose following constraints in FAPI-CIBA

Non-normative example:

authorization_details=[{
      "type": "3ds:payment_authorisation",
      "instructed_amount": {
        "amount": 222.22,
        "currency": "AUD"
      },
      "source_account": "xxxxxxxxxxx1234", //
      "beneficiary_name": "Byron Bay Cookies",
      "payment_desc": "Online purchase of cookies with age verification" // purpose
    }]

4.2. Authorization Server

The Authorization Server shall support the provisions specified in clause 5.2.2 of the FAPI-CIBA profile.

In addition, the Authorization server, for all operations,

  1. shall only support FAPI-CIBA poll mode; and
  2. shall support all claims as per ConnectID-Id-Assurance using the claims request parameter.

4.3. Confidential Client

A Confidential Client shall support the provisions specified in clause 5.2.3 of the FAPI-CIBA profile.

In addition, the Confidential Client

  1. shall only use one of the login_hint values described above;
  2. shall only use FAPI-CIBA poll mode; and
  3. shall request claims using the claims request parameter as defined in ConnectID-Id-Assurance.

5. Accessing Protected Resources

Not required

6. Security Considerations

There are no additional security considerations beyond those in FAPI-CIBA.

7. Privacy Considerations

There are no additional privacy considerations beyond those in FAPI-CIBA.

8. Acknowledgement

We want to thank Ralph Bragg, Mark Haine, Bjorn Helm, and everyone who provided valuable feedback and contributions that helped to evolve this specification.

We would also like to thank the OpenID Foundation, the IETF, and many others who have laid the foundations for secure and safe data sharing.

9. Appendix A - Examples

The following are non-normative examples of the FAPI-CIBA requests and responses.

All examples use private_key_jwt client authentication with the following key:

{
  "kty": "EC",
  "d": "gM__X2faDsb4s6QLer9h-y4KzLIgwt5Jz2dJi5r64Pc",
  "use": "sig",
  "kid": "thrwqnuer",
  "crv": "P-256",
  "x": "YPczq3aBrd8PjtFsXX_HPZNwnzp89vAGjgQXm4cOgdQ",
  "y": "eqE4OZu0V07qXi9ojhQAeqKndWp0QwUfB3aNp4dYYPQ",
  "alg": "ES256"
}

9.1. A.1 Signed Authentication Request with private_key_jwt client authentication

This example includes various optional fields, some of which may not apply to some deployments. Line wraps within values are for display purposes only.

POST /backchannel-authorization-endpoint HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

request=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6InRocndxbnVl
ciJ9.eyJpc3MiOiIzMDExODMzNzM4MTQ5NzkiLCJhdWQiOiJodHRwczovL3NlcnZ
lci5leGFtcGxlLmNvbS8iLCJpYXQiOjE1NjQ5MDI3MzgsIm5iZiI6MTU2NDkwMjc
zOCwiZXhwIjoxNTY0OTAzMDM4LCJqdGkiOiJBSnhaUnBOcWxnNjJVVGR5MzdndSI
sInNjb3BlIjoib3BlbmlkIHBheW1lbnRzIiwiYWNyX3ZhbHVlcyI6InVybjptYWN
lOmluY29tbW9uOmlhcDpzaWx2ZXIgdXJuOm1hY2U6aW5jb21tb246aWFwOmJyb25
6ZSIsImNsaWVudF9ub3RpZmljYXRpb25fdG9rZW4iOiJfTWlVT1kwN0VPQ3ZXUjV
CVnVPTD0iLCJsb2dpbl9oaW50Ijoiam9obkBleGFtcGxlLmNvbSIsImJpbmRpbmd
fbWVzc2FnZSI6IlMyNFIiLCJ1c2VyX2NvZGUiOiI2MzY1IiwicmVxdWVzdGVkX2V
4cGlyeSI6IjEyMCIsInJlcXVlc3RfY29udGV4dCI6eyJsb2NhdGlvbiI6eyJsYXQ
iOjUxLjE3Mzk3LCJsbmciOi0xLjgyMjM4fX0sInBheW1lbnRfaW50ZW50Ijp7ImF
tb3VudCI6IjE2NS44OCIsImN1cnJlbmN5IjoiR0JQIiwiY3JlZGl0b3JfYWNjb3V
udCI6eyJzY2hlbWVfbmFtZSI6IlVLLk9CSUUuU29ydENvZGVBY2NvdW50TnVtYmV
yIiwiaWRlbnRpZmljYXRpb24iOiIwODA4MDAyMTMyNTY5OCIsIm5hbWUiOiJBQ01
FIEluYyJ9fX0.6YQ2j27lXlsfw5QFUoDDbkXJnu8ldi6Tw8LwUEg_C1w2ru_tksY
yIN81jv4Q0NXwRBtWsojahPFynZJa39Q3Yg&
client_assertion=eyJraWQiOiJ0aHJ3cW51ZXIiLCJhbGciOiJFUzI1NiJ9.ey
JzdWIiOiIzMDExODMzNzM4MTQ5NzkiLCJhdWQiOiJodHRwczovL3NlcnZlci5leG
FtcGxlLmNvbS8iLCJpc3MiOiIzMDExODMzNzM4MTQ5NzkiLCJleHAiOjE1NjQ5MD
I3OTgsImlhdCI6MTU2NDkwMjczOCwianRpIjoiNnNSVndWdVpseDFERUJjSEVIaH
gifQ.b9fpM3hUv5Nex9DZOYS8AGUiBMIFnlvf5YgRmUqzBhljIGr4M5f-mkt2VOM
ImaKe-LaUMeD5y_PZGaBiDTo50A&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-asser
tion-type%3Ajwt-bearer

This example contains the JWT payload:

{
  "iss": "301183373814979",
  "aud": "https://server.example.com/",
  "iat": 1564902738,
  "nbf": 1564902738,
  "exp": 1564903038,
  "jti": "AJxZRpNqlg62UTdy37gu",
  "scope": "openid",
  "login_hint": {
    "format": "phone_number",
    "phone_number": "+61400000000"
  }
  "binding_message": "S24R",
  "user_code": "6365",
  "requested_expiry": "120",
  "request_context": {
    "location": {
      "lat": 51.17397,
      "lng": -1.82238
    }
  },
}

9.2. Version 1.0 Implementers Draft 2

Published: 13th November 2025

Changes:

  • Renamed specification
  • Added use case details
  • Addressing review comments
  • Cleanup references

9.3. Version 1.0 Implementers Draft 1

Published: 15th November 2022

Changes:

  • Initial draft for discussion