© 2026 Zoe. All rights reserved.
Zoe is a legal information platform. Always consult the Federal Register of Legislation for authoritative text.
Commonwealth legislation
**What this instrument does (mechanics)
Establishes technical and data rules for participants in the Australian Government Digital ID system (AGDIS). It is a standards instrument that tells three types of participants what they must implement and how data must be represented and shared: Identity Exchange Providers (IXPs), Identity Service Providers (ISPs), and Attribute Service Providers (ASPs).
Requires OpenID Connect Core 1.0 as the supported federation protocol and prescribes a bespoke AGDIS profile of that protocol (Schedule 2). Key protocol rules include: use of the authorization_code grant (PKCE where appropriate), client registration and key management (jwks/jwks_uri), client authentication to token endpoints via private_key_jwt, strict redirect-URI validation, token lifetimes (ID tokens ≤ 300 seconds; access tokens ≤ 3,600 seconds; refresh tokens ≤ 86,400 seconds) and rejection of the resource-owner-password grant (see sections 1.6, 1.8.3 and 1.8.1.2). (See: Protocol requirements and Token/ID token rules, e.g. §1.7–1.8.)
Specifies how identities and identifiers must be generated and used. ISPs may issue a General Purpose Identifier (GPI) but only under narrow rules (one GPI per account per IXP, only inside AGDIS); IXPs must issue pairwise identifiers and pairwise identifiers must be generated per the OpenID Connect pairwise algorithm. Sector identifiers are recommended where used. (See: Identity resolution §1.2 and §§2.1.4 / 3.1.2.)
Sets mandatory data-sharing and attribute policies (Schedule 3). Every attribute or attribute set transmitted across AGDIS must have an attribute-sharing policy that defines consent type, fulfilment rules (best effort vs required), access control (Open / Not available / Restricted / Platform), and data representation. Entities must follow those policies when brokering or fulfilling requests. (See: Attribute sharing policy, §1.2 of Schedule 3.)
Want the full deep dive?
Zoe can write the in-depth analysis on top of the summary above: how it works, who it affects and what each part actually does.
Direct links to the current provisions in Digital ID (AGDIS) Data Standards 2024.
This Chapter outlines the role requirements, where applicable, that MUST be met by ASPs, ISPs and IXPs.
ASPs, ISPs and IXPs:
MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and
SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.
This Chapter outlines the role requirements, where applicable, that MUST be met by ASPs, ISPs and IXPs.
ASPs, ISPs and IXPs:
MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and
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.
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.
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).
This Chapter outlines the requirements that MUST be met by IXPs.
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.
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.
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.
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:
a notice to ensure the individual understands the nature of the express consent they are providing;
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
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.
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:
view their consumer history;
manage the express consent they have given; and
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.
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:
view their consumer history;
manage the express consent they have given; and
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).
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.
This Chapter outlines the requirements that MUST be met by ISPs.
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.
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 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).
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.
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).
This Chapter outlines the requirements that MUST be met by ASPs.
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).
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.
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.
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:
when binding a digital ID brokered by the IXP to any of the attributes managed by the ASP;
if the IXP directly retrieves the attributes; and
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).
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
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 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.
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’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:
hosted on a website with TLS protection (HTTPS);
hosted on a local domain of the client (for example: [http://localhost/](http://localhost/)); or
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.
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:
client\_id
REQUIRED. Client Identifier (within the meaning of RFC 6749) valid at the authorisation server.
response\_type
REQUIRED. Must be set to code.
scope
REQUIRED. Indicates the attributes being requested. The openid scope MUST always be present. Additional scopes are defined in Schedule 3 (AGDIS Attribute Profile).
redirect\_uri
REQUIRED. Indicates a valid endpoint where the client will receive the authentication response. The URI MUST match exactly one of the Redirection URIs preregistered at the IXP. The URI MUST follow the schemes outlined in section 1.4 of this Schedule.
state
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.
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
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:
allow for clock skew of 300 seconds between systems when assessing the expiry of a JWT; and
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:
iss
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:
allow for clock skew of 300 seconds between systems when assessing the expiry of a JWT; and
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:
iss
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.
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:
state
The value of the state parameter passed in via the authentication request. This value MUST match exactly.
code
The authorisation code, a random string issued by the OIDC provider to be used request to the Token Endpoint.
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:
expire; and
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:
iss
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.
nonce
If a nonce value was supplied with the authentication request, then this value is REQUIRED.
jti
REQUIRED. A unique identifier for the token which can be used to prevent the reuse of the token.
exp, iat, nbf
REQUIRED. The expiration, issued at, and not before timestamps for the tokens. They are dates presented as an integer representing the number of seconds since 1970- 01-01T00:00:00Z UTC (Unix epoch) within acceptable ranges.
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 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 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.
This Chapter outlines the requirements for:
IXPs in their role as a TRP to ISPs; and
ISPs in their roles as OIDC providers to IXPs.
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 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.
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.
client\_id
REQUIRED. Client Identifier (within the meaning of RFC 6749) assigned to a IXP by the ISP.
response\_type
REQUIRED. MUST be set to code.
scope
REQUIRED. Indicates the attributes being requested. The openid scope MUST always be present.
redirect\_uri
REQUIRED. Indicates the valid endpoint where the client will receive the authorisation response. The URI MUST exactly match one of preregistered redirect URIs at the ISP.
state
REQUIRED. An opaque value generated by the IXP used to protect against CSRF attacks. The value MUST contain sufficient entropy to avoid guessing and is returned to the IXP in the authentication response.
An IXP SHOULD use a unique value for each authorisation request.
nonce
REQURIED. Un-guessable random string generated by the client, used to protect against cross site request forgery attacks. The string MUST contain sufficient entropy to avoid guessing. The value is returned to the IXP in the ID Token.
acr\_values
OPTIONAL. If the originating PRP requesting authentication has supplied acr\_values a IXP MUST pass these values in accordance with protocol brokering requirements outlined in section 2.8.3 of this Schedule.
user\_flow
OPTIONAL. A string value that indicates the desired user flow for the user. Defined values are:
sign\_in: An Exchange requests this when a TRP expects the user to already have a digital ID and sign in at the ISP.
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:
iss
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:
iss
The issue field is the URL of the expected issuer.
aud
The audience field contains the client ID of the IXP.
nonce
String value used to associate the client session with the ID Token.
exp, iat, nbf
The expiration, issued at and not before tokens are dates (integer number of seconds since 00:00:00Z 1st January 1970, i.e. Unix epoch) are within acceptable ranges.
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.
The authorisation code flow is the only authentication flow support under this Schedule. The authorisation code flow returns an Authorisation Code to the client that the client can then exchange 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.
The ISP MUST validate all redirect URIs for the authorization_code grant type.
An ISP MUST enforce client authentication for access to the authorisation server’s Token Endpoint.
An ISP MUST only authenticate clients using the private_jwt_key method as prescribed in the OpenID Connect Core 1.0.
An ISP’s authorisation server MUST NOT authenticate clients using any other method.
The JWT used to authenticate the client MUST expire and have a lifetime of no longer than 300 seconds.
An ISP’s authorisation server MUST reject a JWT with an expiry time that has passed. An ISP SHOULD:
allow for clock skew of 300 seconds between systems when assessing the expiry of a JWT; and
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:
iss
An ISP MUST NOT support dynamic registration of IXPs as clients.
Endpoints and parameters specified in the Discovery document MAY be considered public information regardless of the existence of the discovery document.
An ISP MAY provide a well-known endpoint for its OpenID configuration as described in the OpenID Connect Discovery 1.0.
If an ISP provides a well-known endpoint, it MUST secure the well-known endpoint as outlined in the OpenID Connect Discovery 1.0 specification. An IXP MAY apply additional security controls if required by their business need.
If an ISP publishes a discovery document, the document MUST as a minimum contain the following REQUIRED fields and MAY contain the OPTIONAL 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 an ISP as defined in Schedule 3 (AGDIS Attribute Profile).
claims\_supported
An ISP MUST support all mechanisms for requesting a level of assurance as prescribed in section
2.8.3 of this Schedule.
As a central and trusted participant of the AGDIS, all IXPs are responsible for collecting express consent from the individual in accordance with the attribute sharing policies outlined in Chapter 2 and Chapter 3 of Schedule 3 (AGDIS Attribute Profile).
An IXP MUST provide the mechanisms to capture express consent from the individual.
An ISP MAY gather consent from the individual to share attributes to the AGDIS but SHOULD take into consideration the end-to-end user experience impacts of additional consent gathering mechanisms.
The authorisation response to the authorisation code flow MUST return the following fields in the response:
state
The value of the state parameter passed in via the authentication request. This value MUST match exactly.
code
The authorisation code, a random string issued by the OIDC provider to be used request to the Token Endpoint.
The key requirements for these fields are described in section 4.1.2 (Authorization Response) of RFC 6749.
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 ISP’s Authorisation Endpoint in response to the Authorisation Request sent by an IXP.
If the individual denies or cancels the request, or the individual fails to authenticate, the ISP MUST inform the IXP by using the error responses defined in either:
section 4.1.2.1 (Error Response) of RFC 6749; or
section 3.1.2.6 (Authentication Error Response) of OpenID Connect Core 1.0. This profile defines an additional authentication error response:
authentication\_cancelled
The End-User did not proceed with the authentication interaction.
A successful token response includes an access token, which can be used to make a UserInfo request, and as ID token (signed and optionally encrypted JWT) as per section 3.1.3.3 (Successful Token Response) of the OpenID Connect Core 1.0.
An ISP MAY also include a Refresh Token in the Token Response.
An ISP MAY encrypt ID Tokens using the appropriate key of the requesting IXP.
An ISP issued ID Token MUST expire with a lifespan of no longer than 300 seconds.
An ISP SHOULD assign lifespans shorter than 300 seconds to the ID Tokens it issues.
An ISP issued ID Token MUST contain the following fields that are defined as REQUIRED.
iss
REQUIRED. The issuer field is the URL of the expected issuer.
aud
REQUIRED. The audience field contains the client ID of the client.
sub
REQUIRED. The identifier of the user. Note it MUST be a pairwise anonymous identifier and be unique to the client’s OpenID Sector.
acr
REQUIRED. This is the level of assurance at which the user was authenticated at.
nonce
If a nonce value was supplied with the authentication request, then this value is REQUIRED.
jti
REQUIRED. A unique identifier for the token which can be used to prevent the reuse of the token.
exp, iat, nbf
REQUIRED. The expiration, issued at, and not before timestamps for the tokens. They are dates presented as an integer representing the number of seconds since 1970-01-01T00:00:00Z UTC (Unix epoch) within acceptable ranges.
The following is an example of an ID token signed using the server’s RSA key.
eyJhbGciOiJSUzI1NiJ9.eyJhdXRoX3RpbWUiOjE0
MTg2OTg3ODIsImV4cCI6MTQxODY5OTQxMiwic3ViI
joiNldaUVBwblF4ViIsIm5vbmNlIjoiMTg4NjM3Yj
NhZjE0YSIsImF1ZCI6WyJjMWJjODRlNC00N2VlLTR
iNjQtYmI1Mi01Y2RhNmM4MWY3ODgiXSwiaXNzIjoi
aHR0cHM6XC9cL2lkcC1wLmV4YW1wbGUuY29tXC8iL
CJpYXQiOjE0MTg2OTg4MTJ9mQc0rtL56dnJ7_zO_f
x8-qObsQhXcn-qN-FC3JIDBuNmP8i11LRA_sgh_om
RRfQAUhZD5qTRPAKbLuCD451lf7ALAUwoGg8zAASI
5QNGXoBVVn7buxPd2SElbSnHxu0o8ZsUZZwNpircW
NUlYLje6APJf0kre9ztTj-5J1hRKFbbHodR2I1m5q
8zQR0ql-FoFlOfPhvfurXxCRGqP1xpvLLBUi0JAw3
F8hZt_i1RUYWMqLQZV4VU3eVNeIPAD38qD1fxTXGV
Ed2XDJpmlcxjrWxzJ8fGfJrbsiHCzmCjflhv34O22
zb0lJpC0d0VScqxXjNTa2-ULyCoehLcezmssg
Figure 9 Sample ID Token signature
Its claims are as follows:
{
"auth_time": 1418698782,
"exp": 1418699412,
"sub": "6WZQPpnQxV",
"nonce": "188637b3af14a",
"aud": [
"c1bc84e4-47ee-4b64-bb52-5cda6c81f788"
],
"iss": "https://idp.gov.au/",
"acr":"urn:id.gov.au:tdif:acr:ip3:cl2",
"iat": 1418698812,
"nbf": 1418698812
}
Figure 10 Claims used to the generate the prior signature
An ISP MUST support returning claims via the UserInfo endpoint as prescribed by the requirements outlined in Schedule 3 (AGDIS Attribute Profile).
When processing a UserInfo request an ISP MUST only return the claims that are authorised within the authentication request associated with the presented access token.
An ISP MUST NOT return empty or null values for claims that cannot be fulfilled unless 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 ISP MUST accept requests containing a request object signed by the requesting IXPs private key. An ISP MUST validate the signature on request objects using the requesting IXP’s public key.
An ISP MUST implement support for receiving requests objects encrypted with one of its public keys.
An ISP MUST return the ACR value used for the authentication even if the acr claim was not marked as essential or the acr_values parameter was used.
An ISP MUST return the ACR value used for the authentication even if the acr claim was not marked as essential or the acr_values parameter was used.
IXPs and ISPs MUST return claims on a best effort basis.
An ISP or its connected IXPs asserting it can provide a user claim does not imply that the data is available for all users.
An IXP MAY returns claims outside of the claims_supported list but MUST ensure that they do not violate the data sharing and privacy constraints where prescribed under one or more of the following:
the Act;
the Accreditation Rules;
the Digital ID Rules; or
the Accreditation Data Standards.
An ISP MUST implement the OpenID Connect support ISP specific scopes and claims outlined as in Schedule 3 (AGDIS Attribute Profile).
Assurance levels are outlined in Schedule 1 (AGDIS Onboarding Specifications).
An ISP MUST implement support to allow its TRPs to use either the acr_values or acr claim to request their required ACR.
An ISP MUST reject any request that include both the acr_values and acr claims.
When the acr claim is requested, an ISP 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 11 Sample assurance level requests using claims
When the acr values are marked as an essential claim, the ISP 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 ISP MUST respond with an authentication error.
If the acr claim is not marked as essential or no acr value was supplied in the brokered authentication request, then an ISP MUST respond with the level of assurance the individual was able to achieve.
An ISP MUST adhere to all the ISP relevant attribute sharing policies set out in Chapter 2 and Chapter 3 of Schedule 3 (AGDIS Attribute Profile).
All clients of an ISP:
MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and
SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.
IXPs and ISPs MUST return claims on a best effort basis.
An ISP or its connected IXPs asserting it can provide a user claim does not imply that the data is available for all users.
An IXP MAY returns claims outside of the claims_supported list but MUST ensure that they do not violate the data sharing and privacy constraints where prescribed under one or more of the following:
the Act;
the Accreditation Rules;
the Digital ID Rules; or
the Accreditation Data Standards.
An ISP MUST implement the OpenID Connect support ISP specific scopes and claims outlined as in Schedule 3 (AGDIS Attribute Profile).
Assurance levels are outlined in Schedule 1 (AGDIS Onboarding Specifications).
An ISP MUST implement support to allow its TRPs to use either the acr_values or acr claim to request their required ACR.
An ISP MUST reject any request that include both the acr_values and acr claims.
When the acr claim is requested, an ISP 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 11 Sample assurance level requests using claims
When the acr values are marked as an essential claim, the ISP 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 ISP MUST respond with an authentication error.
If the acr claim is not marked as essential or no acr value was supplied in the brokered authentication request, then an ISP MUST respond with the level of assurance the individual was able to achieve.
An ISP MUST adhere to all the ISP relevant attribute sharing policies set out in Chapter 2 and Chapter 3 of Schedule 3 (AGDIS Attribute Profile).
All clients of an ISP:
MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and
SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.
An IXP MUST implement support to broker between the protocols used by its connected ISPs and PRPs.
The AGDIS only supports the OpenID Connect Core 1.0.
If the sub claim is specified it MUST be handled as outlined in section 3.1.2 of this Schedule.
If the TRP’s authentication request includes attributes that are fulfilled by itself or an ASP, an IXP SHOULD NOT forward theses attribute requests to the ISP unless it is necessary.
All other attributes included in the TRP’s authentication request MUST be included in the IXPs authentication request to the ISP in accordance with the attribute sharing policies as prescribed in Chapter 4 of Schedule 3 (AGDIS Attribute Profile).
An IXP MAY expand the scopes defined in an authentication request into underlying claims when brokering an authentication request to its ISPs and ASPs.
Scopes and claims not outlined in Schedule 3 (AGDIS Attribute Profile) MUST be ignored by the IXP when brokering an authentication request. The IXP MUST NOT raise an error when scopes and claims are ignored.
An IXP MAY support the sub claim in authentication requests.
If an IXP implements support the sub claim in authentication requests:
the IXP MUST resolve the pairwise identifier presented in the sub claim in the authentication request from the TRP to an existing pairwise identifier; and
the IXP MAY return an error if the pairwise identifier for the user cannot be resolved to the target ISP.
If an IXP receives a single value for the acr_values or acr claim in an authentication request, the IXP MUST pass the set of ACR values that meet or exceed the requested value to the ISP in the brokered authentication request.
If the acr claim is marked as essential in the authentication request, an IXP MUST mark the acr claim as essential when sending the authentication request to the selected ISP.
An IXP MUST implement these processing rules to broker the OIDC prompt parameter.
Table 1 IXP prompt parameter brokering requirements
| From Relying Party | To Identity Service Provider |
|---|---|
| None | None |
| Login | Login |
| Consent | Ignored.An IXP MUST implement consent for the release of attributes in accordance with the attribute sharing policies as defined in Schedule 3 (AGDIS Attribute Profile). |
| Select Account | Service selection of identity or persona for user in context. |
If an IXP has implemented support for the id_token_hint mechanism, the following processing rules apply:
where the IXP receives an id\_token\_hint within an authentication request from a TRP, the IXP is REQUIRED to validate the Identity Token and extract the subject;
the IXP MUST resolve the subject identifier at the ISP as per section 3.1.2 of this Schedule; and
the IXP MUST include the resolved subject identifier when brokering the authentication request to the ISP using the sub claim as per section 5.5 of the OpenID Connect Core 1.0 and mark the sub claim as essential.
Schedule 3 (AGDIS Attribute Profile) outlines the attributes and attribute sets that are available to PRPs.
Figure 1 Verified Documents sample claim request................................81
Figure 2 Self-asserted address sample claim request..............................91
Figure 3 Self-asserted other email address sample claim request.....................93
Figure 4 Self-asserted other email address scope equivalent claim request.............93
Figure 5 Self-asserted other phone number sample claim request using the contact type..94
Figure 6 Self-asserted other phone number sample claim request using telephony type...94
Figure 7 Self-asserted other phone number scope equivalent claim request............94
This Chapter outlines how attributes operate within the context of the AGDIS and the components of an attribute sharing policy.
Consent types prescribe requirements for gathering of express consent from the individual by an accredited entity participating in the AGDIS.
The consent types outlined in this Schedule are found in Table 1 below.
An attribute sharing policy MUST include a consent type and assign the management of that consent to either or both:
a specific entity (which is a named accredited entity such as myGov as an ASP); and
a specific role (such as the ASP, ISP and IXP).
Not all attributes have guaranteed availability, and some may not be available for the IP level associated with the authenticated session.
The assertion of attributes in an individual’s digital ID account is dependent on the documents available to them, the documents they chose to verify their identity, and any additional linkages an individual has with ASP managed attributes. Accordingly, the fulfilment of some attributes may not be practical however some attributes may still be required.
The necessity to meet an attributes request is referred to as a fulfilment requirement in this Schedule.
An attribute sharing policy MUST have a fulfilment policy to inform the behaviours of entities participating in the AGDIS when attribute requests cannot be fulfilled.
The two fulfilment requirements used in this Schedule are outlined in Table 2 below.
Table 2 Attribute fulfilment requirement classes
| Fulfilment requirement | Criteria and description |
|---|---|
| Best effort | The attribute or attribute set MUST be fulfilled if the individual has verified or asserted the requested attributes or attribute set and has provided express consent to share them.If the attributes request cannot be fulfilled or the individual has not provided express consent to share, an error SHOULD NOT be raised unless the attribute sharing policy requires it. |
| Required | The attribute or attribute set MUST be fulfilled.If the attribute or attribute set cannot be fulfilled or the individual did not provide express consent to share, an error MUST be raised. |
Attributes shared with PRPs via the AGDIS are either readily available to PRPs or require approval to access. The rules defining if or why a PRP can request attributes or attribute sets is referred to as an access policy in this Schedule.
An attribute sharing policy MUST outline the access policy that applies to its attributes or attribute sets.
An attribute sharing policy MAY extend the access policy for a given context provided the intent of the policy is not overridden.
The 4 access policies available under this Schedule are outline in Table 3 below.
Table 3 Access policies that MUST be applied to attributes
| Policy | Details |
|---|---|
| Open | Any PRP MAY request an attribute or attribute set with this access control.If attributes are available, an ASP, ISP and IXP MUST fulfill requests for attributes subject to this access policy. |
| Not available | The attribute request MUST NOT be fulfilled.An ASP, ISP and IXP MAY respond with an error. |
| Restricted | A PRP MUST be approved to request this attribute or attribute set.An IXP MUST only broker requests to the ASP, ISP and IXP that are permitted to fulfill the request. |
| Platform | A PRP MUST meet the platform specific requirements to have the attribute request fulfilled.An IXP MUST only broker these attribute requests to the ASP, ISP and IXP that can fulfill the requests.An IXP MAY respond with an error if the PRP is not a member of the attribute’s related platform or approved by the platform to request the attribute or attribute set. |
An attribute sharing policy MUST be accompanied by a high-level specification of an attribute or attribute set’s underlying values.
This Chapter outlines the attribute sharing policies for the Core Attributes available from the AGDIS.
Core Attributes are foundational elements used to identify an individual.
A summary of the attribute sharing policies, outlined here for Core Attributes, is provided in Table 5 below.
All Core Attributes are subject to an Open access policy as provided in Table 4 above. Not all the Core Attributes are verified as outlined in Table 5 below.
An IXP MUST request express consent from the individual for Core Attributes which have changed since consent was last recorded by the IXP.
An IXP MUST support brokering requests to its ISPs for all Core Attributes for requested IP Level of IP1 Plus or stronger.
At IP1 Plus or stronger, an ISP MUST fulfill an attribute request for:
Family Name;
Date of Birth;
Core Attributes Last Updated.
An ISP MUST return an error if it cannot fulfill a request for the above attributes.
At IP1 Plus or stronger, an ISP MUST fulfill requests for the following attributes if they are available:
Given Names;
Middle Names.
At IP1 Plus or stronger, an ISP MAY fulfill an attribute request for Full Name.
At an IP Level less than IP1 Plus, an ISP SHOULD1 NOT fulfill a request for Core Attributes other than Preferred Name.
An ISP MAY fulfill requests for Preferred Name at any IP Level. Noting that Preferred Name should be considered a self-asserted attribute as defined in section 2.3.1 of this Schedule.
Any attribute returned at IP1 should be assumed self-asserted.
An ISP MUST note every change made to the Core Attributes set by recording the date and time of the last change in the Core Attributes Last Updated attribute.
An IXP SHOULD use the Core Attributes Last Updated attribute to determine if the individual is required to provide consent before responding to the PRP’s attribute request.
Contact details like an email address and mobile phone number are sourced by the ISP during the identity proofing process or the individual’s ongoing use of their digital ID. Contact details are only referred to as validated due to ownership of an email address or phone number not being readily verifiable. A summary of the attribute sharing policies for these attributes is outlined in Table 6 below.
Validated Contact Details attributes are subject to an Open access policy.
View image in the official source
1 It is intended that this requirement will change to become ‘MUST’ (rather than ‘SHOULD’) 12 months from commencement of the Act.
Additional names an individual is or was known by are verified by ISPs from the EoI documents presented during the initial or subsequent identity proofing process.
These Attributes include the variations of the individual’s name from those recorded in the Core Attributes and are only sourced from the following document types:
Commencement of Identity Documents;
Linking Documents;
Photo ID Documents.
A summary of the attribute sharing policy for Verified Other Names is outlined in Table 7 below.
The Verified Other Names attribute set is subject to an Open access policy (as defined above) at IP1 Plus and stronger.
An IXP MUST NOT broker requests for Verified Other Names for IP levels weaker than IP1 Plus.
An IXP MAY ignore attribute requests or raise an error if the requested assurance level is less than IP1 Plus.
An IXP MUST request express consent from the individual for the Verified Other Names attribute set which have changed since consent was last recorded by the IXP.
An ISP MUST support attribute requests for Verified Other Names.
The verified fields from the documents an individual submitted during the identity proofing process at their chosen ISP are available as the Verified Documents attribute set. The attributes in the Verified Documents attribute sets are sourced from:
Commencement of Identity Documents;
Linking Documents;
Photo ID Documents;
Use in the Community Documents.
Not all fields/attributes from a verified document can be readily verified.
The ISP MUST return all available verified attributes associated to the verified document request. A summary of the attribute sharing policy for verified documents is presented in Table 8 above.
An IXP MUST request express consent from the individual on every use of the Verified Documents attribute set.
An IXP MUST NOT broker requests for Verified Documents for assurance levels weaker than IP2. An IXP MUST support brokering of attribute requests for a single or multiple Verified Documents. An IXP MUST only broker attribute requests for Verified Documents from approved PRPs.
An ISP MUST support attribute request for single or multiple Verified Documents.
When processing generic requests for Verified Documents, an ISP MUST prepare a response that conforms to IP2 or higher.
When processing requests for specific Verified Documents, an ISP MUST only respond to request for valid document types and for documents the individual has verified. Valid document types are outlined in Table 11 below.
The data representation for a Verified Document is set of named simple and complex attributes. Each set representing an instance of a Verified Document MUST have the following members:
Document Type Code with a value that MUST be one of the URNs outlined in Table 11 below;
Document Verification Method that MUST be one of the enumerated values in Table 12 below;
Document Verification Date MUST be valid a date and time value;
Document Date of Birth MUST be a valid date extracted from the document;
Document Identifiers is a collection that MUST contain one or more document identifiers outlined in the document type’s schema;
Document Names is a collection that MUST contain the required document names for the document type’s schema;
Document Attributes is a collection that MUST contain the required document attributes outlined in the document type’s schema.
A more detailed overview of the fields is provided in Table 9 below.
Table 18 Verified Birth Certificate schema
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:BC”. |
| Document Verification Method | - | Y | String | Only source verification is permitted for Birth Certificates. See Table 12 above for accepted values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Names | Family Name Given Name | Y | String | For NSW, VIC or WA issued Birth Certificates:Given Name MAY be left blank if Family Name has a value;Family Name MAY be left blank if Given Name has a value.All other state and territory BDM issued certificates the string MUST be non- empty and have a maximum length of 80 characters.Values MUST only be composed of alpha characters, apostrophes, hyphens, and spaces. |
| Document Date of Birth | Date of Birth | Y | String | MUST be an RFC 3339 formatted date value or year value of the format YYYY, YYYY-MM, or YYYY-MM-DD. Where the year value MUST be in |
Table 19 Verified Change of Name Certificate schema
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:NC”. |
| Document Verification Method | - | Y | String | Only source verification is permitted for Change of Name Certificates. See Table 12 above for legitimate values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Names | Family Name Given Name | Y | String | For NSW, VIC or WA issued Birth Certificates:Given Name MAY be left blank if Family Name has a value;Family Name MAY be left blank if Given Name has a value.All other state and territory BDM issued certificates the string MUST be non- empty and have a maximum length of 80 characters.Values MUST only be composed of alpha characters, apostrophes, hyphens, and spaces. |
| Document Date of Birth | Date of Birth | N | String | MUST be an RFC 3339 formatted date value or year value of the format YYYY or YYYY-MM-DD. Where the year value MUST be in the range 1753 to 3000. |
Table 20 Verified Marriage Certificate schema
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:MC”. |
| Document Verification Method | - | Y | String | Only source verification is permitted for Marriage Certificates. See Table 12 above for legitimate values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Names | Family Name Given Name Family Name 2Given Name 2 | Y | String | For NSW, VIC or WA issued Marriage Certificates:Given Name MAY be left blank if Family Name has a value;Family Name MAY be left blank if Given Name has a value.All other state and territory BDM issued certificates the string MUST be non- empty and have a maximum length of 80 characters.Values MUST only be composed of alpha characters, apostrophes, hyphens, and spaces. |
| Document Date of Birth | Date of Birth | N | String | MUST be an RFC 3339 formatted date value or year value of the format YYYY or YYYY-MM-DD. Where the year value MUST be in the range 1753 to 3000. |
Table 21 Verified Citizenship Certificate and Registration by Descent
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:RD”.for Registration by DescentValue MUST be “urn:id.gov.au:tdif:doc:type_code:CC”.for Citizenship Certificate |
| Document Verification Method | - | Y | String | Only source verification is permitted for Certificates of Registration by Descent. See Table 12 above for legitimate values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Names | Family Name | Y | String | MUST only be comprised of alpha characters (including spaces, hyphens, and apostrophes) and MUST be a non-empty string with a maximum length of 100 characters.MUST only be composed of alpha characters, apostrophes, hyphens, and spaces. |
| Given Name | N | String | If provided MUST only be comprised of alpha characters (including spaces, hyphens, and apostrophes) and MUST be a non-empty string with a maximum length of 100 characters. |
Table 22 Verified ImmiCard schema
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:IM”. |
| Document Verification Method | - | Y | String | Only source verification is permitted for ImmiCards. See Table 12 above for legitimate values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Names | Family Name Given Name | Y | String | Values MUST be a non-empty string with a maximum of 49 characters in length.Values MUST only be composed of alpha characters, apostrophes, hyphens, and spaces. |
| Document Date of Birth | Date of Birth | Y | String | MUST be an RFC 3339 formatted date value or year value of the format YYYY- MM-DD. Where the year value MUST be in the range 1753 to 3000. |
| Document Identifiers | ImmiCard Number | Y | String | MUST be a string of characters in length 9. The string MUST be composed of 3 leading alpha characters, followed by 6 numeric characters, e.g., ABC123456. |
| Document Attributes | - | - | - | No attributes for the document. |
Table 23 Verified Visa Request schema
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:VI”. |
| Document Verification Method | - | Y | String | Only source verification is permitted for Visa Requests. See Table 12 above for legitimate values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Names | Family Name Given Name | Y | String | MUST be a non-empty string with a maximum length of 49 characters.MUST only be composed of alpha characters, apostrophes, hyphens, and spaces. |
| Document Date of Birth | Date of Birth | Y | String | MUST be an RFC 3339 formatted date value or year value of the format YYYY- MM-DD. Where the year value MUST be in the range 1753 to 3000. |
| Document Identifiers | Passport Number | Y | String | MUST be non-empty string with a length of 14 upper and lower case alphanumeric characters, in any order. |
Table 24 Verified Driver Licence schema
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:DL”. |
| Document Verification Method | - | Y | String | Only source verification is permitted for Driver Licences. See Table 12 above for legitimate values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Names | Family Name | Y | String | MUST be a non-empty string and only be comprised of alpha characters (including spaces, hyphens, and apostrophes), and have a maximum length of 40 characters. |
| Given Name | Y | String | MUST be a non-empty string and only be comprised of alpha characters (including spaces, hyphens, and apostrophes), and have a maximum length of 20 characters. | |
| Middle Name | N | String | If available it MUST be a non-empty string and only be comprised of alpha characters (including spaces, hyphens, and apostrophes), and have a maximum length of 20 characters. |
Table 25 Verified Medicare Card schema
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:MD”. |
| Document Verification Method | - | Y | String | Only source verification is permitted for Medicare Cards. See Table 12 above for legitimate values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Date of Birth | Date of Birth | Y | String | MUST be an RFC 3339 formatted date value or year value of the format YYYY- MM-DD. Where the year value MUST be in the range 1753 to 3000. |
| Document Identifiers | Card Number | Y | String | MUST be a string of 10 numerical characters. |
| Individual Ref Number | Y | String | MUST be a single numeric character within the range of 1 to 9 inclusive. | |
| Document Attributes | Card Expiry | Y | Date | MUST meet the data format for the Card Type. See Table 15 for expiry date formats date. |
Table 26 Verified Passport schema
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:PP”. |
| Document Verification Method | - | Y | String | Only source verification is permitted for Passports and Australian Travel Documents. See Table 12 above for legitimate values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Names | Family Name | Y | String | MUST be a non-empty string with a maximum length of 31 characters.MUST only be composed of alpha characters, hyphens, apostrophes, and spaces. |
| Given Name | N | String | If available, MUST be a non-empty string with a maximum length of 31 characters.MUST only be composed of alpha characters, hyphens, apostrophes, and spaces. |
Table 27 Verified Centrelink Concession Card schema
| Section | Field Name(s) | Required | Type | Constraints |
|---|---|---|---|---|
| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:CO”. |
| Document Verification Method | - | Y | String | Only source verification is permitted for Centrelink Concession Cards. See Table 12 above for legitimate values. |
| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |
| Document Names | Name | Y | String | MUST be a non-empty string with a maximum length of 32 characters.MUST only be composed of alpha characters, hyphens, apostrophes, and spaces. |
| Document Date of Birth | Date of Birth | N | String | MUST be an RFC 3339 formatted date value or year value of the format YYYY, YYYY-MM, or YYYY-MM-DD. Where the year value MUST be in the range 1753 to 3000. |
| Document Identifiers | CRN | Y | String | MUST be a string of 10 characters.The first 9 characters MUST be numerical values and the last character MUST be an alpha character, e.g., 123456789A |
The Digital ID Identifier is a unique identifier for an individual. The Digital ID Identifier:
(a) For PRPs, is the pairwise identifier assigned to an individual by an IXP; and
(b) for IXPs, the GPI or pairwise identifier assigned to an individual by an ISP.
Authentication Time is the date and time when the individual successfully authenticated at the ISP. An ISP MUST support this metadata value.
An IXP MUST support brokering requests for this metadata value.
The data representation for the date-time value is dependent upon the federation protocols being brokered. An IXP MAY need to translate values between types when brokering between different federation protocols in a transaction.
The Assurance Level of the authenticated digital ID outlines the IP level and authentication level attained during authentication at the ISP.
An IXP MUST broker requests for this value as requested from a PRP to the ISPs in accordance with the requirements in section 2.1.9 of Schedule 1 (AGDIS Onboarding Specifications) and requirements outlined by the federation protocols being used.
An ISP MUST process and respond to request for the value in accordance with the requirements in section 2.1.3 of Schedule 1 (AGDIS Onboarding Specifications) and requirements outlined in the relevant federation protocols.
The data representation for this value is specified in Schedule 1 (AGDIS Onboarding Specifications) and illustrated in Table 29 below.
The Authentication Method value communicates to the PRP which ISP the individual used to authenticate themselves. The Authentication Method is an IXP managed value.
An IXP MAY provide the Authentication Method based on the ISP the individual has successfully authenticated themselves if required.
An IXP MAY cache the attribute to support subsequent SSO requests.
An IXP MUST NOT return any information about the Authentication Method if the authentication fails or is cancelled by the individual.
The data representation for the Authentication Method is a URN presented in Table 30 below.
Last Updated is the date and time that any of the individual’s attributes were last updated.
The RP audit ID requirements are outlined in section 2.1.2 of Schedule 1 (AGDIS Onboarding Specifications).
The RP audit ID is an IXP specific value that ISPs do not need to support.
An RP audit ID is a unique audit identifier generated for every logical interaction between a PRP and an IXP to enable an audit trail.
An IXP MUST NOT share the RP audit ID it has generated for a PRP with ISPs.
To ensure uniqueness of the RP audit ID within the AGDIS a UUID is used. The UUID generation MUST conform to RFC 4122.
Table 29 Authentication Assurance Levels
| IP level | Authenticator level | URN |
|---|---|---|
| IP1 | AL1 | urn:id.gov.au:tdif:acr:ip1:cl1 |
| AL2 | urn:id.gov.au:tdif:acr:ip1:cl2 | |
| AL3 | urn:id.gov.au:tdif:acr:ip1:cl3 | |
| IP1 PLUS | AL1 | urn:id.gov.au:tdif:acr:ip1p:cl1 |
| AL2 | urn:id.gov.au:tdif:acr:ip1p:cl2 | |
| AL3 | urn:id.gov.au:tdif:acr:ip1p:cl3 | |
| IP2 | AL2 | urn:id.gov.au:tdif:acr:ip2:cl2 |
| AL3 | urn:id.gov.au:tdif:acr:ip2:cl3 | |
| IP2 PLUS | AL2 | urn:id.gov.au:tdif:acr:ip2p:cl2 |
| AL3 | urn:id.gov.au:tdif:acr:ip2p:cl3 | |
| IP3 | AL2 | urn:id.gov.au:tdif:acr:ip3:cl2 |
| AL3 | urn:id.gov.au:tdif:acr:ip2p:cl2 | |
| IP4 | AL3 | urn:id.gov.au:tdif:acr:ip4:cl3 |
An individual may nominate a name they prefer to be known as at the PRPs they access. A Preferred Name can reflect an individual’s personal preference or may be culturally significant. Ideally an individual should be able to nominate a preferred name they wish to use on the AGDIS.
Given an individual may use the attribute at their ISP to satisfy cultural requirements the preferred name SHOULD be easy to update.
Preferred Name attribute SHOULD be assumed to be self-asserted.
Although it is a Core Attribute, a Preferred Name MUST not be used as an authoritative attribute in the same manner as a PRP would use any of the verified name attributes (Family Name, Give Names or Middle Names).
The data representation for preferred names follows the requirements for the verified name attributes, and the data representation of the federation protocol(s) used to fulfill an attribute request.
An individual MAY self-assert a residential, postal, business, or other addresses.
Addresses MAY be collected during the identity proofing process or added by the individual during the normal use and management of their digital ID.
The attribute response for addresses MAY be a single address or a collection of addresses. The data representation for an Address attribute MUST contain the following fields:
the address type;
street address;
locality;
region;
post code; and
validated.
The data representation MAY also contain the following fields:
An individual MAY self-assert additional email addresses for use in different contexts, for example when accessing business services with their personal digital ID.
An ISP MUST NOT permit an individual to add an email address that is currently claimed as the validated email address for the individual’s or other active digital ID accounts on their system.
If an ISP uses the Validated Email Address as the account identifier, the ISP MAY use any of the other email addresses asserted by an individual as an ad hoc replacement for the individual’s account identifier.
An ISP MUST validate the individual has control over all other email addresses they assert if it is used as a replacement for the account identifier.
The attribute response for other email addresses MAY be a single email address or a collection of email addresses.
Each Other Email Address MUST contain:
the email address;
a flag indicating if the email address has been validated; and
a contact type label.
The data representation for each other email address string MUST conform to the requirements outlined above for Validated Email Address in section 2.1.2 of this Schedule.
The contact type value MUST be one the contact type URNs enumerated in Table 35 below.
An ISP fulfilling an attribute request for other email address where the contact type of address being requested is not specified SHOULD return a default value nominated by the individual.
An individual may self-assert additional phone numbers to use with their digital ID, for example an additional phone number may be a personal landline number or business phone number.
The attribute response for other phone numbers MAY be a single phone number object or a collection of phone number objects.
An individual can self-assert their place of birth. For individuals holding an Australian Birth Certificate the Place of Birth field is not verified during the identity proofing process and presently there are no readily available mechanisms to validate foreign birth certificates and their attributes.
If an ISP supports this self-asserted attribute, they SHOULD ensure the location supplied by the individual is real if practical to do so.
The data representation for this attribute is a string with a maximum length of 255 characters.
Qualification, honorific or gender-based titles can be asserted by the individual to tailor user experiences at a PRP.
An ISP MAY allow an individual to specify their preferred title.
An ISP SHOULD appropriately limit the types of titles an individual may choose.
The data representation for this attribute is string with a maximum length of 100 characters.
This Chapter provides the attribute sharing policies for the attributes and attribute sets provided by ASPs.
An IXP MUST implement support to broker access to these attributes in accordance with this Chapter’s attribute sharing policies.
An IXP MUST not broker requests for ASP managed attributes or attribute sets to ISPs to ensure AGDIS privacy requirements are maintained.
Table 37 ASP managed attributes and attribute sets
| Attribute Set | Attributes | Description |
|---|---|---|
| Business Authorisations | Authorisation Schemas Unique Relationship ID Entity IDEntity Type Entity Name Contact Emails Relationship TypeRelationship Start Time Relationship End Time RolesEntitlementsAttributes Last Updated | The Australian Taxation Office’s Relationship Authorisation Manager (RAM) manages the authorisation for a person to act on behalf of a business entity that is registered with the Australian Business Register (ABR) and issued with an Australian Business Number (ABN). |
| myGov linkID | myGov linkID | A pairwise identifier used by the myGov platform. This is attribute is subject to restrictions. |
To enable the use of attributes and attribute sets across the AGDIS an idiomatic mapping from this profile to Schedule 2 (AGDIS OpenID Connect Profile) is outlined in this Chapter.
The mapping outlines requirements to ensure interoperability amongst entities participating in the AGDIS making and fulfilling attribute requests. The data types assigned to the mapped OIDC scopes and claims, for each attribute, are also defined here along with their representation.
The scopes an IXP MUST make available for a PRP to request are:
openid
profile
email
phone
tdif\_other\_names
tdif\_docs
tdif\_business\_authorisations
The attribute sets mapped to these OpenID Connect Core 1.0 scopes along with the relevant sets of claims is outlined in Table 42 below. A detailed attribute mapping to claims, along with data types, is presented in Table 46 below.
Additional scopes for Self-Asserted Attributes that an IXP SHOULD support brokering attribute requests for are:
adgis\_address
agdis\_other\_email
agdis\_other\_phone
agdis\_birth\_place
agdis\_personal\_title
The scopes an ISP MUST make available for its IXPs to request are:
openid
tdif\_core
tdif\_email
tdif\_phone
tdif\_other\_names
tdif\_docs
The attribute sets mapped to these OpenID Connect Core 1.0 scopes along with the relevant sets of claims are outlined in Table 44. A detailed attribute mapping to claims, along with data types, is presented in Table 46.
Additional scopes for Self-Asserted Attributes an ISP SHOULD make available for its IXPs to request are:
adgis\_address
agdis\_other\_email
agdis\_other\_phone
agdis\_birth\_place
agdis\_personal\_title
The self-asserted attribute sets are mapped to OpenID Connect Core 1.0 scopes and claims are outlined in Table 45, with detailed mapping from attributes to claims in Table 46.
An ISP SHOULD support attribute requests for each individual claim outlined in Table 44 and Table 45.
An ISP MAY fulfill attributes request via either the Token or UserInfo Endpoints.
An ISP SHOULD encrypt all scopes and claims, except for the common attributes set, when fulfilling and attribute requests via the Token Endpoint.
The primitive data types assigned to attributes conveyed via claims and scopes conform to the JSON data interchange format as outlined in RFC 8529. The primitive JSON data types are the building blocks used in the data type definitions for the simple and complex types used in the AGDIS.
Simple data types are JSON primitives with additional constraints applied that MUST be applied to the held value for an attribute. The AGDIS type and its associated JSON type with constraints are presented in Table 48 below.
A JSON string that can represent name attributes that are not mandatory. The value has a:
(a) minimum length of zero characters; and
(b) maximum length of 100 characters.
A JSON string that can represent name attributes that are mandatory. The value has a:
(a) minimum length of 1 character; and
(b) maximum length of 100 characters.
The primitive data types assigned to attributes conveyed via claims and scopes conform to the JSON data interchange format as outlined in RFC 8529. The primitive JSON data types are the building blocks used in the data type definitions for the simple and complex types used in the AGDIS.
Simple data types are JSON primitives with additional constraints applied that MUST be applied to the held value for an attribute. The AGDIS type and its associated JSON type with constraints are presented in Table 48 below.
A JSON string that can represent name attributes that are not mandatory. The value has a:
(a) minimum length of zero characters; and
(b) maximum length of 100 characters.
A JSON string that can represent name attributes that are mandatory. The value has a:
(a) minimum length of 1 character; and
(b) maximum length of 100 characters.
RFC 3339 compliant date string that MUST conform to one of the following:
YYYY
YYYY-MM
YYYY-MM-DD
This value is commonly used to represent birth dates.
RFC 3339 compliant date and time string capturing a significant date and time in Coordinated Universal Time (UTC). Values MUST assume one of the following forms:
YYYY-MM-DDTHH:MM:SSZ
YYYY-MM-DDTHH:MMZ
RFC 3339 compliant date string that MUST conform to one of the following:
YYYY
YYYY-MM
YYYY-MM-DD
This value is commonly used to represent birth dates.
RFC 3339 compliant date and time string capturing a significant date and time in Coordinated Universal Time (UTC). Values MUST assume one of the following forms:
YYYY-MM-DDTHH:MM:SSZ
YYYY-MM-DDTHH:MMZ
A JSON number representing a date and time as the number of seconds since 1970-01-01T00:00:00Z up to when the time was observed.
Note: Follows the same format as the OIDC updated_at claim outlined in section 5.1 of the OpenID Connect Core 1.0 profile.
A non-empty JSON string with a maximum length of 254 characters (defined by RFC 5321) with a format that conforms to the syntax defined in RFC 5322 and SHOULD be conformant to guidance outlined in RFC 3696.
A non-empty JSON string with a maximum length of 15 characters with format the confirms to the phone numbering for prescribed in ITU-T E.164.
A JSON string that MUST be at most 36 characters in length and is generated in accordance with RFC 4122.
Selection of an appropriate version of the UUID version to be used is at the discretion of the participant. The UUID version choice MUST be suitable to avoid collisions.
An Other Names Object is a JSON Object that represents an instance of a Verified Other Name. The data types outlined in Table 46 above for the encapsulated claims MUST be applied.
At least one value of the claims MUST be present for the Other Name Object to be valid.
Table 49 Other Names Object fields
| Attribute | Claim/Field name | Required |
|---|---|---|
| Family Name | family_name | Y |
| Given Name | given_name | N |
| Middle Name | middle_name | N |
| Full Name | full_name | Y |
The Address Object is a JSON Object that is intended to be used for the self-asserted address scope and claims. The specification for this data type maps directly to the definition outlined in Table 32 above.
Table 50 Address Object fields definitions
| Attribute | Field name | Data type | Required |
|---|---|---|---|
| Address Type | address_type | URN from values outlined in Table 33above | Y |
| Formatted | formatted | string | N |
| Street Address | street_address | string | Y |
| Locality | locality | string | Y |
| Region | region | string | Y |
| Post Code | post_code | string | Y |
| Country | country | string | N |
| Validated | validated | Boolean | Y |
The Other Email Address Object is a JSON Object that is intended to be used for the self-asserted other email address scope and claim.
The data types for the fields of the Other Email Address JSON Object, outlined in section 2.3.3 of this Schedule, are presented in Table 51 below.
Table 51 Other Email Address type field definitions
| Attribute | Field name | Data type | Required |
|---|---|---|---|
| Y | |||
| Email Validated | email_validated | Boolean | Y |
| Contact Type | contact_type | URN from the values prescribed in Table 35 above | Y |
The Other Phone Number Type is a JSON Object that is intended to be sued for the self-asserted other phone numbers scope and claim.
The data types for the fields Other Phone Number JSON Object, outlined in section 2.3.4 of this Schedule, are presented in Table 52 below.
Table 52 Other Phone Number type field definitions
| Attribute | Field name | Data type | Required |
|---|---|---|---|
| Other Phone | other_phone | Phone | Y |
| Other Phone Validated | other_phone_validated | Boolean | Y |
| Other Phone Telephony Type | telephony_type | URN from the values prescribed in Table 34 above | Y |
| Contact Type | contact_type | URN from the values prescribed in Table 35 above | Y |
Each of the Core Attributes are assigned a simple data type (see Table 46 above). Additional requirements for the Core Attribute data representation are outlined in Table 53 below. Normative examples are available in section 4.8 of this Schedule.
Table 53 Core claim requirements
| Claim | AGDIS data type | Requirements |
|---|---|---|
| name | RequiredNameString | Value MUST be a concatenation of given_name, middle_name and family_name.The joining character SHOULD be a space. |
| family_name | RequiredNameString | MUST NOT be an empty string. |
| given_name | NameString | MAY be excluded from attribute responses when value is an empty string. |
| middle_name | NameString | MAY be excluded from attribute responses when value is an empty string. |
| birthdate | Date | SHOULD be validated to ensure dates that satisfying the RFC 3339 format and are reasonable. |
| updated_at | Unix Timestamp | MUST be derived from the most recently updated Core Attribute. |
| tdif_core_updated_at | Unix Timestamp | IXPs MUST NOT broker this claim to PRPs.ISPs MUST supply this claim. |
As outlined in section 2.1.2 of this Schedule the Validated Contact attributes cover the individual’s validated email and phone. The data types applied to the claims in the attribute response MUST conform to the values outlined in Table 46 above.
All claims MUST be returned when fulfilling the email and phone scopes.
An ISP MUST not fulfill this request if the related email or phone number have not been validated.
Table 54 Requirements for Validated Email claims
| Claim | AGDISdata type | Required for scope | Constraints |
|---|---|---|---|
| Y | |||
| email_verified | Boolean | Y | If the email has not been successfully validated the scope for these claims should not be fulfilled. |
| tdif_email_updated_at | Unix Timestamp | Y |
Table 55 Requirements for Validated Phone Number claims
| Claim | AGDISdata type | Required for scope | Constraints |
|---|---|---|---|
| phone | Phone Number | Y | |
| phone_verified | Boolean | Y | If the phone number has not been validated successfully the scope for these claims should not be fulfilled. |
| tdif_phone_number_updated_at | Unix Timestamp | Y |
The Verified Other Names scope and claim uses the Other Names object for each of the verified other names returned in an attribute request.
An ISP fulfilling this request MAY return a single Other Name object or a JSON array containing the single value when only one Verified Other Name set is available.
An ISP fulfilling this request MUST return a JSON array of Other Name object when two or more Other Verified Names are available.
A Verified Document MUST be represented as a JSON Object with a structure conformant to the schema outlined in Table 10 above with the literal field names and data types outlined in Table 58 below.
The responses to an attribute request for a single verified document MAY be serialised as a single Verified Document Object or as wrapped in a JSON Array.
An attribute response for multiple verified documents MUST be serialised as a JSON Array of Verified Document Objects.
An ISP MUST apply the rules outlined in Table 10 above when preparing an attribute response if the attribute request for verified documents comes via the scope parameter.
Using the claims request parameter an attribute request for one or more specific documents can be made, using the document type code URNs outlined in Table 11 above. An example request is illustrated below in Figure 1.
The Document Identifiers field of a Verified Document Object is a JSON Object with keys and values determined by the parent objects document type.
The document type, held in the type_code claim, is mapped to an enumeration of permitted values in Table 58 below. The mapping does not imply the required the presence of a document identifier, for the specified verified document type, for the payload to be valid. For a given document type, the availability of document identifiers is dependent upon an identity document’s issuing authority and when it was issued.
For a Document Identifiers Object to be valid it MUST:
(a) only have keys that map to the parent object’s Document Type field; and
(b) be compliant with value data types prescribed in Table 58 below for a given identifier.
Table 58 Verified Document Identifiers with data types
| Document identifier string | Value data type | Value requirements | Used by document types |
|---|---|---|---|
| Registration Number | string | Maximum length 10 characters.Only available for ACT, NT, NSW, TAS, VIC, and WA. | BC, MC, NC |
| Registration Date | Date | - | BC, MC, NC |
| Registration Year | Number | Integer value for the year. | BC, MC, NC |
The Document Names Object field of a Verified Document Object is a JSON Object with keys and values determined by the parent objects document type.
The document type, held in the type_code claim, is mapped to an enumeration of permitted values in Table 58 above. The mapping does not imply the presence of a document name attribute is required
The Document Attributes field of a Verified Document Object is a JSON Object with keys and values determined by the parent objects document type.
The document type, held in the type_code claim, is mapped to an enumeration of permitted values in Table 60 below. The mapping does not imply the required presence of a document attribute, for the specified verified document type, for the payload to be valid. For a given document type, the availability of document attributes is dependent upon an identity document’s issuing authority and when it was issued.
For a Document Identifiers Object to be valid it MUST:
only comprise keys that map to the parent object’s Document Type field; and
have values that are compliant with data types prescribed in Table 60 below for a given identifier.
Table 60 Verified Document Attributes with data types
| Document attribute string | Value data type | Value requirements | Used by document types |
|---|---|---|---|
| Registration State | string | An up to 3 letter abbreviation of the registration state name.See Table 13 above for accepted values. | BC, MC, NC |
| Date of Event | Date | DVS valid dates are between 1753-01-01 to 3000-12-31. | MC |
| Acquisition Date | Date | DVS valid dates are between 1753-01-01 to 3000-12-31. | CC, RDDVS request input field but is not checked. |
OpenID Connect Core 1.0 data representation for the common attribute sets defined in section 2.2.1 of this Schedule.
Table 61 Common attributes definition
| Claim | AGDIS Data Type | Constraints |
|---|---|---|
| sub | string | Maximum length 255 characters. |
| auth_time | Unix Timestamp | - |
| acr | URNorArray of URNs | See section 2.2.1.3, section 4.4.1.3 of this Schedule. |
| amr | URN | Must be one of the values outlined in Table 30 above. |
| updated_at | Unix Timestamp | - |
Commonly referred to as the subject identifier or subject ID the sub claim’s data definition is outlined in OpenID Connect attribute found in Table 47 above.
ISPs and IXPs assigned subject IDs MUST be conform to the requirements outlined in section 1.2 of Schedule 1 (AGDIS Onboarding Specifications).
An ISP MUST implement support for authentication time, the auth_time claim, as outlined in Table 47 above.
When making, brokering, or fulfilling request for an Assurance Level, in compliance with the role specific requirements outlined in Schedule 2 (AGIDS OpenID Connect Profile), all entities
OpenID Connect Core 1.0 data representation for the common attribute sets defined in section 2.2.1 of this Schedule.
Table 61 Common attributes definition
| Claim | AGDIS Data Type | Constraints |
|---|---|---|
| sub | string | Maximum length 255 characters. |
| auth_time | Unix Timestamp | - |
| acr | URNorArray of URNs | See section 2.2.1.3, section 4.4.1.3 of this Schedule. |
| amr | URN | Must be one of the values outlined in Table 30 above. |
| updated_at | Unix Timestamp | - |
Commonly referred to as the subject identifier or subject ID the sub claim’s data definition is outlined in OpenID Connect attribute found in Table 47 above.
ISPs and IXPs assigned subject IDs MUST be conform to the requirements outlined in section 1.2 of Schedule 1 (AGDIS Onboarding Specifications).
An ISP MUST implement support for authentication time, the auth_time claim, as outlined in Table 47 above.
When making, brokering, or fulfilling request for an Assurance Level, in compliance with the role specific requirements outlined in Schedule 2 (AGIDS OpenID Connect Profile), all entities
When fulfilling the Authentication Method claim an IXP MUST use URN values conformant with the values outlined in Table 30 above to communicate the ISP chosen and authenticated at by the individual.
The addition of other values Internet Assigned Numbers Authority registered in line with the specification for the Authentication Method Reference response are permitted.
An ISP MUST implement support for this claim as outlined in Table 44 above using a Unix Timestamp.
The claim outlined in this section is for the RP Audit ID only.
Audit and transaction identifiers for the ISP to IXP transactions are left to the discretion of IXPs and accordingly not defined here.
Table 62 Audit attribute definitions
| Claim | AGDISdata type | Constraints |
|---|---|---|
| tdif_audit_id | UUID | - |
An IXP MUST implement RP Audit ID, the tdif_audit_id claim, as outlined in section 2.2.2.1 of this Schedule.
Assumed Self-Asserted Attributes are not mandatory under this profile, however if an ISP supports these attributes, they MUST implement the definitions outlined in Table 63 below to ensure interoperability.
The Preferred Name follows the same data definitions for name claims in the Core Attribute set. If fulfilled it MUST be a non-empty string with a maximum length of 100 characters.
The Address claim MAY represent one or more Address Objects.
The Other Email Addresses scope MUST only return the default email address nominated by the individual.
The Other Email Address claim MAY represent one or more Other Email Address Objects.
A request for a single other email address MAY be returned as a single Other Email Address object or as a JSON Array containing a single entry.
A request for one or more other email addresses MUST be returned as a JSON array of Other Email Address Objects.
An attribute requests for multiple or a specific other email address type can be done via the claim requests parameter using the Contact Type URNs defined in Table 36 above. An example request is illustrated in Figure 3.
A request MAY include the default contact type along with other contact type URNs.
{
…,
“userinfo”: {
…,
“agdis_address”: {
“values”: [
“urn:id.gov.au:agdis:address:default”,
“urn:id.gov.au:agdis:address:residential”
]
},
…
},
…
}
Figure 2 Self-asserted address sample claim request
The Other Phone Numbers scope request MUST only return the default other phone number nominated by the individual.
The Other Phone Numbers claim MAY represent one or more Other Phone Number Objects.
A request for a single other phone number MAY be returned as a single Other Phone Number object or as a JSON Array containing the object as its single entry.
A request for one or more other phone numbers MUST be returned as a JSON array of Other Phone Number Objects.
An attribute requests for multiple or a specific other phone number types can be done via the claim requests parameter using the Telephony (Table 34) or Contact Type (Table 35) URNs. An example request is illustrated in Figure 3.
Place of Birth MUST be a non-empty string with a maximum length of 255 characters.
A personal title MUST be a non-empty string with a maximum length of 100 characters.
Presently no Computed Attributes are defined in this Schedule.
The OpenID Connect attribute for AGDIS ASP is presented in this section.
The Business Authorisations attribute set mapping in Table 64 below maps the field names defined in section 3.1 of this Schedule to concrete payload names with type definitions.
As the ASP providing these attributes RAM SHOULD provide guidance to PRPs consuming these attributes to support use.
Table 64 Business Authorisation data representation
| Field | OIDC payload field name | Data type | Constraints |
|---|---|---|---|
| Schemas | schemas | Arry of URNs | MUST contain a URN that maps to the schema version follow the format defined in Table 39 above. |
| Unique Entity Relationship ID | id | string | A unique value as a non-empty string with a format defined by RAM, and a maximum length of 256 characters. |
| Entity ID | subjectId | string | A JSON string that MUST adhere the lengths constraints of the entity type. |
| Entity Type | subjectIdType | string | A value from the enumeration defied in Table 41 above. |
Detailed definition of the data representation for the myGov linkID is not defined in this Schedule.
An IXP or a PRP seeking further information on the format of this attribute SHOULD consult the myGov member service documentation.
Sourced from the Federal Register of Legislation (legislation.gov.au), CC BY 4.0.
This Chapter outlines the role requirements, where applicable, that MUST be met by ASPs, ISPs and IXPs.
ASPs, ISPs and IXPs:
MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and
SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.
This Chapter outlines the role requirements, where applicable, that MUST be met by ASPs, ISPs and IXPs.
ASPs, ISPs and IXPs:
MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and
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.
Requires auditability and an RP Audit ID. IXPs must generate an RP Audit ID (UUID) for every logical interaction with a relying party (PRP) and must include it in transactions with PRPs and any ASPs used to fulfil requests, but must not share that RP Audit ID with ISPs. ASPs must log consent and the RP Audit ID when used. (See: Audit requirements §2.1.2 and attribute/audit rules in Schedule 3 §2.2.2.1; ASP audit logging §4.2.)
Requires user control surfaces. IXPs must offer a user dashboard that shows an individual's consumer history, express consent records, and ISP preferences; dashboards must respect the level of assurance of the current session. IXPs must obtain express consent before redirecting the user back to a requesting PRP. (See: §2.3; §1.10.)
Provides detailed attribute schemas and normative examples for dozens of attributes and verified document types (birth certificate, driver licence, passport, Medicare card, visa, business authorisations, etc.). Schedules specify exact JSON claim names, data types, field constraints and when attributes are restricted or require explicit consent. (See: Schedule 3 Chapters 2 and 4.)
Who this affects (practical population)
Why it matters (practical consequences and behaviour changes)
Interoperability and uniformity: By prescribing an OpenID Connect profile and a single attribute/claim mapping, the standard reduces ambiguity about how attributes are requested, represented and returned (Schedules 2 & 3). Implementers must conform to those formats.
Shift of operational responsibility: IXPs are defined as central brokers — they control protocol brokering, user selection of ISPs, user dashboards and a large part of consent capture and logging (see §2.1, §2.2, §2.3). That changes who implements the user experience and who holds operational audit records.
Compliance and technical burden: Participants must implement strict cryptographic key management (jwks/jwks_uri, client keys, private_key_jwt), short token lifetimes, per-client access controls, schema validation and extensive audit logging. These carry implementation, operational and security costs (see §1.5.1; §1.8.3; Schedule 3 §§4.2–4.3).
Privacy and access control mechanics: Attribute sharing is governed by explicit policies (consent types, fulfilment rules, access policies). Some attributes are restricted or platform-limited (for example, myGov linkID and RAM-managed business authorisations). Those controls will affect which PRPs can access which data and under what consent model (see Schedule 3 §§1.2, 3.1–3.2).
Analytical lens — incentives, costs, trade-offs, and operational risks
Who pays: technical implementers (government agencies or vendors) bear upfront engineering costs (protocol conformance, key management, schema support, audit logging), ongoing operational costs (key rotation, logs, dashboards) and compliance costs (privacy and access controls). The instrument requires explicit implementation steps (see client key registration §1.5.1; audit logging §§2.1.2, 2.6.1, 2.7.1; attribute schemas Schedule 3 Chapter 4).
Who decides: IXPs exercise discretionary choices that materially affect user experience and privacy (how ISP choices are presented, whether to remember ISP selections, when to re‑authenticate, SSO behaviours), subject to notice and revocation mechanics required by the standard (§2.2; §2.2 Identity provider selection; §2.1.6–2.1.7). ISPs decide whether to support dynamic registration (ISPs must not support dynamic registration of IXPs — §2.2) and what levels of assurance they can deliver.
Behaviour changes forced by the rules: implementers must avoid some insecure legacy flows (no resource‑owner‑password grants), must use specific client authentication (private_key_jwt) and must not return empty/null attribute values unless a policy explicitly allows it. These rules narrow developer choices and require stronger server-side controls (§1.1; §1.6; §1.7.2; Schedule 3 §1.3.1).
Concentration of responsibility and substitution effects: centralised responsibilities for consent capture, dashboarding and brokering sit with IXPs; that centralisation simplifies some interoperability tasks but concentrates risk and operational burden. The rules also create mutual exclusivities (e.g., if an ISP issues pairwise identifiers it MUST NOT issue a GPI, §1.2.2) that influence an ISP’s choices and downstream mapping.
Rent-seeking / capture risk: the instrument gives IXPs technical levers (brokerage, protocol translation, attribute brokering and dashboards). Those levers create an incentive for IXPs to become dominant hubs; the standard itself does not set economic terms for participation, so contractual and accreditation rules outside the data standard will determine market dynamics (see role definitions across Schedule 1 and Schedule 2).
Implementation risk and brittle dependencies: the standard requires reliable jwks_uri reachability, accurate clock synchronisation (allowed clock skew is limited), and strict redirect URI matching. Failures in these operational pieces (DNS, key hosting, clock drift) will cause authentication failures. Token and ID lifetimes are short (ID tokens ≤ 300 seconds), increasing reliance on robust token exchange and clock alignment (§1.5.1; §1.8.1.2; §1.8.3.1).
Compliance burden from attribute detail: Schedule 3 contains many concrete schemas and validation constraints for verified documents and identifiers (birth certificates, driver licences, etc.). Conforming to those detailed schemas and maintaining updates is a non-trivial software and data management cost (Schedule 3 Chapters 2 and 4).
Selected concrete citations (where key obligations appear)
Bottom-line summary in one short paragraph
This instrument is a detailed technical and data standard that locks the Australian Government Digital ID ecosystem to an AGDIS-specific OpenID Connect profile, prescribes identifier semantics, consent and attribute-sharing policies, audit requirements, short token lifetimes, and precise JSON schemas for many verified attributes. It therefore creates clear interoperability rules but imposes non-trivial engineering, operational and compliance costs on IXPs, ISPs and ASPs, while concentrating brokering and consent responsibilities with IXPs (see Schedules 1–3).
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.
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).
This Chapter outlines the requirements that MUST be met by IXPs.
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.
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.
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.
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:
a notice to ensure the individual understands the nature of the express consent they are providing;
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
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.
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:
view their consumer history;
manage the express consent they have given; and
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.
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:
view their consumer history;
manage the express consent they have given; and
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).
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
This is an opening excerpt, not the complete document.