Commonwealth Coat of Arms of Australia

Digital ID (AGDIS) Data Standards 2024


I, Katy Gallagher, Minister for Finance, acting as the Digital ID Data Standards Chair, make the following instrument.

 

Dated 7 November 2024

 

 

 

 

 

Katy Gallagher Minister for Finance

Digital ID Data Standards Chair


 

 

Contents

Chapter 1—Preliminary 1

  1.    Name..........................................................1
  2.    Commencement...................................................1
  3.    Authority.......................................................1
  4.    Definitions......................................................1
  5.    Meaning of federation protocol.........................................7
  6.    Meaning of technical relying party.......................................7
  7.    Abbreviations....................................................7
  8.    Key words.......................................................8
  9.    Incorporated instruments............................................10
  10.    Application—transitioned participating relying parties.........................10
  11.    Schedules......................................................12

Schedule 1—AGDIS Onboarding Specifications..............13

Schedule 2—AGDIS OpenID Connect Profile...............27

Schedule 3—AGDIS Attribute Profile.....................67

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

Chapter 1—Preliminary

 

  1.     Name

This instrument is the Digital ID (AGDIS) Data Standards 2024.

 

  1.     Commencement

This instrument commences at the same time as the Digital ID Act 2024

commences.

 

  1.     Authority

This instrument is made under section 99 of the Digital ID Act 2024.

 

  1.     Definitions

Note 1: A number of expressions used in this instrument are defined in the Act, including the following:

  1.       accredited attribute service provider;
  2.      accredited identity exchange provider;
  3.       accredited identity service provider;
  4.      attribute;
  5.       participating relying party;
  6.       restricted attribute.

Note 2: A number of expressions used in this instrument are defined in the Transitional Act, including the following:

  1.       ImmiCard;
  2.      marriage certificate;
  3.       medicare card;
  4.      passport.

Note 3: A number of expressions used in this instrument are defined in the Accreditation Rules, including the following:

  1.       authenticated session;
  2.      commencement of identity credential;
  3.       DI data environment;
  4.      identity proofing level;
  5.       IP level.

Note 4: A number of expressions used in this instrument are defined in the Digital ID Rules, including the following:

  1.       participating entity;
  2.      pairwise identifier.
  1.     Unless otherwise specified, expressions defined in the Transitional Act, the Accreditation Rules and the Digital ID Rules have the same meaning in this instrument.

Example: The expressions ‘ASP’, ‘ISP’ and ‘IXP’, which are used in the Accreditation Rules, have a different meaning in this instrument. Similarly, the expression ‘IXP’, which is used in the Digital ID Rules, has a different meaning in this instrument. See subsection (2) and section 1.7.

  1.     In this instrument:

access channel has the meaning in section 4.1.2 of Schedule 1 (AGDIS Onboarding Specifications).

Accreditation Data Standards means the Digital ID (Accreditation) Data Standards 2024.

Accreditation Rules means the Digital ID (Accreditation) Rules 2024.

Act means the Digital ID Act 2024.

attribute set has the same meaning as in section 1.1 of Schedule 3 (AGDIS Attribute Profile).

Note: Attributes are not unique to a single attribute set. The same attribute may be used across multiple attribute sets. Further information can be found in Schedule 3 (AGDIS Attribute Profile).

attribute sharing policy means any policy mentioned in Chapter 2 or Chapter 3 of Schedule 3 (AGDIS Attribute Profile) that describes rules to be applied when sharing attributes with a participating relying party.

authentication context class reference is an identifier for an authentication context class supported by OpenID Connect 1.0 and used in the Australian Government Digital ID System for the levels of assurance.

authentication level has the meaning given in the Accreditation Data Standards.

computed attribute means an attribute that is dynamically derived from the attributes in an attribute set using an algorithm.

consumer history, in relation to an individual, means the history of all the individual’s interactions with a participating accredited identity exchange provider.

Designated Identity Exchange Provider has the same meaning as in the Transitional Rules.

digital ID identifier means a unique identifier specified in section 2.2.1.1 of Schedule 3 (AGDIS Attribute Profile).

Digital ID Rules means the Digital ID Rules 2024.

Document Verification Service has the same meaning as ‘DVS’ in section 15 of the Identity Verification Services Act 2023.

evidence of identity has the same meaning as the National Identity Proofing Guidelines published by the Attorney-General’s Department.

Note: At the time this instrument was made, located at: https://www.ag.gov.au/national-security/publications/national-identity-proofing- guidelines.

federation protocol: see section 1.5.

general purpose identifier, in relation to an individual, means a unique identifier assigned by a participating accredited identity service provider:

  1.     to the individual; and
  2.     independently from a participating relying party or a participating accredited identity exchange provider.

incorporated instrument has the meaning given in subsection 1.9(1).

ITU E.164 means the standard for international public telecommunication structures published by the International Telecommunication Union.

Note: At the time this instrument was made, located at: https://www.itu.int/rec/T-REC-E.164-201011-I/en.

JSON Web Key Set has the same meaning as in RFC 7517.

JSON Web Token has the same meaning as in RFC 7517.

JavaScript Object Notation has the same meaning as in RFC 7517 and RFC 8259.

levels of assurance has the meaning given in section 2.1.3 of Schedule 1 (AGDIS Onboarding Specifications).

MAY: see section 1.8.

MUST and MUST NOT: see section 1.8.

OAuth 2.0 has the same meaning as in RFC 6749.

OpenID Connect Core 1.0 means the standard published by the OpenID Foundation for an identity layer which operates on top of RFC 6749.

Note: At the time this instrument was made, located at: https://openid.net/specs/openid-connect-core-1_0.html.

OpenID Connect Core 1.0 provider means an entity which incorporates OpenID Connect Core 1.0 into its operations.

OpenID Connect Discovery 1.0 means the specification titled OpenID Connect Discovery 1.0 incorporating errata set 2 published by the OpenID Foundation.

Note: At the time this instrument was made, located at: https://openid.net/specs/openid-connect-discovery-1_0.html.

OpenID Connect Extended Authentication Profile (EAP) ACR Values 1.0 means the standard used to request specific authentication context classes, published by the OpenID Foundation.

Note: At the time this instrument was made, located at: https://openid.net/specs/openid-connect-eap-acr-values-1_0.html.

OPTIONAL: see section 1.8.

proof key for code exchange has the same meaning as in RFC 7636. RECOMMENDED and NOT RECOMMENDED: see section 1.8. REQUIRED: see section 1.8.

participating accredited attribute service provider means an accredited attribute service provider that is participating in the Australian Government Digital ID System.

participating accredited identity exchange provider means an accredited identity exchange provider that is participating in the Australian Government Digital ID System.

participating accredited identity service provider means an accredited identity service provider that is participating in the Australian Government Digital ID System.

relying party audit ID means a transaction audit identifier for transactions between participating identity exchange providers and participating relying parties.

Note: The relying party audit ID is never shared with a participating identity service provider. A separate audit ID is shared between a participating identity exchange provider and a participating identity service provider.

RFC means a document published by the Internet Engineering Task Force that contains technical specifications regarding the internet.

Note: RFCs are freely available. For more information, see: https://www.ietf.org/process/rfcs/.

RFC 2119 means the RFC numbered 2119 and titled Key Words for use in RFCs to Indicate Requirement Levels.

Note 1: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc2119.

Note 2: See also RFC 8174 (Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words).

RFC 3339 means the RFC numbered 3339 and titled Date and Time on the Internet: Timestamps.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc3339.

RFC 3629 means the RFC numbered 3629 and titled UTF-8, a transformation format of Unicode and ISO 10646.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc3629.

RFC 3696 means the RFC numbered 3696 and titled Application Techniques for Checking and Transformation of Names.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc3696.

RFC 3986 means the RFC numbered 3986 and titled Uniform Resource Identifier (URI): Generic Syntax.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc3986.

RFC 4122 means the RFC numbered 4122 and titled A Universally Unique IDentifier (UUID) URN Namespace.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc4122.

RFC 5321 means the RFC numbered 5321 and titled Simple Mail Transfer Protocol.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc5321.

RFC 5322 means the RFC numbered 5322 and titled Internet Message Format.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc5322.

RFC 5646 means the RFC numbered 5646 and titled Tags for Identifying Languages.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc5646.

RFC 6749 means the RFC numbered 6749 and titled The OAuth 2.0 Authorization Framework.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc6749.

RFC 6750 means the RFC numbered 6750 and titled The OAuth 2.0 Authorization Framework: Bearer Token Usage.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc6750.

RFC 6819 means the RFC numbered 6819 and titled OAuth 2.0 Threat Model and Security Considerations.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc6819.

RFC 7009 means the RFC numbered 7009 and titled OAuth 2.0 Token Revocation.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc7009.

RFC 7517 means the RFC numbered 7517 and titled JSON Web Key (JWK).

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc7517.

RFC 7591 means the RFC numbered 7591 and titled OAuth 2.0 Dynamic Client Registration Protocol.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc7591.

RFC 7636 means the RFC numbered 7636 and titled Proof Key for Code Exchange by OAuth Public Clients.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc7636.

RFC 7662 means the RFC numbered 7662 and titled OAuth 2.0 Token Introspection.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc7662.

RFC 8141 means the RFC numbered 8141 and titled Uniform Resource Names.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc8141.

RFC 8174 means the RFC numbered 8174 and titled Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc8174.

RFC 8259 means the RFC numbered 8259 and titled The JavaScript Object Notation (JSON) Data Interchange Format.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc8259.

RFC 8446 means the RFC numbered 8446 and titled The Transport Layer Security (TLS) Protocol Version 1.3.

Note: At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc8446.

sector identifier has the same meaning as in OpenID Connect Core 1.0.

SHALL and SHALL NOT: see section 1.8.

single logout means the ability for an individual to initiate a logout process for relying parties that relied on a single logon session for the individual at an exchange operated by a participating accredited identity exchange provider.

single sign on means the ability for an individual to make use of their digital ID at multiple services in a short period of time, with a single user authentication.

technical relying party: see section 1.6.

technical relying party profile means the profile in Schedule 2 (AGDIS Open ID Connect Profile).

Transitional Act means the Digital ID (Transitional and Consequential Provisions) Act 2024.

Transitional Rules means the Digital ID (Transitional and Consequential Provisions) Rules 2024.

transitioned participating relying party means a relying party that is taken to be a participating relying party in accordance with subitem 4(2) of Schedule 1 to the Transitional Act.

Note: See also rules 2.3 and 2.4 of Part 2 of Chapter 2 of the Transitional Rules.

transitioned participating relying party service, in relation to a transitioned participating relying party, means the service that the entity is approved to provide, or provide access to, in accordance with subitem 4(2) of Schedule 1 to the Transitional Act.

Note: See also rules 2.3 and 2.4 of Part 2 of Chapter 2 of the Transitional Rules.

transport layer security has the same meaning as in RFC 8446. uniform resource identifier has the same meaning as in RFC 3986. uniform resource name has the same meaning as in RFC 8141.

UTF-8 means the standard for encoding electronic communications published by the Unicode Consortium.

Note: At the time this instrument was made, located at: https://www.unicode.org/versions/Unicode15.1.0/.

universally unique identifier has the same meaning as in RFC 4122.

 

  1.     Meaning of federation protocol
  1.     A federation protocol means an open protocol that enables participating entities to communicate with each other and share attributes of individuals in a trusted manner.
  2.     Subject to section 1.10, Schedule 2 (AGDIS OpenID Connect Profile) is the only federation protocol for the Australian Government Digital ID System.

 

  1.     Meaning of technical relying party

A technical relying party means:

  1.     a participating accredited identity exchange provider’s OpenID Connect Core 1.0 software used to co-ordinate the flow of data or information between entities participating in the Australian Government Digital ID System; or
  2.     a participating relying party’s OpenID Connect Core 1.0 software used to:
    1.     authenticate the participating relying party with the participating accredited identity exchange; and
    2.     request and receive information or data from the participating accredited identity exchange; or
  3.     a participating accredited attribute service provider’s OpenID Connect Core 1.0 software used to:
    1.     authenticate the participating accredited attribute service provider with the participating accredited identity exchange; and
    2.     request and receive information or data from the participating accredited identity exchange.

Note: To avoid doubt, a technical relying party is not a relying party as defined in section 9 of the Act.

 

  1.     Abbreviations

In this instrument, an abbreviation mentioned in column 1 of an item in the following table has the meaning set out in column 2 of that item.

 

Abbreviations

Item

Column 1

Column 2

 

Abbreviation

Meaning

1

ACR

authentication context class reference

2

AGDIS

Australian Government Digital ID System

3

AL

authentication level

4

ASP

participating accredited attribute service provider

5

BDM

State and/or Territory Registry of Births, Deaths and Marriages

6

CoI credential

commencement of identity credential

7

DVS

Document Verification Service

8

EoI

evidence of identity

9

GPI

general purpose identifier

10

IP level

identity proofing level

11

IP#

identity proofing level number (for example, IP1, IP1 Plus, IP2, IP2 Plus, IP3, IP4)

12

ISP

participating accredited identity service provider

13

IXP

participating accredited identity exchange provider

14

JSON

JavaScript Object Notation

15

JWKS

JSON Web Key Set

16

JWT

JSON Web Token

17

OIDC provider

OpenID Connect Core 1.0 provider

18

PKCE

proof key for code exchange

19

PRP

participating relying party

20

RP audit ID

relying party audit ID

21

SLO

single logout

22

SSO

single sign on

23

TLS

transport layer security

24

TRP

technical relying party

25

URI

uniform resource identifier

26

URN

uniform resource name

27

UUID

universally unique identifier

 

  1.     Key words
  1.     In this instrument, and in each incorporated instrument, a capitalised term mentioned in column 1 of an item in the following table (key word) has the meaning and effect, in relation to an entity, set out in column 2 of that item subject to any exception or requirement in column 3 of that item.

 

 


Section 1.8

 

Key words

Item

Column 1

Column 2

Column 3

 

Key word

Meaning and effect

Exception/requirement

1

MAY

Optional—the entity has discretion in relation to the behaviour

Except where it is necessary to:

  1.   interoperate with another implementation which does or does not include the option, in which case the entity MUST or MUST NOT implement the behaviour, as the case requires, to interoperate with the other implementation; or
  2.   comply with a condition imposed on the entity’s approval to participate in the AGDIS under section 64 of the Act, in which case the entity MUST or MUST NOT

implement the behaviour,

as the case requires, to comply with that condition.

2

MUST

Absolute requirement—the entity has no discretion in relation to the behaviour.

 

3

MUST NOT

Absolute prohibition—the entity has no discretion in relation to the behaviour.

 

4

NOT RECOMMENDED

There may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before the entity implements any

behaviour to which this term applies

Same as item 1.

5

OPTIONAL

Same as item 1

Same as item 1.

6

RECOMMENDED

There may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before the entity implements a different

behaviour to which this term applies

Same as item 1.

 

Key words

Item

Column 1

Column 2

Column 3

 

Key word

Meaning and effect

Exception/requirement

7

REQUIRED

Same as item 2.

 

8

SHALL

Same as item 2.

 

9

SHALL NOT

Same as item 3.

 

10

SHOULD

Same as item 6

Same as item 1.

11

SHOULD NOT

Same as item 4

Same as item 1.

  1.     RFC 2119 and RFC 8174 do not apply to the interpretation of a key word appearing in:
    1.     this instrument; or
    2.     an incorporated instrument to the extent that this instrument applies, adopts or incorporates, with or without modification, any matter contained in the incorporated instrument.

 

  1.     Incorporated instruments
  1.     If a provision of this instrument applies, adopts or incorporates, with or without modification, any matter contained in any other instrument or other writing (incorporated instrument), then, unless the contrary intention appears in the provision, the reference to the incorporated instrument is a reference to the incorporated instrument as in force at the commencement of this instrument.
  2.     For the avoidance of doubt, if an incorporated instrument expressly refers to or requires compliance with any other instrument or other writing, then, the reference to the other instrument or other writing is a reference to the other instrument or other writing as in force at the commencement of this instrument.

Example: Section 10.9 of RFC 6749 provides that the authorisation server MUST require the use of TLS with server authentication as defined by RFC 2818 for certain purposes.

RFC 2818 was obsoleted (superseded) by RFC 9110 in June 2022. RFC 9110, as published in June 2022, was in force at the commencement of this instrument.

Therefore, for the purposes of section 10.9 of RFC 6749, the reference to RFC 2818 is taken to be a reference to RFC 9110.

Note: RFC 9110 means the RFC numbered 9110 and titled HTTP Semantics. At the time this instrument was made, located at: https://datatracker.ietf.org/doc/html/rfc9110.

 

  1.     Application—transitioned participating relying parties
  1.     This section applies to:
    1.     a transitioned participating relying party:
      1.     specified in column 1 of an item in the following table;
      2.     when participating in the Australian Government Digital ID System; and
      3.     in relation to the transitioned participating relying party service specified in column 2 of that item; and
    2.     the Designated Identity Exchange Provider.

 

 

Section 1.10

 

Transitioned participating relying parties and services

Item

Column 1

Column 2

 

Entity

Service

1

Australian Communications and Media Authority

ACMA Lodgement Facility.

2

Australian Prudential Regulation Authority

APRA Connect.

3

Australian Prudential Regulation Authority

APRA Connect (External Test).

4

Australian Prudential Regulation Authority

APRA Extranet.

5

Commissioner of State Revenue (Victoria)

PTX Express.

6

Commissioner of Taxation

Australian Business Register Explorer.

7

Commonwealth Department of Employment and Workplace Relations

SkillSelect.

8

Commonwealth Department of Social Services

Humanitarian Settlement Program.

9

Commonwealth Department of the Treasury

Franchise Disclosure Register.

10

Commonwealth Department of the Treasury

Payment Times Reporting Portal.

11

Commonwealth Department of the Treasury

Treasury Authentication Broker.

12

Northern Territory Department of Corporate and Digital Development

InvoiceNTG.

13

Northern Territory Department of Industry, Tourism and Trade

Vocational Education and Training Provider Portal.

14

Northern Territory Department of Infrastructure, Planning and Logistics

Motor Vehicle Registry for Business.

15

Tasmanian State Revenue Office

Tasmanian Revenue Online.

16

Workplace Gender Equality Agency

WGEA Employer Portal.

Transitioned participating relying party

(2) Unless subsection (3) or (4) applies:

  1.     a provision, or part of a provision, of this instrument that contains a requirement in relation to Schedule 2 (AGDIS OpenID Connect Profile) only applies to a transitioned participating relying party in relation to the entity’s transitioned participating relying party service on and from the specified day; and
  2.     every provision, or every part of a provision, of this instrument not specified in paragraph (a) applies to that entity in relation to that service in accordance with its terms and on and from the commencement of this instrument.

Example:  If this instrument commences on 1 December 2024 and the specified day is 1 December 2029 (see subsection (6)), then a provision or part of a provision

mentioned in paragraph (b) applies on and from 1 December 2024, and a provision or part of a provision mentioned in paragraph (a) applies on and from 1 December 2029.

  1.     If a transitioned participating relying party is required by this instrument, or another instrument made under section 99 of the Act, to comply with Schedule 2 (AGDIS OpenID Connect Profile) in relation to the entity’s transitioned participating relying party service at a particular time after commencement of

this instrument and before the specified day, then Schedule 2 (AGDIS OpenID Connect Profile) applies to that entity in relation to that service at that time.

  1.     If a transitioned participating relying party is required by this instrument, or another instrument made under section 99 of the Act, to comply with an alternative federation protocol that supports Security Assertion Markup Language in relation to the entity’s transitioned participating relying party service at a particular time after commencement of this instrument and before the specified day, then the alternative federal protocol applies to that entity in relation to that service at that time.

Designated Identity Exchange Provider

  1.     If a provision, or part of a provision, of this instrument that contains a requirement in relation to Schedule 2 (AGDIS OpenID Connect Profile) does not apply to a particular transitioned participating relying party, then that provision, or that part of the provision, does not apply to the Designated Identity Exchange Provider to the extent that:
    1.     the Designated Identity Exchange Provider conveys, manages or coordinates the flow of data or other information in Security Assertion Markup Language within the Australian Government Digital ID System; and
    2.     the activity mentioned in paragraph (a) enables the transitioned participating relying party to participate in the Australian Government Digital ID System.

Definition

  1.     In this section:

specified day means the day that is 5 years after the day on which this instrument commences.

 

  1.     Schedules

Each instrument that is specified in a Schedule to this instrument is amended or repealed as set out in the applicable items in the Schedule concerned, and any other provision (however described) in a Schedule to this instrument has effect according to its terms.

 

 

 

 

 

Branding shape for Australia's Digital ID System

 

 

 

Schedule 1 AGDIS Onboarding Specifications

 

Contents

  1.          Common requirements for participating accredited entities..................1
    1.      Security considerations.....................................................1
    2.      Identity resolution.........................................................1
      1.       General purposes identifiers...............................................1
      2.       Pairwise identifiers.......................................................1
      3.       Sector Identifiers........................................................1
    3.      Data sharing.............................................................2
      1.       Request processing......................................................2
  2.      Identity exchange provider...........................................3
    1.      Technical integration requirements...........................................3
      1.       Protocol requirements....................................................3
      2.       Audit requirements.......................................................3
      3.       Levels of assurance......................................................3
      4.       Identity resolution........................................................5
      5.       Authenticated sessions...................................................5
      6.       Single sign on...........................................................5
      7.       Single logout............................................................5
      8.       Attribute service provider integration.........................................5
      9.       Federation protocol brokering..............................................6
    2.      Identity provider selection...................................................6
      1.       Blinding................................................................6
    3.      User dashboard...........................................................7
    4.      Data requirements........................................................7
      1.       Attribute requirements....................................................7
      2.       Computed attributes......................................................7
      3.       Attribute sharing policy....................................................7
      4.       Data representation......................................................8
  3.      Identity service provider.............................................8
    1.      Technical integration requirements...........................................8
      1.       Protocol requirements....................................................8
      2.       Identity resolution........................................................8
      3.       Single sign on...........................................................8
      4.       Single logout............................................................8
  1.      Data requirements........................................................9
    1.       Attribute requirements....................................................9
    2.       Computed attributes......................................................9
  1.      Attribute service provider............................................9
    1.      Technical integration requirements...........................................9
      1.       Protocol requirements....................................................9
      2.       Access channels........................................................9
    2.      Audit logging............................................................10
    3.      Attribute schema.........................................................10

List of Tables

Table 1 Level of assurance combinations used in the AGDIS.........................4

Table 2 Mapping of new authentication levels to legacy credential levels................4

 

 

 

1.        Common requirements for participating accredited entities

This Chapter outlines the role requirements, where applicable, that MUST be met by ASPs, ISPs and IXPs.

 

ASPs, ISPs and IXPs:

  1.             MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and
  2.             SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.

 

An IXP MUST NOT issue a GPI.

An ISP MAY issue a GPI. Where an ISP chooses to issue a GPI, the ISP MUST:

(a)            bind the GPI to only a single digital ID account;

(b)            only use the GPI within the AGDIS;

(c)            only use the GPI to map the individual’s digital ID to a single IXP; and

(d)            issue additional GPIs for each IXP an individual accesses.

A GPI MUST be unique within the DI data environment of the ISP that issues it.

 

An IXP MUST issue a pairwise identifier.

An ISP SHOULD issue a pairwise identifier. If an ISP issues a pairwise identifier, the ISP MUST NOT issue a GPI.

IXPs or ISPs that issue digital ID identifiers as pairwise identifiers MUST generate the identifiers in accordance with the algorithm outlined in section 8.1 (Pairwise Identifier Algorithm) of OpenID Connect Core 1.0.

 

IXPs and ISPs SHOULD use sector identifiers.

The scope of a sector identifier MUST be limited as per the role specific role requirements outlined in the following specified sections of OpenID Connect Core 1.0.

 

 

If a sector identifier is used, it MUST conform to the definition outlined in the following specified sections of OpenID Connect Core 1.0.

For this standard, the following sections of OpenID Connect Core 1.0 are specified:

(a)            section 1.2 (Terminology); and

(b)            section 8.1 (Pairwise Identifier Algorithm).

 

Irrespective of the federation protocol used, ASPs, ISPs and IXPs MUST handle and transmit data in accordance with the data sharing policies outlined in Schedule 3 (AGDIS Attribute Profile).

 

ASPs, ISPs and IXPs MUST NOT attempt to fulfill requests for unknown attributes or attribute sets.

Requests for known attributes or attribute sets that cannot be fulfilled, regardless of the reason, MUST NOT be returned with empty values unless explicitly permitted by an attribute sharing policy as outlined in Schedule 3 (AGDIS Attribute Profile).

 

2.        Identity exchange provider

This Chapter outlines the requirements that MUST be met by IXPs.

 

An IXP MUST implement Schedule 2 (AGDIS OpenID Connect Profile) for an:

(a)            IXP acting as an OIDC provider; and

(b)            IXP acting as TRP to an ISP.

 

An IXP MUST generate the RP Audit ID attribute as outlined in Schedule 3 (AGDIS Attribute Profile).

The IXP MUST provide the RP Audit ID attribute it generated in response to every logical transaction between itself (the IXP) and the PRP (including ASPs).

The IXP MUST include the RP Audit ID attribute it generated for the PRP’s authentication request in every logical transaction between itself and each of the ASPs required to fulfill the attribute requirements of a PRP’s authentication request.

The IXP MUST NOT send the RP Audit ID attribute it generated for the PRP’s authentication request to its ISP.

 

Levels of assurance are used to define the IP level and AL of an individual’s authenticated session.

Levels of assurance are ranked from the lowest to the highest degree of confidence in the authentication process. The rankings of levels of assurance are specified in Table 1below.

Note the URNs in Table 1below MUST reference the legacy acronym cl (credential level) in their namespace to represent AL.

A mapping of the new ALs to the legacy credential levels, used in the URNs outlined in Table 1, is provided below in Table 2.

An IXP MUST allow a PRP to request a minimum level of assurance when making authentication requests.

 

 

Table 1 Level of assurance combinations used in the AGDIS.

 

Identity proofing level

Authentication level

URN

Ranking (low to high)

IP1

AL1

 

urn:id.gov.au:tdif:acr:ip1:cl1

1

 

AL2

 

urn:id.gov.au:tdif:acr:ip1:cl2

2

 

AL3

 

urn:id.gov.au:tdif:acr:ip1:cl3

3

IP1 Plus

AL1

 

urn:id.gov.au:tdif:acr:ip1p:cl1

4

 

AL2

 

urn:id.gov.au:tdif:acr:ip1p:cl2

5

 

AL3

 

urn:id.gov.au:tdif:acr:ip1p:cl3

6

IP2

AL2

 

urn:id.gov.au:tdif:acr:ip2:cl2

7

 

AL3

 

urn:id.gov.au:tdif:acr:ip2:cl3

8

IP2 Plus

AL2

 

urn:id.gov.au:tdif:acr:ip2p:cl2

9

 

AL3

 

urn:id.gov.au:tdif:acr:ip2p:cl3

10

IP3

AL2

 

urn:id.gov.au:tdif:acr:ip3:cl2

11

 

AL3

 

urn:id.gov.au:tdif:acr:ip2p:cl2

12

IP4

AL3

 

urn:id.gov.au:tdif:acr:ip4:cl3

13

 

 

Table 2 Mapping of new authentication levels to legacy credential levels.

 

Authentication level

Credential level

AL1

CL1

AL2

CL2

AL3

CL3

 

An IXP MUST generate pairwise identifiers as required in section 1.2.2 of this Schedule.

If an IXP does not use sector identifiers, the IXP MUST generate a pairwise identifier for every distinct service it connects, even if these services are operated by the same PRP.

If an IXP makes use of sector identifiers:

(a)            the pairwise identifiers MUST only have a one-to-one mapping with a sector identifier; and

(b)            a sector identifier MUST only map to a single PRP, regardless of the number of connected services.

Pairwise identifiers MUST be used when presenting individuals to PRPs irrespective of the federation protocols being brokered by the IXP in a transaction.

 

An authenticated session managed by the IXP MUST expire.

For each supported federation protocol, an IXP MUST provide PRPs with information regarding session expiration times.

An IXP MAY support features as specified in the relevant federation protocol to allow refreshing of an authenticated session before expiry.

 

An IXP MAY support a SSO scheme.

If an IXP supports SSO, it MUST support the ability for a PRP to request authentication for a particular individual, using all the methods outlined in the profile of their supported federation protocols.

An IXP MUST permit a PRP to request an individual’s reauthentication even when a pre-existing session is active and valid, regardless of the PRP that created the session.

An IXP MUST ensure their implementation of SSO does not result in the disclosure of attributes including restricted attributes of an individual.

 

If an IXP supports SSO, the IXP MUST implement SLO.

The IXP MUST ensure their implementation of SLO does not result in the disclosure of attributes including restricted attributes of an individual.

 

When an IXP receives an authentication request from a PRP that includes attributes supplied by an ASP, the IXP MUST facilitate gathering those attributes from the ASP.

 

 

An IXP MUST implement mechanisms to support the access channels it has agreed with an ASP as referenced in section 4.1.2 of this Schedule.

When accessing attributes directly from the ASP, an IXP MUST do so using the pairwise identifier it has issued to the ASP.

To facilitate direct communication between an ASP and a PRP, an IXP MAY share an individual’s encrypted pairwise identifier:

(a)            for the ASP with the PRP requesting authentication; and

(b)            for the PRP with the ASP that can fulfill the attribute requests.

If an IXP chooses to share an encrypted identifier, the identifier MUST be:

  1.             encrypted using a public key of the PRP or ASP it belongs to; and
  2.             be packaged with a timestamp and a nonce to limit the opportunity for replay and the creation of de facto pairwise identifiers.

 

When accepting authentication requests from a PRP, an IXP MUST broker the federation protocol used by the PRP to the federation protocol of the ISP selected by the individual.

 

An IXP MUST provide a mechanism for the individual to choose an ISP.

The list of ISPs presented by an IXP MUST only display ISPs that satisfy the IP level and AL requested in the PRP’s authentication request.

An IXP MAY provide a mechanism for the individual to remember their choice of ISP for a given PRP.

If an individual has remembered their ISP choice for a given PRP, an IXP MAY redirect them to the remembered ISP.

If an IXP provides a mechanism to remember ISP selection, the IXP MUST provide:

  1.             a notice to ensure the individual understands the nature of the express consent they are providing;
  2.             a notice outlining the duration of the remembered ISP selection and the limitations on how it is remembered (for example, if it is limited to the device or web browser from which the express consent is given); and
  3.             a mechanism to revoke the remembered choice.

 

An IXP MUST NOT broker any information about the PRP requesting authentication to any of its ISPs.

An IXP MAY inform the PRP which ISP the individual used to authenticate.

 

 

If an IXP informs the PRP which ISP the individual used to authenticate, the IXP MUST do so in accordance with the requirements outlined for the federation protocol used by the PRP.

 

An IXP MUST provide a user dashboard that allows an individual, for the digital ID used to create the individual’s current authenticated session, to:

  1.             view their consumer history;
  2.             manage the express consent they have given; and
  3.             manage their ISP preferences.

The user dashboard MUST only display information for services at or below the level of assurance for the current authenticated session.

When a user dashboard is accessed, an IXP MAY re-authenticate the individual, even if the individual already has a current authenticated session.

 

An IXP MUST support brokering all attributes as outlined in Schedule 3 (AGDIS Attribute Profile).

An IXP MUST support the disclosure of all IXP managed or generated attributes as outlined in Schedule 3 (AGDIS Attribute Profile).

An IXP MUST support requesting any ISP specific attributes outlined in Schedule 3 (AGDIS Attribute Profile) in an authentication request to an ISP.

 

For each of their supported federation protocols, an IXP MUST implement the following requirements in this section.

An IXP MUST support the disclosure of computed attributes as described in Schedule 3 (AGDIS Attribute Profile).

An IXP MAY source computed attributes from an ISP or an ASP.

An IXP MAY define support for additional computed attributes derived from attributes available from its ISPs and ASPs.

Any new computed attribute MUST NOT violate attribute sharing policies defined in Schedule 3 (AGDIS Attribute Profile).

 

The IXP MUST only disclose an attribute or attribute set with PRPs in accordance with that attribute or attribute set’s attribute sharing policy as defined in Schedule 3 (AGDIS Attribute Profile).

 

When disclosing IXP specific attributes, an IXP MUST use the data representation as prescribed in Schedule 3 (AGDIS Attribute Profile).

An IXP MAY use the data representation, defined in Schedule 3 (AGDIS Attribute Profile), to validate attribute payloads received from ISPs and ASPs.

An IXP MUST NOT alter payloads received from an ISP or ASP unless the relevant attribute sharing polices explicitly permit alteration to occur.

 

3.        Identity service provider

This Chapter outlines the requirements that MUST be met by ISPs.

 

An ISP MUST implement the ISP requirements in Schedule 2 (AGDIS OpenID Connect Profile).

 

An ISP MAY generate GPIs as prescribed in section 1.2.1 of this Schedule.

An ISP SHOULD generate pairwise identifiers as prescribed in section 1.2.2 of this Schedule.

An identifier linking a digital ID to an IXP MUST only be used to map that one-to-one relationship. The identifier MUST NOT be shared by the IXP with any other service connected to the ISP.

 

An ISP MAY support an SSO scheme operated by one or more of its connected IXPs.

Where an ISP chooses to support an IXP’s SSO scheme, the ISP MAY choose to re-authenticate an individual at their discretion when servicing a SSO request.

If an ISP is unable to fulfill a request of SSO then it MUST re-authenticate the user.

 

The ISP MUST support the SLO scheme operated by its connected IXPs.

The ISP MUST support the SLO scheme (of its connected IXPs) regardless of whether the ISP has supported the SSO.

 

An ISP MUST support the disclosure of attributes based on support and fulfilment requirements outlined in Schedule 3 (AGDIS Attribute Profile).

For each of their supported federation protocols, an ISP MUST implement the specific attribute profile and attribute mapping.

 

An ISP MUST support computed attributes as outlined in Schedule 3 (AGDIS Attribute Profile).

An ISP MAY define support for additional computed attributes. The new computed attribute MUST NOT violate attribute sharing policies defined in Schedule 3 (AGDIS Attribute Profile).

 

4.        Attribute service provider

This Chapter outlines the requirements that MUST be met by ASPs.

 

An ASP, in addition to these requirements, is subject to TRP requirements as outlined in section 1.7 of Schedule 2 (AGDIS OpenID Connect Profile).

An ASP, in addition to these requirements, MAY also have a role as a PRP in another context, and in that context is subject to PRP requirements.

The ASP MUST implement the technical relying party profile for one of the federation protocols supported by the IXP it is connecting to.

At the time this instrument was made, the only technical relying party profile for the AGDIS is in Schedule 2 (AGDIS OpenID Connect Profile).

 

An access channel is any mechanism that allows ASP managed attributes to be provided either:

(a)            directly to a PRP; or

(b)            to a PRP via an IXP.

Examples include, but are not limited to, the use of OpenID Connect Core 1.0 distributed claims issued by IXP, authorisation methods (within the meaning of RFC 6749), event streaming services or application programming interfaces.

An ASP MAY make multiple access channels available for IXPs or PRPs to access the attributes they control.

 

 

For each access channel that an ASP makes available, the ASP MUST:

  1.             provide documentation outlining the technical integration requirements for the IXP and/or the PRP, as the case may be;
  2.             outline the attribute lifecycle features supported by the channel and how the IXP and/or PRP, as the case may be, can use them;
  3.             document and demonstrate how an individual’s consent is collected and managed;
  4.             document and demonstrate how an individual can manage their consent; and
  5.             document how the audit logging will be undertaken.

 

An ASP’s audit log MUST include any individual’s consent managed by the ASP that enables the sharing of attributes with PRPs.

An ASP’s audit log MUST include the value of the RP Audit ID supplied by the IXP:

  1.             when binding a digital ID brokered by the IXP to any of the attributes managed by the ASP;
  2.             if the IXP directly retrieves the attributes; and
  3.             if the ASP provides attributes indirectly and the RP Audit ID is available.

 

An ASP MUST publish an attribute schema for any attributes it provides.

The attribute schema MAY support multiple data formats if required by the various access channels provided by the ASP to IXPs and PRPs to access the ASP’s attributes.

A published attribute schema MUST outline data types and constraints for the fields that comprise the attribute sets managed by the ASP.

The published attribute schema MUST support a data format compatible with the federation protocol the ASP uses to connect to the IXP.

An ASP MUST establish procedures to publish updates to their attribute schema in accordance with Schedule 3 (AGDIS Attribute Profile).

 

 

Branding shape for Australia's Digital ID System

 

 

 

Schedule 2 AGDIS Open ID Connect Profile

 

 

Contents

  1.          Identity exchange..................................................1
    1.      Authorisation grant types...................................................1
    2.      Client types..............................................................1
      1.     Full Client with User Delegation.............................................1
      2.     Native Client with User Delegation..........................................1
      3.     Direct Access Client......................................................2
    3.      Client Registration.........................................................3
    4.      Redirect URI.............................................................3
      1.     Native Client Applications.................................................3
    5.      Connection to the authorisation server.........................................4
      1.     Client keys.............................................................4
    6.      Grant types..............................................................5
    7.      Technical Relying Party Profile...............................................5
      1.     Requests to the Authorisation Endpoint......................................5
      2.     Requests to the Token Endpoint............................................7
      3.     Token response.........................................................9
        1.        ID Tokens............................................................9
      1.   . Request to the UserInfo Endpoint..........................................9
      2.   . Request Object........................................................9
      3.   . Discovery.............................................................9
    8.      Identity Exchange OpenID Connect provider Profile.............................10
      1.     Connecting to clients....................................................10
        1.        Grant types..........................................................10
        2.        Client authentication...................................................10
        3.        Dynamic registration...................................................11
        4.        Discovery...........................................................11
        5.        PKCE 14
      1.   . Response to Authorisation Requests......................................14
        1.        Authentication Error Response...........................................14
        2.        Responding to Invalid Claims............................................15
      2.   . Token Response......................................................15
        1.        ID Token............................................................15
      3.   . UserInfo Endpoint.....................................................16
  1.   . Request Objects.......................................................16
  2.   . Authentication Context..................................................16
  1.      Entity information........................................................16
    1.     Claims supported.......................................................16
    2.     Scope profiles..........................................................17
    3.     Valid ACR Claims.......................................................17
  2. User consent............................................................18
  3. Privacy considerations....................................................18
  4. Security considerations....................................................18
  1.          Identity service provider............................................19
    1.      Client types.............................................................19
      1.     Full Client with User Delegation............................................19
    2.      Client registration........................................................19
    3.      Redirect URI............................................................20
    4.      Client keys..............................................................20
    5.      Grant types.............................................................20
    6.      Technical Relying Party Profile..............................................20
      1.     Audit Logging..........................................................20
      2.     Request to the Authorisation Endpoint......................................21
      3.     Request to the Token Endpoint............................................22
      4.     Request to the UserInfo Endpoint..........................................24
      5.     ID Tokens.............................................................24
      6.     Request Objects........................................................24
      7.     Discovery.............................................................24
    7.      Identity Provider Profile....................................................24
      1.     Audit Logging..........................................................25
      2.     Connecting to clients....................................................25
        1.        Grant types..........................................................25
        2.        Client authentication...................................................25
        3.        Dynamic registration...................................................26
        4.        Discovery...........................................................26
      1.   . Requests to the Authorisation Endpoint (Authentication Request)................27
      2.   . User consent.........................................................27
      3.   . Response to Authorisation Requests......................................27
        1.        Authentication Error Response...........................................27
      4.   . Token Response......................................................28
  1.        ID Token............................................................28
  1.   . UserInfo Endpoint.....................................................29
  2.   . Request Object.......................................................29
  3.   . Authentication context..................................................30
  1.      Entity information........................................................30
    1.     Claims supported.......................................................30
    2.     Scope profiles..........................................................30
    3.     Valid ACR Claims.......................................................30
  2.      Privacy Requirements.....................................................31
  3. Security Considerations...................................................31
  1.          Protocol brokering................................................32
    1.      OIDC to OIDC brokering...................................................32
      1.     Mapping Claims and Scopes..............................................32
      2.     Handling of Subject ID...................................................32
      3.     Mapping assurance levels................................................32
      4.     Prompt Parameter......................................................33
      5.     ID Token Hint Parameter.................................................33
  2.          Attributes.......................................................34
    1.      Restricted attributes......................................................34
    2.      OIDC Attribute Mapping...................................................34

 

List of Tables

Table 1 IXP prompt parameter brokering requirements.............................33

 

 

 

List of Figures

Figure 1 JSON WEB Key Set example...........................................4

Figure 2 Example authorisation request..........................................7

Figure 3 Sample Token Endpoint HTTP POST request..............................8

Figure 4 Client authentication JWT example.....................................11

Figure 5 Normative example of the well-known configuration........................14

Figure 6 Requesting authentication assurance level with claims......................17

Figure 7 Token Endpoint private JWT example...................................22

Figure 8 UserInfo endpoint example request.....................................23

Figure 9 Sample ID Token signature............................................29

Figure 10 Claims used to the generate the prior signature...........................29

Figure 11 Sample assurance level requests using claims...........................31

 

 

1.        Identity exchange

This Chapter outlines the requirements that an IXP MUST satisfy to facilitate brokering access to ISPs using OpenID Connect Core 1.0 as their federation protocol.

Interoperability between IXPs is not within scope for this release of the Digital ID (AGDIS) Data Standards 2024.

 

An IXP MUST NOT use the resource owner password credentials grant type defined in RFC 6749.

 

An IXP MUST support the Full Client with User Delegation client type.

This client type applies to clients that act on behalf of a particular resource owner and require delegation of that user’s authority to access the protected resource. This client type can interact with a separate web browser application to facilitate the resource owner’s interaction with the authentication endpoint of the authorisation server.

All IXP clients of this type MUST use the authorisation code flow of RFC 6749 by sending the resource owner to the Authorisation Endpoint to obtain authorisation.

An IXP MUST ensure that the individual authenticates to the Authorisation Endpoint. The user’s web browser is then redirected back to a URI hosted by the client service, from which the client can obtain an authorisation code passed as a query parameter. The client then presents that authorisation code along with its own credentials (private_key_jwt) to the authorisation server’s Token Endpoint to obtain an access token.

An IXP MUST associate the clients with a unique public key as described in section 1.5.1 of this Schedule.

An IXP MAY issue this client type a refresh token if the security parameters of the access request allow for it.

 

A Native Client with User Delegations is a client that acts on behalf of a particular resource owner, such as an application on a mobile platform, and requires delegation of that individual’s authority to the protected resource. This client type can interact with a separate web browser application to facilitate the resource owner’s interaction with the authentication endpoint of the authorisation server. Specifically, this client type runs natively on the resource owner’s device, often leading to many identical instances of a piece of software operating in different environments and running simultaneously for different end users.

An IXP MAY support Native Clients with User Delegation.

 

 

If an IXP supports Native Clients with User Delegation, the IXP MUST implement the following requirements.

An IXP client MUST use the authorisation code flow of RFC 6749 by sending the resource owner to the Authorisation Endpoint to obtain authorisation.

An IXP MUST authenticate an individual to the Authorisation Endpoint.

The user’s web browser is then redirected back to a URI hosted by the client, from which the client can obtain an authorisation code passed as a query parameter. The client then presents that authorisation code along to the authorisation servers Token Endpoint to obtain an access token.

Native clients connecting to a IXP MUST either be:

  1.             dynamically registered to obtain a separate client identifier for each instance; or
  2.             act as Public Clients (as defined in section 2.1 (Client Types) of RFC 6749) by using a common client identifier and using PKCE (as per RFC 7636) to protect calls to the Token Endpoint.

An IXP supporting dynamic registration of native applications MUST support one of the following methods to register or exchange a unique public key value:

  1.             the native application generates unique public and private keys on the device and registers the public key value with the IXP; or
  2.             the IXP generates a unique public and private key pair, registering the public key with itself and securely transmitting the public and private key pair to the client. After transmission, the IXP MUST discard the private key.

An IXP MUST NOT permit sharing of client credentials among instances of client software.

All native applications registered with a IXP not registering a separate public key for each instance are considered Public Clients and MUST use PKCE with the S256 code challenge method (within the meaning of RFC 7636).

An IXP MUST NOT permit Public Clients to authenticate to the Token Endpoint in any other way.

If an IXP supports Native Clients with User Delegation, the IXP MAY implement the following requirements.

An IXP MAY permit dynamically registered native applications to use PKCE.

An IXP MAY issue a refresh token to a Native Client with User Delegation if the IXP is satisfied that there are no security issues.

 

A Direct Access Client is a client that connects directly to protected resources and do not act on behalf of a particular resource owner, for example, machine to machine access.

An IXP MAY only implement this client type to support interactions between itself and other entities participating in the AGDIS.

If an IXP supports the Direct Access Client type, the IXP MUST support the confidential client type and the client_credentials grant types.

 

An IXP MUST support Client Registration by static configuration or dynamic configuration. An IXP MAY support both static and dynamic Client Registration.

All clients of an IXP MUST register with the authorisation server.

For client software that may be installed on multiple client instances, an IXP MUST issue each client instance a unique client identifier from the authorisation server.

An IXP MUST advise a PRP of the information that is required to be supplied when configuring its connection as a TRP of the IXP.

Where a TRP is seeking to register by dynamic configuration, an IXP MUST require the TRP provide an initial access token (as defined in RFC 7591).

If an IXP supports dynamic registration of clients, the IXP MUST implement support for bearer tokens in the manner prescribed in RFC 6750.

 

An IXP’s clients that use the authorisation code grant type MUST register its full redirect URIs.

An IXP MUST as the authorisation server validate the redirect URI given by the client at the Authorisation Endpoint using strict string comparison.

An IXP MUST ensure that the redirect URI used by a client is one of the following:

  1.             hosted on a website with TLS protection (HTTPS);
  2.             hosted on a local domain of the client (for example: http://localhost/); or
  3.             hosted on a client specific non-remote protocol URI scheme (for example: myapp:// or au.gov.app://).

If a client’s redirect URI is either hosted on the local domain of the client or hosted on a client specific non-remote protocol URI schema, then a IXP MAY require that the TRP uses the PKCE extension to the authorisation code flow.

An IXP MUST NOT allow its ASPs to have URIs in more than one of the 3 categories outlined above. An IXP SHOULD NOT allow ASP clients to have multiple redirects URIs on different domains.

The use of client specific non-remote protocol URI schemes SHOULD be phased out for native application.

An IXP MAY allow existing native application clients to continue using non-remote protocol URI schemes in their redirect URI.

When a new Native Client Application is running on a platform that supports Claimed HTTPs Scheme URI redirection, an IXP SHOULD require these native applications to use that scheme in their redirect URI.

 

An IXP MUST require clients using the authorisation code grant type to have a public and private key pair type for use in authentication to the Token Endpoint.

An IXP MUST require each client to register its public keys in its client registration metadata by either sending the public key directly in the jwks field or by registering a jwks_uri.

If a client registers a jwks_uri, the IXP MUST require the URI to be reachable by the authorisation server.

An IXP SHOULD require the use of a jwks_uri as it allows for easier key rotation.

An IXP MUST reject a jwks field or the content available from a jwks_uri provided by the client if the content does not contain a public key in the format prescribed in RFC 7517.

As the authorisation server, a IXP MUST verify the content available from a client’s registered

jwks_uri contains a valid JSON Web Key Set. The example below is of a 2048-bit RSA key.

{

 "keys": [{
  "alg": "RS256",

  "e": "AQAB",

  "n": "kAMYD62n_f2rUcR4awJX4uccDt0zcXRssq_mDch5aifcShx9aTtTVza23PTn3KaKrsBXwWcfioXR6zQn5eYdZQVGNBfOR4rxF5i7t3hfb4WkS50EK1gBYk2lO9NSrQzxG9QsUsAnN6RHksXqsdOqvnxjLexDfIJlgbcCN9h6TBC66ZXv7PVhl19gIYVifSU7liHkLe0l0fw7jUI6rHLHf4d96_neR1HrNIK_xssr99Xpv1EM_ubxpktX0T925qej9fMEpzzQ5HLmcNt1H2_VQ_Ww1JOLn9vRnH48FDj7TxlIT74XdTZgTv31w_GRPAOfyxEw_ZUmxhz5ZngTlQ",

  "kty": "RSA",

  "kid": "oauth-client"

 }]

}

Figure 1 JSON WEB Key Set example

An IXP MAY allow native client applications to omit their key during registration if they are a Public Client using PKCE.

 

The grant type of authorisation_code MUST be supported by an IXP.

The Authorisation Code authentication flow implemented by an IXP MUST follow the steps outlined in the section 3.1 (Authentication using the Authorization Code Flow) of OpenID Connect Core 1.0.

If an IXP supports a Direct Access Client type, it MUST also support the grant type of

client_credentials.

Implementation of the Client Credentials grant MUST conform to RFC 6749.

 

In this section the terms client and technical relying party (TRP) refer to the OpenID Connect Core 1.0 software operated by a PRP or an ASP.

 

IXP’s clients making a request to the Authorisation Endpoint SHOULD use an unpredictable value for the state parameter with at least 128 bits of entropy.

IXP’s clients MUST validate the value of the state parameter upon return to the redirect URI and MUST ensure that the state value is securely tied to the individual’s current session, for example, by relating the state value to a session identifier issued by the client software to the browser.

IXP’s clients MUST include their full redirect URI in the authorisation request.

To prevent open redirection and other injection attacks, an IXP MUST match the entire redirect URI using a direct string comparison against registered values and MUST reject requests with invalid or missing redirect URIs.

The Authentication Request MUST contain the following REQUIRED parameters and MAY contain the following OPTIONAL parameter values:

 

 

 

 

 

A sample HTTP GET request may look like the following example:

https://idexchange.gov.au/oidc/authorization?response_type=code &client_id=827937609728-m2mvqffo9bsefh4di90saus4n0diar2h &scope=profile%20openid%20email &redirect_uri=https%3A%2F%2Frp.agency.gov.au%2Foidc%2FloginResponse &state=2ca3359dfbfd0 &prompt=select_account &acr_values=urn%3Aid.gov.au%3Atdif%3Aacr%3Aip3%3Acl2

Figure 2 Example authorisation request

 

Requests to the Token Endpoint uses client authentication. The client authentication mechanism is signed JWT as defined in section 1.8.1.2 of this Schedule.

The JWT assertion used in the client authentication MUST be signed by the client using the client’s public key it has registered with the Authorisation server. Registration of keys should occur in accordance with process outlined section 1.5.1 of this Schedule.

 

 

For clients that are required to use PKCE as described in section 1.2.2 and section 1.4 of this Schedule, the following claims MUST be included in the request to the Token Endpoint.

A TRP MUST include the following claims in the request to the Token Endpoint, when requesting authentication for an individual:

1.7.3.1 of this Schedule. The Client MUST generate a new assertion JWT for each call to the Token Endpoint.

These would be sent to the Token Endpoint as illustrated in the HTTP POST example below.

POST /token HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host: idexchange.gov.au grant_type=authorization_code &code=sedaFh &scope=openid+email+profile &redirect_uri=https%3A%2F%2Frp.agency.gov.au%2Foidc%2FloginResponse &client_id=55f9f559-2496-49d4-b6c3-351a586b7484 &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclientassertion- type%3Ajwt-bearer &client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.ew0KICAgImlzcy I6ICI1NWY5ZjU1OS0yNDk2LTQ5ZDQtYjZjMy0zNTFhNTg2Yjc0ODQiLA0KICAgInN1YiI 6ICI1NWY5ZjU1OS0yNDk2LTQ5ZDQtYjZjMy0zNTFhNTg2Yjc0ODQiLA0KICAgImF1ZCI6

ICJodHRwczovL2lkcC1wLmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgICJpYXQiOiAxNDE4N jk4Nzg4LA0KICAgImV4cCI6IDE0MTg2OTg4NDgsDQogICAianRpIjogIjE0MTg2OTg3OD gvMTA3YzRkYTUxOTRkZjQ2M2U1MmI1Njg2NWM1YWYzNGU1NTk1Ig0KfQ.t_gX8JQGq3G2

OEc2kUCQ8zVj7pqff87Sua5nktLIHj28l5onO5VpsL4sRHIGOvrpo7XO6jgtPWy3iLXv3 NLyo1TWHbtErQEGpmf7nKiNxVCXlGYJXSDJB6shP3OfvdUc24urPJNUGBEDptIgT7Lhf6 BbwQNlMQubNeOPRFDqQoLWqe7UxuI06dKX3SEQRMqcxYSIAfP7CQZ4WLuKXb6oEbaqz6g L4l6p83G7wKGDeLETOTHsztjKR38v4F_MnSrx8e0iIqgZwurW0RtetEWvynOCJXkp166T 7qZR45xuCxgOotXY6O3et4n77GtgspMgOEKj3b_WpCiuNEwQ

Figure 3 Sample Token Endpoint HTTP POST request

 

The token response includes an access token, which can be used to make a UserInfo request as per section 1.7.4 of this Schedule, and an ID token as per section 3.1.3.3 (Successful Token Response) of OpenID Connect Core 1.0. It MAY also include a Refresh token.

 

All clients MUST validate the signature of an ID Token before accepting it using the public key of the issuing server, published in JWK format.

An IXP MAY encrypt ID Tokens using the appropriate key of the requesting client. An IXP’s TRPs MUST verify the following in received ID tokens:

         iss

 

         aud


 

 

An IXP MUST be able to accept UserInfo Request from clients using either the HTTP GET or POST methods.

An IXP MUST only accept Access Tokens from its clients when presented as Bearer Tokens, as outlined in the RFC 6750.

 

A client MAY send request to the authorisation end point using the request parameters as outlined in OpenID Connect Core 1.0.

Request objects MUST be signed by the client’s public key.

A client MAY encrypt the request object with the authorisation server’s public key.

 

Clients and protected resources MAY cache an IXP’s OpenID Connect metadata once the IXP has been discovered, as outlined in this Schedule.

 

 

1.8.1.1                  Grant types

The authorization_code grant type is the only grant type that is supported under this Schedule. Accordingly, an IXP MUST only support the authorization_code grant type when fulfilling PRP authentication requests for individuals.

The authorisation code flow returns an authorisation code to the client. The client can then exchange this one-time code for an ID Token and an Access Token. This provides the benefit of not exposing any tokens to the User Agent and potentially malicious applications with access to the User Agent.

 

An authorisation server MUST enforce client authentication for access to the authorisation server’s Token Endpoint.

An authorisation server MUST only authenticate clients using the private_key_jwt method as prescribed in the OpenID Connect Core 1.0.

An authorisation server MUST NOT authenticate clients using any other method.

The JWT used to authenticate the client MUST expire with a lifetime no longer than 300 seconds. An authorisation server MUST reject an JWT with an expiry time passed.

An authorisation server SHOULD:

  1.             allow for clock skew of 300 seconds between systems when assessing the expiry of a JWT; and
  2.             reject any JWT with expiry that is unreasonably far into the future.

The JWT MUST contain the following REQUIRED claims and MAY contain the following OPTIONAL claims:

 

 

 

 

 

 

 


 

 

 

 

 

 

 

 

 


128 bits of entropy and MUST NOT be re-used by any subsequent authentication token.

 

 

The following is an example of the use of the REQUIRED claims for a client authentication JWT as defined in this Schedule. Noting that additional claims MAY be included in this set.

{

"iss": "55f9f559-2496-49d4-b6c3-351a586b7484",

"sub": "55f9f559-2496-49d4-b6c3-351a586b7484",

"aud": "https://idexchange.gov.au/token",

"iat": 1418698788,

"exp": 1418698848,

"jti": "1418698788/107c4da5194df463e52b56865c5af34e5595"

}

Figure 4 Client authentication JWT example

 

An IXP MAY support the dynamic registration of clients.

 

Endpoints and parameters specified in the discovery document below MAY be considered public information regardless of the existence of the discovery document.

An IXP MUST provide a well-known endpoint for its configuration as described in the OpenID Connect Discovery 1.0.

An IXP MUST secure the well-known endpoint as outlined in OpenID Connect Discovery 1.0. An IXP MAY apply additional security controls if required by their business need.

The discovery document published by a IXP MUST as a minimum contain the following fields:

         issuer

o        REQUIRED. The fully qualified issuer URL of the server.

         authorization_endpoint

o        REQUIRED. The fully qualified URL of the server’s Authorisation Endpoint defined in RFC 6749.

 

 

 

         token_endpoint

o        REQUIRED. The fully qualified URL of the server’s Token Endpoint defined in RFC 6749.

         introspection_endpoint

o        OPTIONAL. The fully qualified URL of the server’s introspection endpoint defined in RFC 7662.

         revocation_endpoint

o        OPTIONAL. The fully qualified URL of the server’s revocation endpoint as within the meaning of RFC 7009.

         jwks_uri

o        REQUIRED. The fully qualified URI of the server’s public key in JWK Set format as defined in RFC 7517.

         scopes_supported

o        REQUIRED. The list of scopes that MUST be made available by a IXP as defined in Schedule 3 (AGDIS Attribute Profile).

         claims_supported

o        REQUIRED. The list of claims that MUST be made available by an IXP as defined in Schedule 3 (AGDIS Attribute Profile).

The following is sample of the current AGDIS IXP’s well-known endpoint response.

 

{

    "issuer": "https://auth.identity.gov.au",

    "authorization_endpoint": "https://auth.identity.gov.au/authorise",

    "token_endpoint":

        "https://auth.identity.gov.au/sso/sps/oauth/oauth20/token",

    "userinfo_endpoint":
  "https://auth.identity.gov.au/sso/sps/oauth/oauth20/userinfo",

    "jwks_uri":

  "https://auth.identity.gov.au/.well-known/jwks.json",

    "end_session_endpoint": "https://auth.identity.gov.au/logout",

    "response_types_supported": [

        "code"

    ],

    "grant_types_supported": [

        "authorization_code"

    ],

    "subject_types_supported": [

        "pairwise"

 

],

    "id_token_signing_alg_values_supported": [

        "RS256"

    ],

    "scopes_supported": [

        "openid",

        "profile",

        "email",

        "phone",

        "tdif_business_authorisations",

        "tdif_doc",

        "tdif_other_names"

    ],

    "claims_supported": [

        "tdif_business_authorisations",

        "tdif_doc",

        "acr"

    ],

    "user_flows_supported": [

        "sign_in",

        "sign_up",

        "mygov_link"

    ],

    "prompts_supported": [

        "none",

        "login"

    ],

    "acr_values_supported": [

        "urn:id.gov.au:tdif:acr:ip1:cl1",

        "urn:id.gov.au:tdif:acr:ip1:cl2",

 

 

"urn:id.gov.au:tdif:acr:ip2:cl2",

        "urn:id.gov.au:tdif:acr:ip3:cl2"

    ],

    "frontchannel_logout_supported": true,

    "frontchannel_logout_session_supported": false

}

Figure 5 Normative example of the well-known configuration

 

An authorisation server MUST support the PKCE extension to the authorisation code flow, including support for the S256 code exchange methods (within the meaning of RFC 7636).

The authorisation server MUST NOT allow a client to use the plain code challenge method (within the meaning of RFC 7636).

 

The authorisation code flow’s authorisation response MUST return the following fields in the response:

PKCE parameters MUST be associated with the code (refer above) within the meaning of RFC 7636.

This response MUST be sent to the client via a HTTP redirect to the URI specified in the request.

 

The Authentication Error Response is the message returned from an IXP’s Authorisation Endpoint in response to the Authorisation Request sent by the client.

If the End-User denies or cancels the request or the End-User authentication fails, the OIDC provider informs the TRP by using the error responses defined in either section 4.1.2.1 (Error Response) of RFC 6749 or the error codes defined in section 3.1.2.6 (Authentication Error Response) of the OpenID Connect Core 1.0. The additional authentication error responses defined in this Schedule are:

         authentication_cancelled

o        The End-User did not proceed with the authentication interaction.

 

A scope or claim is invalid if a IXP cannot source the underlying attributes from its ISPs or ASPs and from the IXP specific attributes outlined in Chapter 4 of Schedule 3 (AGDIS Attribute Profile).

If an IXP receives a request for a scope or claim it cannot fulfill, the IXP MUST ignore these scopes or claims.

An IXP MUST deny an authentication request with the access_denied error code (as described in RFC 6749) if its client requests a scope or claim that under the relevant attribute sharing policy it is not authorised to request. For example, if a client requests a restricted attribute set when they are not approved to an access_denied error code MUST be returned.

 

All tokens issued by an IXP MUST be signed with the IXP’s private key.

For clients using the Authorisation Code Grant type, access tokens MUST have a valid lifetime of no greater than one hour (which is 3,600 seconds).

If an IXP issues refresh token they MUST have a lifespan of no longer than 24 hours (which is 86,400 seconds).

Token lifespans MAY be shorter than these prescribed values to meet the requirements of an IXP’s security risk assessment.

 

An IXP MAY encrypt an ID Token or the ID Token’s fields with the requesting clients public key when the ID Token contains attributes of the individual.

An IXP issued ID Token MUST:

  1.             expire; and
  2.             have a lifespan of no longer than 300 seconds.

An IXP SHOULD assign lifespans of shorter than 300 seconds to an ID Token.

An IXP issued ID Token MUST contain the following fields that are defined as REQUIRED. An IXP issued ID Token MAY include the following fields that are defined as OPTIONAL. ID token fields:

 

 

 

 


 

 

 

 

 

 

An IXP MUST support returning claims via the UserInfo endpoint as prescribed by the requirements outlined in section 4.1.1 of Schedule 3 (AGDIS Attribute Profile).

When processing a UserInfo request, a IXP MUST only return the claims that are authorised within the authentication request associated with the presented access token.

An IXP MUST NOT return empty or null values for claims that cannot be fulfilled unless Chapter 2 and Chapter 3 of Schedule 3 (AGDIS Attribute Profile) specifically permits these values for a given attribute set.

The sub claim MUST always be present in the UserInfo response.

 

An IXP operating as OpenID Connect provider MUST accept requests containing a request object signed by the client’s private key.

An IXP MUST validate the signature on request objects using the client’s public key.

An IXP MUST implement support for receiving requests objects encrypted with one of its public keys.

 

An IXP MUST provide an ACR in line with the claims outlined in section 4.4.1.3 of Schedule 3 (AGDIS Attribute Profile).

An IXP MUST return the acr attained by the individual during authentication at the ISP even if the acr was not marked as essential, the acr_values parameter was used, or no acr value was supplied in the TRP’s authentication request.

 

An authorisation server MUST return claims on best effort basis. An IXP asserting it can support specific claims does not guarantee it is available for all individuals.

 

 

An IXP MUST only return claims in accordance with data sharing requirements and data formats outlined in Chapter 4 of Schedule 3 (AGDIS Attribute Profile).

 

An authorisation server MUST fulfill scopes on best effort basis.

An IXP MUST only return scopes in accordance with the data sharing policies and data formats outlined in Chapter 4 of Schedule 3 (AGDIS Attribute Profile).

 

Assurance levels are outlined in section 2.1.3 of Schedule 1 (AGDIS Onboarding Specifications).

An IXP MUST implement support to allow its PRPs to use either the acr_values or acr claim to request their required ACR.

An IXP MUST reject any request that include both the acr_values and acr claims.

When the acr claim is requested an IXP MUST support the acr claim being optionally marked as essential claim by the client. For example:

“claims”: {

    “id_token”: {

         “acr”: {

             “essential”: true,

             “values”: [“urn:id.gov.au:tdif:acr:ip2:cl3”]

         }

}

}

Figure 6 Requesting authentication assurance level with claims

When the acr values are marked as an essential claim, the IXP MUST return a value that matches the requested values.

If the individual is unable to achieve the required level of assurance outlined in the request and the acr

claim is marked as essential, then an IXP MUST respond with an authentication error.

If the acr claim is not marked as essential or no acr value was supplied in the authentication request, then an IXP MUST respond with the level of assurance the individual was able to achieve.

 

Given IXPs operate as central trusted entity in the AGDIS, IXPs MUST collect consent of the individual to whom the digital ID relates before redirecting the individual to the client that originated the authentication request.

 

An IXP MUST adhere to all the attribute sharing policies set out in Chapter 2 and Chapter 3 of Schedule 3 (AGDIS Attribute Profile).

 

All clients of an IXP SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.

 

2.        Identity service provider

This Chapter outlines the requirements for:

  1.             IXPs in their role as a TRP to ISPs; and
  2.             ISPs in their roles as OIDC providers to IXPs.

 

The resource owner password credential grant type as defined in RFC 6749 MUST NOT be used under this Schedule.

Given an IXP is only acting as a proxy, the Full Client with delegation is the only client available.

 

This client type applies to clients that act on behalf of a particular resource owner and require delegation of that user’s authority to access the protected resource. This client type can interact with a separate web browser application to facilitate the resource owner’s interaction with the authentication endpoint of the authorisation server.

An ISP MUST only support clients of this type.

All clients of an ISP MUST use the authorisation code flow of RFC 6749 by sending the resource owner to the Authorisation Endpoint to obtain authorisation.

An ISP MUST ensure that the user authenticates to the Authorisation Endpoint.

The user’s web browser is then redirected back to a URI hosted by the client service, from which the client can obtain an authorisation code passed as a query parameter. The client then presents that authorisation code along with its own credentials (private_key_jwt) to the authorisation server’s Token Endpoint to obtain an access token.

An ISP MUST associate the clients with a unique public key as described in section 2.4 of this Schedule.

If an ISP issues a refresh token to this type of client, they MUST only do so if the security parameters of the request permit its issuance.

 

An IXP MUST register with the authorisation server.

Each client IXP MUST receive a unique client identifier from the authorisation server. Clients of the authorisation server MUST be statically configured.

An ISP MUST NOT support the dynamic registration of IXPs.

 

An ISP MUST register an IXP’s full redirect URIs as required by the authorization_code grant type.

The authorisation server MUST validate the redirect URI passed to the authorisation end using strict string comparison.

An ISP MUST only permit TLS protected redirect URIs to be registered.

An ISP MUST NOT permit a IXP to have multiple redirect URIs on different domains.

An ISP MUST NOT forward values passed back to their redirect URIs to other arbitrary or user provided URIs.

An ISP MUST NOT permit open redirection.

 

All connected IXPs acting as clients MUST have a public and private key that MUST be used when authenticating to the Token Endpoint.

As clients all IXPs MUST:

  1.             provide their public keys in their client registration metadata; or
  2.             provide an avenue for entities to obtain or reference their public keys. An ISP SHOULD support the use of jwks field, or registration of a jwks_uri.

If a IXP uses a jwks_uri to register its public key, the URI MUST be reachable by the authorisation server.

If an ISP supports the use of jwks_uri:

  1.             the IXP SHOULD use a jwks_uri to simplify key rotation; and
  2.             the ISP MUST validate the content of the clients registered jwks_uri document.

 

An ISP MUST only support the authorization_code grant type when providing services to IXPs.

 

This section outlines the profile that an ISP MUST provide for the IXPs that are its TRPs.

 

An IXP MUST log all interactions with its ISPs using a unique audit identifier it has generated for an authentication request from its TRP.

To enable a traceable audit trail for requests sent to an ISP, an IXP MUST implement a scheme to ensure that each request is uniquely identifiable at the ISP.

 

 

A recommended scheme is for an IXPs to transport a unique generated value using the state

parameter. Note this unique value MUST NOT be the RP audit ID issued by an IXP to an PRP.

 

An IXP making a request to the Authorisation Endpoint MUST use an unpredictable value for the

state parameter with at least 128 bits of entropy.

An IXP MUST validate the state parameter upon return to the redirect URI.

An IXP MUST ensure that the state value is securely tied to the user’s current IXP session. An IXP MUST include their redirect URIs in the authorisation request.

An ISP MUST match the entire redirect URI using strict string comparison against registered values and reject request with missing or invalid redirect URIs.

The authentication request MUST contain the following REQUIRED parameters and MAY contain the following OPTIONAL parameters.

 

 

The values of the claims, scope and acr_values parameters are mapped from the original authentication request to the IXP from one of its TRPs. Additional OpenID Connect Core 1.0 parameters MAY also be mapped from the original request to the IXP that triggered the request from the IXP to the ISP. Mapping of these parameters are described Chapter4 of this Schedule.

 

Request to the Token Endpoint require client authentication. The client authentication mechanism is a signed JWT and defined in the Identity Provider profile outlined in section 2.7 of this Schedule.

The claims that are included in the JWT are summarised below:

 

 

 

 

 


 

 

 

 

 

An IXP making the request MAY include additional claims in this set.

The following is an example of the required claims for a client authentication JWT as defined in this profile.

{
   "iss": "8428fea9-2815-82e9-a9f3-a32a9e9b723c",
   "sub": "8428fea9-2815-82e9-a9f3-a32a9e9b723c ",
   "aud": "https://idp.gov.au/token",
   "iat": 1516986988,
   "exp": 1516986929,
   "jti": "1516986988/c4da1075193e524df46b5e565c5a59568f34"
}

Figure 7 Token Endpoint private JWT example

 

 

The JWT assertion MUST be signed with the IXP’s private key from the key pair they have registered with the ISP.

The following claims MUST be included in a request to a Token Endpoint:

The following is an example of how these claims would be sent Token Endpoint:

POST /token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Host: idp.gov.au

grant_type=authorization_code
&code=sedaFh
&redirect_uri=https%3A%2F%2Fidexchange.gov.au%2Foidc%2FloginResponse
&client_id=55f9f559-2496-49d4-b6c3-351a586b7484
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.ew0KICAgImlzcyI6ICI1NWY5ZjU1OS0yNDk2LTQ5ZDQtYjZjMy0zNTFhNTg2Yjc0ODQiLA0KICAgInN1YiI6ICI1NWY5ZjU1OS0yNDk2LTQ5ZDQtYjZjMy0zNTFhNTg2Yjc0ODQiLA0KICAgImF1ZCI6ICJodHRwczovL2lkcC1wLmV4YW1wbGUuY29tL3Rva2VuIiwNCiAgICJpYXQiOiAxNDE4Njk4Nzg4LA0KICAgImV4cCI6IDE0MTg2OTg4NDgsDQogICAianRpIjogIjE0MTg2OTg3ODgvMTA3YzRkYTUxOTRkZjQ2M2U1MmI1Njg2NWM1YWYzNGU1NTk1Ig0KfQ.t_gX8JQGq3G2OEc2kUCQ8zVj7pqff87Sua5nktLIHj28l5onO5VpsL4sRHIGOvrpo7XO6jgtPWy3iLXv3-NLyo1TWHbtErQEGpmf7nKiNxVCXlGYJXSDJB6shP3OfvdUc24urPJNUGBEDptIgT7Lhf6BbwQNlMQubNeOPRFDqQoLWqe7UxuI06dKX3SEQRMqcxYSIAfP7CQZ4WLuKXb6oEbaqz6gL4l6p83G7wKGDeLETOTHsztZjKR38v4F_MnSrx8e0iIqgZwurW0RtetEWvynOCJXk-p166T7qZR45xuCxgOotXY6O3et4n77GtgspMgOEKj3b_WpCiuNEwQ

Figure 8 UserInfo endpoint example request

 

An ISP MUST implement support for an IXP to send a UserInfo request using either the HTTP GET or POST methods.

The Access Token obtained from authentication request MUST be sent as a Bearer Token, as described in RFC 6750.

 

An IXP MUST validate the signature of an ID Token before accepting it by using the public key of the ISP that issued it.

An IXP MAY require an ISP to encrypt the ID Tokens it returns.

If an ISP supports encrypting ID Tokens, it MUST use the appropriate key of the requesting IXP. An IXP MUST verify the following in received ID Tokens:

 

An IXP MAY optionally send requests to the Authorisation Endpoint using the request parameter as defined in the OpenID Connect Core 1.0.

An IXP MUST sign the request object with its registered key.

An IXP MAY encrypt the request object using the ISP’s public key.

 

An IXP MAY cache the ISP’s OIDC provider metadata once the ISP has been discovered and used by that IXP.

 

An ISP providing authentication services to an IXP using OpenID Connect Core 1.0 MUST implement this Schedule.

 

An ISP MUST log all authentication requests and responses, including the values of the client_id

and the state parameters associated with the request.

 

 

2.7.2.1                  Grant types

The only supported grant type is authorization_code.