digitalid-cr-05 October 2025
TBC Standards Track [Page]
Workgroup:
DigitalID Security
Published:
Author:
TBC. TBC
DigitalID

DigitalID Client Registration 1.0 Implementers' Draft 5

Foreword

The DigitalID Solution Working Group is responsible for creating standards and specifications necessary to meet the requirements and obligations of the Australian Payments Plus DigitalID Scheme. There is a possibility that some of the elements of this document may be the subject to patent rights.

Introduction

The DigitalID Financial-grade API Client Registration Document sets out the client metadata that is made available from the Directory of Participants and how it should be mapped to client configuration by Identity Providers. The Identity Providers must synchronise the client metadata from the registry into their systems in order to onboard clients. This document describes the synchronisation process and requirements.

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 key words are not used as dictionary terms such that any occurrence of them shall be interpreted as key words and are not to be interpreted with their natural language meanings.

Table of Contents

1. Scope

This document specifies the:

This document is applicable to all participants engaging in DigitalID.

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

RFC7519 - JSON Web Token (JWT)

RFC7591 - OAuth 2.0 Dynamic Client Registration Protocol

OIDC - OpenID Connect Core 1.0 incorporating errata set 1

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

DigitalID-FAPI - DigitalID FAPI Security Profile 1.0

3. Terms and definitions

For the purpose of this document, the terms defined in DigitalID-FAPI, OpenID Connect Core apply.

4. Symbols and Abbreviated terms

API – Application Programming Interface

FAPI - FAPI security profile

HTTP – Hyper Text Transfer Protocol

OIDF - OpenID Foundation

OP - OpenID Provider

REST – Representational State Transfer

SS – Software Statement

SSA – Software Statement Assertion

TLS – Transport Layer Security

5. Introduction

ConnectID's ecosystem leverages a federation trust provider or directory of participants as the golden source of information on accredited participants and software that are authorized to partake in the DigitalID ecosystem.

The services by the Registry include:

Together these services provide everything necessary to discover and register clients with providers within the scheme.

6. ConnectID OpenID Connect Registration

This specification defines the mechanism by which Clients are registered with Identity Providers.

As part of the onboarding and configuration process, Relying Parties Clients and associated metadata will be configured in the Digital Identity Registry. Identity Providers are required to synchronise the client information from the Registry to their Authorisation Servers to enable the Clients to be used.

IDP shall implement one of the following options for client synchronisation with the Registry: 1. Initial synchronisation (full) and periodic synchronisation at a regular intervals. Maximum refresh period shall be every 2 hours. Minimum refresh period shall be every 15 minutes. Recommended refresh period should be every hour. 2. Initial synchronisation (full) and monitoring for updates via webhooks.

In addition to client synchronisation, IDP shall: 1. Periodically refresh client's JWKS. Maximum refresh period shall be every 15 minutes. Minimum refresh period shall be every 1 minutes. Recommended refresh period should be every 5 minutes.

6.1. Synchronisation details

The Registry provides APIs that allow all client metadata for all organisations to be retrieved, enabling Identity Providers to register Clients. The provided APIs:

  • shall be REST/JSON APIs
  • shall support the Resource Server provisions as defined in the DigitalID-FAPI
  • shall support retrieval of the information necessary for an Identity Provider to register a Client in their Authorisation Server
  • shall support retrieval of all Clients' metadata, with optional filtering of Clients based on the Client's last updated time

ConnectID IDPs: - shall use the ConnectID Registry as an Authorisation server to obtain an access token - shall obtain an access token (sender constrained using MTLS) from the Registry token_endpoint using a client credentials grant - should use token_endpoint authentication mechanism as per DigitalID-FAPI - may use mtls as the token_endpoint authentication mechanism (to be deprecated at a later stage) - shall use the Registry token_endpoint advertised in mtls_endpoint_aliases as per clause 5 RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

The Registry provides one API for Identity Providers that is used to retrieve all Relying Party Clients. The API is:

  • GET /clients - allows retrieval of all Relying Party Client's metadata

The client metadata returned will contain claims as described in section "8.1 Software Statement Claims", in addition to metadata for the Relying Party Organisation. This will provide all required information for an Identity Provider to register the Client with their Authorisation server.

The OpenAPI specs for the Registry Client Registration APIs are available from: https://github.com/connectid-tools/specifications.

The expected pattern that Identity Providers will use to retrieve Client information using the APIs is shown below:

          .---.                                                        .--------.
          |IDP|                                                        |Registry|
          '---'                                                        '--------'
            |                                                               |
            |            POST /token (MTLS client authentication)           |
            |                   (client credentials grant)                  |
            |-------------------------------------------------------------->|
            |                                                               |
            |                          access token                         |
            |<--------------------------------------------------------------|
            |                                                               |
            |                 GET /clients                  |
            |                      (MTLS + access token)                    |
            |-------------------------------------------------------------->|
            |                                                               |
            |                    list of all clients                        |
            |<--------------------------------------------------------------|
            |                                                               |
  --------> |                                                               |
 | for      |--------                                                       |
 | each     |        | Register Client                                      |
 | client   |<-------                                                       |
  --------- |                                                               |
            |                                                               |
          .---.                                                        .--------.
          |IDP|                                                        |Registry|
          '---'                                                        '--------'

7. Software Statement

A software statement is a JSON Web Token (JWT) RFC7519 that asserts metadata values about the client software as a bundle.

7.1. Software Statement Claims

A Software Statement issued by the Registry shall contain the following claims

Table 1
Software Statement Attribute Example Value Client Metadata in RFC7591 Display on OP Consent UI Additional Processing Requirements
redirect_uris [ "https://my.accountingapp.com/cb" ] Yes No Redirect URIs should be unique between each RP and OP pair
token_endpoint_auth_method "private_key_jwt" Yes No Is currently fixed to "private_key_jwt" only
grant_types ["authorization_code"] Yes No
response_types ["code"] Yes No
client_name "Great Accounting App" Yes Yes
client_uri "https://my.accountingapp.com" Yes Yes
logo_uri "https://my.accountingapp.com/logo.svg" Yes Yes
scope "openid" Yes No
tos_uri "https://my.accountingapp.com/tos.html" Yes tbc
policy_uri "https://my.accountingapp.com/policy.html" Yes tbc
jwks_uri "https://keystore.directory.sandbox.connectid.com.au/c0ab3873-d86d-430e-bf09-63a097dd5f59/26c2183c-5e9c-4a63-bc65-164d8e316719/application.jwks" Yes No
software_id "26c2183c-5e9c-4a63-bc65-164d8e316719" Yes No
software_version "1.0" Yes No
client_id "26c2183c-5e9c-4a63-bc65-164d8e316719" No No The non-standard client_id claim will be added to the software statement, and will facilitate an ecosystem wide unique client_id - the client_id will hold the same value as the software_id
claims ["given_name", "family_name"] No Yes The list of allowed standard claims in verified_claims for a given RP
claims_in_verified_claims ["over18", "over65"] No Yes The list of allowed claims in verified_claims for a given RP
subject_type "pairwise" No No The subject type returned in the sub value of the id_token
sector_identifier_uri "https://my.accountingapp.com/redirect_uris.json" No No This attribute is needed to support pairwise pseudonymous identifier (PPID) as the subject identifier. The values registered in redirect_uris must be included in the elements of the array, or registration must fail.
application_type "web" No No
client_description "This is a long detailed description of the application" No tbc

The following is a non-normative example of a software statement that can be issued from the directory of participants.

{
  "iat": "1643723203",
  "iss": "sandbox SSA issuer",
  "redirect_uris": ["https://my.accountingapp.com/cb"],
  "token_endpoint_auth_method": "private_key_jwt",
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "client_name": "Great Accounting App",
  "client_uri": "https://my.accountingapp.com",
  "logo_uri": "https://my.accountingapp.com/logo.svg",
  "scope": "openid",
  "tos_uri": "https://www.accountingapp.com/terms.html",
  "policy_uri": "https://my.accountingapp.com/policy.html",
  "jwks_uri": "https://keystore.directory.sandbox.connectid.com.au/c0ab3873-d86d-430e-bf09-63a097dd5f59/26c2183c-5e9c-4a63-bc65-164d8e316719/application.jwks",
  "software_id": "26c2183c-5e9c-4a63-bc65-164d8e316719",
  "software_version": "1.0",
  "client_id": "26c2183c-5e9c-4a63-bc65-164d8e316719",
  "sector_identifier_uri": "https://my.accountingapp.com/redirect_uris.json",
  "subject_type": "pairwise",
  "claims": ["given_name", "family_name", "address"],
  "claims_in_verified_claims": ["over18", "over21"],
  "application_type": "web",
  "client_description": "This is a long detailed description of the application",
  "environment": "Production",
  "jwks_inactive_uri": "https://keystore.directory.sandbox.connectid.com.au/c0ab3873-d86d-430e-bf09-63a097dd5f59/26c2183c-5e9c-4a63-bc65-164d8e316719/inactive/application.jwks",
  "jwks_transport_inactive_uri": "https://keystore.directory.sandbox.connectid.com.au/c0ab3873-d86d-430e-bf09-63a097dd5f59/26c2183c-5e9c-4a63-bc65-164d8e316719/inactive/transport.jwks",
  "jwks_transport_uri": "https://keystore.directory.sandbox.connectid.com.au/c0ab3873-d86d-430e-bf09-63a097dd5f59/26c2183c-5e9c-4a63-bc65-164d8e316719/transport.jwks",
  "mode": "Live",
  "roles": [],
  "status": "Active",
  "org_id": "c0ab3873-d86d-430e-bf09-63a097dd5f59",
  "org_jwks_inactive_uri": "https://keystore.directory.sandbox.connectid.com.au/c0ab3873-d86d-430e-bf09-63a097dd5f59/inactive/application.jwks",
  "org_jwks_transport_inactive_uri": "https://keystore.directory.sandbox.connectid.com.au/c0ab3873-d86d-430e-bf09-63a097dd5f59/inactive/transport.jwks",
  "org_jwks_transport_uri": "https://keystore.directory.sandbox.connectid.com.au/c0ab3873-d86d-430e-bf09-63a097dd5f59/transport.jwks",
  "org_jwks_uri": "https://keystore.directory.sandbox.connectid.com.au/c0ab3873-d86d-430e-bf09-63a097dd5f59/application.jwks",
  "org_name": "Test Org",
  "org_number": "ABN123123123",
  "org_status": "Active",
  "organisation_competent_authority_claims": [
    {
      "authorisation_domain": "DigitalID",
      "authorisations": [],
      "registration_id": "BISROLE",
      "authority_name": "DigitalID Authority",
      "authority_id": "b44fac7c-af64-4948-8638-130d1cdf7f4d",
      "authorisation_role": "BIS",
      "authority_code": "ID",
      "status": "Active"
    }
  ]
}

Appendix A. Change History

A.1. Version 1.0 Implementers Draft 5

Published: 10th May 2024

Changes:

  • Corrected typos (29th April 2024)
  • Updated ConnectID URLs (6th May 2024)
  • Corrected response_types example (6th May 2024)
  • Added default authentication mechanism for ConnectID token endpoint as compliant with ConnectID FAPI profile (8th May 2024)
  • Removed obsolete references (10th May 2024)

A.2. Version 1.0 Implementers Draft 4

Published: 7th November 2023

Changes:

  • Clarify frequency of the registry sync (3rd October 2022)
  • Clarify frequency of JWKS refresh (3rd October 2022)
  • Add verified_claims restriction for RPs (3rd October 2022)
  • Remove internal registry role mapping (3rd October 2022)
  • Update registry URLs (3rd October 2022)
  • Clients endpoint is updated (7th November 2023)

A.3. Version 1.0 Implementers Draft 3

Published: 18th June 2022

Changes:

  • Specified that client registration is a IDP responsibility and must be performed using periodic synchronisation
  • Included details of synchronisation methods and endpoints

Appendix B. Notices

Copyright (c) 2024 Australian Payments Plus (ConnectID).

Author's Address

TBC
DigitalID