connectid-identity-assurance-profile-08 October 2025
Postnikov Standards Track [Page]
Workgroup:
ConnectID Security
Published:
Author:
DP. Postnikov
ConnectID

ConnectID Identity Assurance Profile 1.0 Implementers' Draft 8

Foreword

This specification is a part of standards and specifications necessary to meet the requirements and obligations of the Australian Payments Plus ConnectID Scheme. There is a possibility that some of the elements of this document may be the subject to patent rights. Australian Payments Plus shall not be held responsible for identifying any or all such patent rights.

The ConnectID specifications consist of the following parts:

Introduction

The ConnectID Identity Assurance profile aims to provide specific implementation guidelines for regarding the provision of identity information 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 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 method of:

This document is applicable to all participants engaging in ConnectID.

2. Normative references

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

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

RFC3966 - The tel URI for Telephone Numbers

RFC4627 - JavaScript Object Notation (JSON)

E.164 - The international public telecommunication numbering plan

OIDC - OpenID Connect Core 1.0 incorporating errata set 1

OIDI - OpenID Connect for Identity Assurance 1.0

RFC4122 - A Universally Unique IDentifier (UUID) URN Namespace

3. Terms and definitions

For the purpose of this document, the terms defined in OIDC and ISO29100 apply.

Customer - An End-User or a user utilising the services of Relying Party and authenticating with an OP.

4. Symbols and Abbreviated terms

acr - Authentication Context Class Reference

API – Application Programming Interface

FAPI - FAPI Security Profile

OIDF - OpenID Foundation

OP - OpenID Provider

PII - Personally Identifiable Information

PPID - Pairwise Pseudonymous Identifier

5. ConnectID Identity Assurance Profile

5.1. Authorisation Server

The Authorisation Server:

  1. shall support the claims parameter as defined in clause 5.5 OpenID Connect Core;
  2. shall not include an acr claim in the id_token;
  3. shall only advertise and support claims, verified claims and scopes defined in this specification except exceptions agreed with the network operator;
  4. shall advertise the only supported subject identifier type as "pairwise" in subject_types_supported in the OpenID discovery document - as defined in clause 8 OpenID Connect Core;
  5. shall populate the sub value in the id_token with a PPID for the Customer as defined in clause 8.1 OpenID Connect Core - this sub must be immutable, and must not be PII;
  6. shall populate the txn value in the id_token whether RP has requested it or not;
  7. shall not provide the Customer with the ability to opt out of releasing claims requested as essential, other than cancelling the entire flow;
  8. may provide the Customer with the ability to opt out of releasing Claims that were not requested as essential (ie: voluntary claims)
  9. shall not generate an error in the response when a Customer consents to share essential claims but the claims are not present in the IDP (eg: a Customer without a middle name consenting to share when middle_name was marked as essential). All available claims that the Customer has consented to share shall be returned;
  10. shall record the purpose supplied by the client for each transaction as defined in OAuth 2 Purpose extension and shall display purpose during the authorisation flow and in a Customer's consent history.
  11. shall validate that request contains au_connectid case-sensitive value in trust_framework JSON request object (as defined in OpenID Connect Core 5.5.1. Individual Claims Requests) and shall provide the same string value in the response, if verified_claims are requested;
  12. shall only respond with claims requested if they are provisioned for a particular Relying Party by the registry via client registration mechanism described in ConnectID-Client-Reg. All claims not allowed by the register should be ignored (preferred behaviour as oppose to rejecting these requests).
  13. shall advertise its presence in the ConnectID ecosystem by being listed on the Directory of Participants.

Note: if verified_claims are requested and if trust_framework in the request is absent, unknown, invalid or null value, verified_claims part of the request shall be ignored.

5.2. Confidential Client

The Confidential Client:

  1. shall support the claims parameter as defined in clause 5.5 OpenID Connect Core;
  2. shall only request claims, verified claims and scopes defined in this specification except exceptions agreed with the network operator;
  3. shall only request claims, verified claims and scopes that the client has been acredited for by the Register. Register client configuration reflects current accreditation status;
  4. shall request identity claims using the claims request parameter only as defined in OpenID Connect Core 5.4 - Requesting Claims using Claims Values;
  5. shall not request an acr claim value using either an individual acr claim request or acr_values request parameter;
  6. shall request identity claims be issued in an id_token;
  7. shall request 'txn' claim in an id_token;
  8. shall not request identity claims be issued via the user_info endpoint;
  9. shall rely on ecosystem discovery services provided by Directory of Participants only;
  10. shall supply purpose for each authorisation as defined in OAuth 2 Purpose extension. Purpose parameter should be limited to ASCII character set only;
  11. shall request au_connectid value in trust_framework as per the OpenID for Identity Assurance Specification, if verified_claims are requested. trust_framework should be requested as JSON request object (as defined in OpenID Connect Core 5.5.1. Individual Claims Requests);
  12. shall validate that response contains only au_connectid value in trust_framework string in verified_claims, if verified claims are requested.

5.3. Authorisation request

5.3.1. Request parameters

Table 1
Parameter Mandatory Description
claims optional JSON object as per the OpenID Connect Core Specification Clause 5.5.1 defining the identity claims your app is requesting for the Customer, containing claims as per Clause 5.4.3 below.
verified_claims optional JSON object as per the OpenID for Identity Assurance Specification defining the verified claims your app is requesting for the Customer, containing claims as per Clause 5.4.4 below.
scope required Must be set to openid for all requests to enable OpenID Connect

5.3.2. Standard claims

This specification defines a limited set of standard Claims which may be requested in the ID Token.

Table 2
Member Type Description Example
given_name string Given name(s) or first name(s) of the Customer. Note that in some cultures, people can have multiple given names; all can be present, with the names being separated by space characters. { "given_name": "John Barry" }
middle_name string Middle name(s) of the Customer. Note that in some cultures, people can have multiple middle names; all can be present, with the names being separated by space characters. Also note that in some cultures, middle names are not used. { "middle_name": "Fred" }
family_name string Surname(s) or last name(s) of the Customer. Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters. { "family_name": "Citizen" }
email string Customer's preferred e-mail address address { "email": "john@citizen.org" }
birthdate string Customer's birthday, represented as an ISO 8601:2004 [ISO8601‑2004] YYYY-MM-DD format { "birthdate": "1990-04-23" }
phone_number string Customer's preferred telephone number in E.164 format, for example, +1 425 555-1212 or +56 2 687 2400. If the phone number contains an extension, the extension shall be represented using the RFC3966 extension syntax, for example, +1 604 555-1234;ext=5678. { "phone_number": "+61 8 5555 1212" }
address JSON object Customer's residential address. The value of the address member is a JSON RFC4627 structure { "address": {"street_address": "140 Citizen Drive", "locality": "Melbourne", "region": "VIC", "postal_code": "4209", "country": "Australia"} }
txn string A unique identifier for the identity transaction as per OpenID Connect for Identity Assurance OIDI. Provides Relying Party with a unique reference for the transaction. This is a technical claim for Relying Party use and the request for the claim is not expected to be displayed to the customer by the IDP during the consent process. 2c6fb585-d51b-465a-9dca-b8cd22a11451
5.3.2.1. Address claim

The Address Claim represents a physical residential address.

Table 3
Member Type Description
street_address string Full street address component, which may include house number, street name, and multi-line extended street address information. This field may contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").
locality string City or locality component
region string State (abbreviated in capital letters)
postal_code string Zip code or postal code component
country string Country name component (full name)

5.3.3. Extended syntax claims (verified_claims)

This specification defines a limited set of extended claims which may be requested in the verified_claims section of the ID Token as defined in OIDI. Other claims defined in OIDI shall not be supported.

For overXX age assertions, a customer is considered to be overXX at 00:00 on the day they turn the age of XX. For example, if a customer's birthdate is the 2nd February 2000, they are considered over18 at 00:00 on the 2nd February 2018.

Table 4
Member Type Description
over16 boolean A flag indicating that the Customer is over 16. A customer is considered over 16 at 00:00 on the day they turn 16.
over18 boolean A flag indicating that the Customer is over 18. A customer is considered over 18 at 00:00 on the day they turn 18.
over21 boolean A flag indicating that the Customer is over 21. A customer is considered over 21 at 00:00 on the day they turn 21.
over25 boolean A flag indicating that the Customer is over 25. A customer is considered over 25 at 00:00 on the day they turn 25.
over65 boolean A flag indicating that the Customer is over 65. A customer is considered over 65 at 00:00 on the day they turn 65.
beneficiary_account_au JSON object as per Section 5.3.3.1.1 Verified bank account number (regular BSB and account details) that the Customer owns (as a single or joint owner) for the purpose of incoming payments (transaction, cheque and savings accounts).
beneficiary_account_au_payid JSON object as per Section 5.3.3.1.2 Verified bank account details (PayID) that the Customer owns (as a single or joint owner) for the purpose of incoming payments (transaction, cheque and savings accounts). If the Customer doesn't have a PayID, BSB and account number will be supplied.
beneficiary_account_international JSON object as per Section 5.3.3.1.3 Verified bank account details that the Customer owns (as a single or joint owner) for the purpose of incoming payments (transaction, cheque and savings accounts).
5.3.3.1. Extended syntax claim values

The structure of the extended claims values returned in the verified_claims section of the ID Token are defined below.

5.3.3.1.1. beneficiary_account_au

The fields to be returned in the beneficiary_account_au claim are:

Table 5
Fields Description
beneficiary_name the name of the Customer associated with the account
account_bsb the BSB of the account (number only
account_number the account number 
  "beneficiary_account_au": {
    "beneficiary_name": "John Smith",
    "account_bsb": "100200",
    "account_number": "12345678"
  }
5.3.3.1.2. beneficiary_account_au_payid

The fields to be returned in the beneficiary_account_au_payid are conditional upon whether the Customer has a PayID associated with their account.

If the Customer has a PayID, the following fields will be returned:

Table 6
Fields Description
beneficiary_name the legal name of the Customer associated with the account
payid the PayID associated with the Customer's account
payid_type the type of PayID associated with the Customer's account. Must be one of "/EMAL" (email address), "/TELI" (mobile number), "/AUBN" (ABN), "/ORGN" (Organisation Identifer)

Example:

  "beneficiary_account_au_payid": {
    "beneficiary_name": "John Smith",
    "payid": "0400000321",
    "payid_type": "/TELI"
  }

If the Customer does not have a PayID, then their BSB and account details shall be returned instead:

Table 7
Fields Description
beneficiary_name the legal name of the Customer associated with the account
account_bsb the BSB of the account
account_number the account number

Example:

  "beneficiary_account_au_payid": {
    "beneficiary_name": "John Smith",
    "account_bsb": "100200",
    "account_number": "12345678"
  }
5.3.3.1.3. beneficiary_account_international

The fields to be returned in the beneficiary_account_international claim are:

Table 8
Fields Description
beneficiary_name the legal name of the Customer associated with the account
bic_swift_code the Bank Identification Code (BIC) issued by SWIFT that identifies the Customer's bank
account_number_international the Customer's account number to be used when addressing the payment internationally. This is typically the Customer's BSB and Account number concatenated
beneficiary_residential_address the Customer's residential address. Address should follow the same representation as standard address claim described above but formatted as one string

Example:

  "beneficiary_account_international": {
    "beneficiary_name": "John Smith",
    "bic_swift_code": "XXXXXNNNNX",
    "account_number_international": "10020012345678",
    "beneficiary_residential_address": "255 George St, Sydney, NSW 2000, Australia"
  }

5.3.4. Beneficiary account verified claims request example

The following is a non-normative example of a request that contains beneficiary_account verified claim (BSB and account details):

{
  "id_token": {
    "verified_claims": {
      "verification": {
        "trust_framework": { value: "au_connectid" }
      },
      "claims": {
        "beneficiary_account_au": {
          "essential": true,
        }
      }
    }
  }
}

5.4. Authorisation response

5.4.1. Simple verified claims response example

The following is a non-normative example of verified_claims delivered via ID token.

{
  "iss": "https://server.example.com",
  "sub": "248289761",
  "aud": "https://rs.example.com/",
  "exp": 1544645174,
  "client_id": "s6BhdRkqt3_",
  "given_name": "Max",
  "verified_claims": {
    "verification": {
      "trust_framework": "au_connectid"
    },
    "claims": {
      "over18": true
    }
  }
}

5.4.2. Beneficiary account verified claims response example (BSB and account details)

The following is a non-normative example of beneficiary_account_au (BSB and account details) verified claim delivered via ID token.

{
  "iss": "https://server.example.com",
  "sub": "248289761",
  "aud": "https://rp.example.com/",
  "exp": 1544645174,
  "client_id": "s6BhdRkqt3_",
  "given_name": "John",
  "family_name": "Smith",
  "verified_claims": {
    "verification": {
      "trust_framework": "au_connectid"
    },
    "claims": {
      "beneficiary_account_au": {
        "beneficiary_name": "John Smith",
        "account_bsb": "100-200",
        "account_number": "12345678"
      }
    }
  }
}

5.4.3. Beneficiary account verified claims response example (PayID)

The following is a non-normative example of beneficiary_account_au_payid (PayID) verified claim delivered via ID token.

{
  "iss": "https://server.example.com",
  "sub": "248289761",
  "aud": "https://rp.example.com/",
  "exp": 1544645174,
  "client_id": "s6BhdRkqt3_",
  "given_name": "John",
  "family_name": "Smith",
  "verified_claims": {
    "verification": {
      "trust_framework": "au_connectid"
    },
    "claims": {
      "beneficiary_account_au_payid": {
        "beneficiary_name": "John Smith",
        "payid": "0400000321",
        "payid_type": "/TELI"
      }
    }
  }
}

5.4.4. Beneficiary account verified claims response example (BIC / SWIFT)

The following is a non-normative example of beneficiary_account_international (BIC / SWIFT) verified claim delivered via ID token. This is intended to be used for international payments.

{
  "iss": "https://server.example.com",
  "sub": "248289761",
  "aud": "https://rp.example.com/",
  "exp": 1544645174,
  "client_id": "s6BhdRkqt3_",
  "given_name": "John",
  "family_name": "Smith",
  "verified_claims": {
    "verification": {
      "trust_framework": "au_connectid"
    },
    "claims": {
      "beneficiary_account_international": {
        "beneficiary_name": "John Smith",
        "bic_swift_code": "XXXXXNNNNX",
        "account_number_international": "10020012345678",
        "beneficiary_residential_address": "255 George St, Sydney, NSW 2000, Australia"
      }
    }
  }
}

6. Acknowledgements

We would like to thank Dave Hyland, Mark Haine, Ralph Bragg, Paul Ruskin, Igor Janicijevic, Erik Pragt and everyone for their valuable feedback and contributions that helped to evolve this specification.

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

Appendix A. Notices

Copyright (c) 2025 Australian Payments Plus (ConnectID)

Appendix B. Appendix A: Change History

B.1. Version 1.0 Implementers' Draft 8

Published: 31st of July 2025

Changes:

  • Cleanup incorrect references (URLs and document sections)

B.2. Version 1.0 Implementers' Draft 7

Published: 8th of July 2025

Changes:

  • Remove the requirement for RPs to request beneficiary account details as non-essential. The guidance will now be provided in the RP user guide allowing for both essential and non-essential.
  • Specification renamed from DigitalID to ConnectID
  • Editorial - Update references, cleanup old introductions

B.3. Version 1.0 Implementers' Draft 6

Published: 8th of May 2024

Changes:

  • Removed name claim as redundant (29th of April 2024)
  • Clarification: Beneficiary account details shall be requested as non-essential (8th May 2024).

B.4. Version 1.0 Implementers' Draft 5

Published: 7th of December 2023

Changes:

  • Clarified address claim formatting in verified account details - same as standard claims (25th of September 2023)
  • Clarified country code should be a full country name (25th of September 2023)
  • Clarified BSB field should only have numbers, no dashes (25th of September 2023)
  • Clarified purpose display (21st of September 2023)
  • Clarified region (state) field formatting (20th of September 2023)
  • Minor editorials, broken URLs fixed (20th of September 2023)
  • Clarified expected age assertion handling on the day the customer turns the age (6th of September 2023)
  • Moved purpose request parameter to a different specification (6th of September 2023)
  • Removed support for a default purpose for a client (6th of September 2023)
  • trust_framework example corrected and its format clarified (6th of September 2023)
  • validation rules for trust_framework added and clarified (6th of September 2023)
  • purpose language clarified (1st of Decemmber 2023)
  • txn mandatory for RPs to supply, but OP generate txn whether it was requested or not (1st of December 2023).
  • ignore all unknown, unsupported or not allowed claims (1st of December 2023)
  • RPs should not ask claims they are not allowed to ask (5th of December 2023)

B.5. Version 1.0 Implementers Draft 4

Published: 21st March 2023

Changes:

  • Removed beneficiary account type in favour of 3 separate claims.

B.6. Version 1.0 Implementers Draft 3

Published: 10th February 2023

Changes:

  • Feedback from the implementers incorporated
  • Clarification that OIDI claims not defined in this specification shall not be supported
  • Default purpose clarification
  • Added over16 and over21
  • address clarification - residential address
  • Bank account details description clarified
  • Added support for private APIs
  • Consistent User, End-User, Customer terminology across the specification.
  • Updated FAPI 2 references
  • Updated acknowledgements
  • Remove references to irrelevant specifications

B.7. Version 1.0 Implementers Draft 2

Published: 16th January 2023

Changes:

  • Added bank account verified claim.

Published: 16th January 2023

Changes:

  • Add purpose per claim - the only way this currently can be done in OIDI.
  • Clearly define phone number format, remove Fire Services Credit Union number in phone number example 8-).

Published: 15th November 2022

Changes:

  • Add age assertions (over 18, over 25, over 65).

B.8. Version 1.0 Implementers Draft 1

Published: 30th September 2022

Changes:

  • Refactor of identity assurance specific requirements from original digitalid-financial-api-04.md specification into this standalone spec

Author's Address

Dima Postnikov
ConnectID
URI: www.connectid.com.au