{"id":"F2024L01443","name":"Digital ID (AGDIS) Data Standards 2024","slug":"digital-id-agdis-data-standards-2024","collection":"legislative_instrument","jurisdiction":"commonwealth","status":"in_force","isInForce":true,"actNumber":null,"makingDate":null,"administeringDepartment":null,"currentVersion":{"id":105440,"registerId":"commonwealth-F2024L01443-current","compilationNumber":null,"startDate":"2026-04-03","status":"InForce","reasons":null,"registeredAt":null},"sections":[{"sectionNumber":"1. Common requirements for participating","sectionType":"part","heading":"1. Common requirements for participating accredited entities","content":"# 1. Common requirements for participating accredited entities\n\nThis Chapter outlines the role requirements, where applicable, that MUST be met by ASPs, ISPs and IXPs.","sortOrder":0},{"sectionNumber":"1.1","sectionType":"part","heading":"Security considerations","content":"## 1.1 Security considerations\n\nASPs, ISPs and IXPs:\n\n MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and\n SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.","sortOrder":1},{"sectionNumber":"1.2","sectionType":"part","heading":"Identity resolution","content":"# 1. Common requirements for participating accredited entities\n\nThis Chapter outlines the role requirements, where applicable, that MUST be met by ASPs, ISPs and IXPs.\n\n## 1.1 Security considerations\n\nASPs, ISPs and IXPs:\n\n MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and\n SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.\n\n## 1.2 Identity resolution\n\n### 1.2.1 General purposes identifiers\n\nAn IXP MUST NOT issue a GPI.\n\nAn ISP MAY issue a GPI. Where an ISP chooses to issue a GPI, the ISP MUST:\n\n (a) bind the GPI to only a single digital ID account;\n (b) only use the GPI within the AGDIS;\n (c) only use the GPI to map the individual’s digital ID to a single IXP; and\n (d) issue additional GPIs for each IXP an individual accesses.\n\nA GPI MUST be unique within the DI data environment of the ISP that issues it.\n\n### 1.2.2 Pairwise identifiers\n\nAn IXP MUST issue a pairwise identifier.\n\nAn ISP SHOULD issue a pairwise identifier. If an ISP issues a pairwise identifier, the ISP MUST NOT issue a GPI.\n\nIXPs 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.\n\n### 1.2.3 Sector Identifiers\n\nIXPs and ISPs SHOULD use sector identifiers.\n\nThe 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.","sortOrder":2},{"sectionNumber":"1.2.1 General purposes identifiers","sectionType":"division","heading":"1.2.1 General purposes identifiers","content":"### 1.2.1 General purposes identifiers\n\nAn IXP MUST NOT issue a GPI.\n\nAn ISP MAY issue a GPI. Where an ISP chooses to issue a GPI, the ISP MUST:\n\n (a) bind the GPI to only a single digital ID account;\n (b) only use the GPI within the AGDIS;\n (c) only use the GPI to map the individual’s digital ID to a single IXP; and\n (d) issue additional GPIs for each IXP an individual accesses.\n\nA GPI MUST be unique within the DI data environment of the ISP that issues it.","sortOrder":3},{"sectionNumber":"1.2.2 Pairwise identifiers","sectionType":"division","heading":"1.2.2 Pairwise identifiers","content":"### 1.2.2 Pairwise identifiers\n\nAn IXP MUST issue a pairwise identifier.\n\nAn ISP SHOULD issue a pairwise identifier. If an ISP issues a pairwise identifier, the ISP MUST NOT issue a GPI.\n\nIXPs 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.","sortOrder":4},{"sectionNumber":"1.2.3 Sector Identifiers","sectionType":"division","heading":"1.2.3 Sector Identifiers","content":"### 1.2.3 Sector Identifiers\n\nIXPs and ISPs SHOULD use sector identifiers.\n\nThe 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.","sortOrder":5},{"sectionNumber":"1.3","sectionType":"part","heading":"Data sharing","content":"## 1.3 Data sharing\n\nIrrespective 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).","sortOrder":6},{"sectionNumber":"1.3.1 Request processing","sectionType":"division","heading":"1.3.1 Request processing","content":"### 1.3.1 Request processing\n\nASPs, ISPs and IXPs MUST NOT attempt to fulfill requests for unknown attributes or attribute sets.\n\nRequests 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).","sortOrder":7},{"sectionNumber":"2. Identity exchange provider","sectionType":"part","heading":"2. Identity exchange provider","content":"# 2. Identity exchange provider\n\nThis Chapter outlines the requirements that MUST be met by IXPs.","sortOrder":8},{"sectionNumber":"2.1","sectionType":"part","heading":"Technical integration requirements","content":"# 2. Identity exchange provider\n\nThis Chapter outlines the requirements that MUST be met by IXPs.\n\n## 2.1 Technical integration requirements\n\n### 2.1.1 Protocol requirements\n\nAn IXP MUST implement Schedule 2 (AGDIS OpenID Connect Profile) for an:\n\n (a) IXP acting as an OIDC provider; and\n (b) IXP acting as TRP to an ISP.\n\n### 2.1.2 Audit requirements\n\nAn IXP MUST generate the RP Audit ID attribute as outlined in Schedule 3 (AGDIS Attribute Profile).\n\nThe 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).\n\nThe 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.\n\nThe IXP MUST NOT send the RP Audit ID attribute it generated for the PRP’s authentication request to its ISP.\n\n### 2.1.3 Levels of assurance\n\nLevels of assurance are used to define the IP level and AL of an individual’s authenticated session.\n\nLevels 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.\n\nNote the URNs in Table 1below MUST reference the legacy acronym cl (credential level) in their namespace to represent AL.\n\nA mapping of the new ALs to the legacy credential levels, used in the URNs outlined in Table 1, is provided below in Table 2.\n\nAn IXP MUST allow a PRP to request a minimum level of assurance when making authentication requests.","sortOrder":9},{"sectionNumber":"2.1.1 Protocol requirements","sectionType":"division","heading":"2.1.1 Protocol requirements","content":"### 2.1.1 Protocol requirements\n\nAn IXP MUST implement Schedule 2 (AGDIS OpenID Connect Profile) for an:\n\n (a) IXP acting as an OIDC provider; and\n (b) IXP acting as TRP to an ISP.","sortOrder":10},{"sectionNumber":"2.1.2 Audit requirements","sectionType":"division","heading":"2.1.2 Audit requirements","content":"### 2.1.2 Audit requirements\n\nAn IXP MUST generate the RP Audit ID attribute as outlined in Schedule 3 (AGDIS Attribute Profile).\n\nThe 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).\n\nThe 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.\n\nThe IXP MUST NOT send the RP Audit ID attribute it generated for the PRP’s authentication request to its ISP.","sortOrder":11},{"sectionNumber":"2.1.3 Levels of assurance","sectionType":"division","heading":"2.1.3 Levels of assurance","content":"### 2.1.3 Levels of assurance\n\nLevels of assurance are used to define the IP level and AL of an individual’s authenticated session.\n\nLevels 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.\n\nNote the URNs in Table 1below MUST reference the legacy acronym cl (credential level) in their namespace to represent AL.\n\nA mapping of the new ALs to the legacy credential levels, used in the URNs outlined in Table 1, is provided below in Table 2.\n\nAn IXP MUST allow a PRP to request a minimum level of assurance when making authentication requests.","sortOrder":12},{"sectionNumber":"2.1.4 Identity resolution","sectionType":"division","heading":"2.1.4 Identity resolution","content":"### 2.1.4 Identity resolution\n\nAn IXP MUST generate pairwise identifiers as required in section 1.2.2 of this Schedule.\n\nIf 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.\n\nIf an IXP makes use of sector identifiers:\n\n (a) the pairwise identifiers MUST only have a one-to-one mapping with a sector identifier; and\n (b) a sector identifier MUST only map to a single PRP, regardless of the number of connected services.\n\nPairwise identifiers MUST be used when presenting individuals to PRPs irrespective of the federation protocols being brokered by the IXP in a transaction.","sortOrder":13},{"sectionNumber":"2.1.5 Authenticated sessions","sectionType":"division","heading":"2.1.5 Authenticated sessions","content":"### 2.1.5 Authenticated sessions\n\nAn authenticated session managed by the IXP MUST expire.\n\nFor each supported federation protocol, an IXP MUST provide PRPs with information regarding session expiration times.\n\nAn IXP MAY support features as specified in the relevant federation protocol to allow refreshing of an authenticated session before expiry.","sortOrder":14},{"sectionNumber":"2.1.6 Single sign on","sectionType":"division","heading":"2.1.6 Single sign on","content":"### 2.1.6 Single sign on\n\nAn IXP MAY support a SSO scheme.\n\nIf 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.\n\nAn 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.\n\nAn IXP MUST ensure their implementation of SSO does not result in the disclosure of attributes including restricted attributes of an individual.","sortOrder":15},{"sectionNumber":"2.1.7 Single logout","sectionType":"division","heading":"2.1.7 Single logout","content":"### 2.1.7 Single logout\n\nIf an IXP supports SSO, the IXP MUST implement SLO.\n\nThe IXP MUST ensure their implementation of SLO does not result in the disclosure of attributes including restricted attributes of an individual.","sortOrder":16},{"sectionNumber":"2.1.8 Attribute service provider integra","sectionType":"division","heading":"2.1.8 Attribute service provider integration","content":"### 2.1.8 Attribute service provider integration\n\nWhen 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.","sortOrder":17},{"sectionNumber":"2.1.9 Federation protocol brokering","sectionType":"division","heading":"2.1.9 Federation protocol brokering","content":"### 2.1.9 Federation protocol brokering\n\nWhen 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.","sortOrder":18},{"sectionNumber":"2.2","sectionType":"part","heading":"Identity provider selection","content":"## 2.2 Identity provider selection\n\nAn IXP MUST provide a mechanism for the individual to choose an ISP.\n\nThe 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.\n\nAn IXP MAY provide a mechanism for the individual to remember their choice of ISP for a given PRP.\n\nIf an individual has remembered their ISP choice for a given PRP, an IXP MAY redirect them to the remembered ISP.\n\nIf an IXP provides a mechanism to remember ISP selection, the IXP MUST provide:\n\n a notice to ensure the individual understands the nature of the express consent they are providing;\n 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\n a mechanism to revoke the remembered choice.","sortOrder":19},{"sectionNumber":"2.2.1 Blinding","sectionType":"division","heading":"2.2.1 Blinding","content":"### 2.2.1 Blinding\n\nAn IXP MUST NOT broker any information about the PRP requesting authentication to any of its ISPs.\n\nAn IXP MAY inform the PRP which ISP the individual used to authenticate.","sortOrder":20},{"sectionNumber":"2.3","sectionType":"part","heading":"User dashboard","content":"## 2.3 User dashboard\n\nAn IXP MUST provide a user dashboard that allows an individual, for the digital ID used to create the individual’s current authenticated session, to:\n\n view their consumer history;\n manage the express consent they have given; and\n manage their ISP preferences.\n\nThe user dashboard MUST only display information for services at or below the level of assurance for the current authenticated session.\n\nWhen a user dashboard is accessed, an IXP MAY re-authenticate the individual, even if the individual already has a current authenticated session.","sortOrder":21},{"sectionNumber":"2.4","sectionType":"part","heading":"Data requirements","content":"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.\n\n## 2.3 User dashboard\n\nAn IXP MUST provide a user dashboard that allows an individual, for the digital ID used to create the individual’s current authenticated session, to:\n\n view their consumer history;\n manage the express consent they have given; and\n manage their ISP preferences.\n\nThe user dashboard MUST only display information for services at or below the level of assurance for the current authenticated session.\n\nWhen a user dashboard is accessed, an IXP MAY re-authenticate the individual, even if the individual already has a current authenticated session.\n\n## 2.4 Data requirements\n\n### 2.4.1 Attribute requirements\n\nAn IXP MUST support brokering all attributes as outlined in Schedule 3 (AGDIS Attribute Profile).\n\nAn IXP MUST support the disclosure of all IXP managed or generated attributes as outlined in Schedule 3 (AGDIS Attribute Profile).\n\nAn IXP MUST support requesting any ISP specific attributes outlined in Schedule 3 (AGDIS Attribute Profile) in an authentication request to an ISP.\n\n### 2.4.2 Computed attributes\n\nFor each of their supported federation protocols, an IXP MUST implement the following requirements in this section.\n\nAn IXP MUST support the disclosure of computed attributes as described in Schedule 3 (AGDIS Attribute Profile).\n\nAn IXP MAY source computed attributes from an ISP or an ASP.\n\nAn IXP MAY define support for additional computed attributes derived from attributes available from its ISPs and ASPs.\n\nAny new computed attribute MUST NOT violate attribute sharing policies defined in Schedule 3 (AGDIS Attribute Profile).\n\n### 2.4.3 Attribute sharing policy\n\nThe 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).","sortOrder":22},{"sectionNumber":"2.4.1 Attribute requirements","sectionType":"division","heading":"2.4.1 Attribute requirements","content":"### 2.4.1 Attribute requirements\n\nAn IXP MUST support brokering all attributes as outlined in Schedule 3 (AGDIS Attribute Profile).\n\nAn IXP MUST support the disclosure of all IXP managed or generated attributes as outlined in Schedule 3 (AGDIS Attribute Profile).\n\nAn IXP MUST support requesting any ISP specific attributes outlined in Schedule 3 (AGDIS Attribute Profile) in an authentication request to an ISP.","sortOrder":23},{"sectionNumber":"2.4.2 Computed attributes","sectionType":"division","heading":"2.4.2 Computed attributes","content":"### 2.4.2 Computed attributes\n\nFor each of their supported federation protocols, an IXP MUST implement the following requirements in this section.\n\nAn IXP MUST support the disclosure of computed attributes as described in Schedule 3 (AGDIS Attribute Profile).\n\nAn IXP MAY source computed attributes from an ISP or an ASP.\n\nAn IXP MAY define support for additional computed attributes derived from attributes available from its ISPs and ASPs.\n\nAny new computed attribute MUST NOT violate attribute sharing policies defined in Schedule 3 (AGDIS Attribute Profile).","sortOrder":24},{"sectionNumber":"2.4.3 Attribute sharing policy","sectionType":"division","heading":"2.4.3 Attribute sharing policy","content":"### 2.4.3 Attribute sharing policy\n\nThe 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).","sortOrder":25},{"sectionNumber":"2.4.4 Data representation","sectionType":"division","heading":"2.4.4 Data representation","content":"### 2.4.4 Data representation\n\nWhen disclosing IXP specific attributes, an IXP MUST use the data representation as prescribed in Schedule 3 (AGDIS Attribute Profile).\n\nAn IXP MAY use the data representation, defined in Schedule 3 (AGDIS Attribute Profile), to validate attribute payloads received from ISPs and ASPs.\n\nAn IXP MUST NOT alter payloads received from an ISP or ASP unless the relevant attribute sharing polices explicitly permit alteration to occur.","sortOrder":26},{"sectionNumber":"3. Identity service provider","sectionType":"part","heading":"3. Identity service provider","content":"# 3. Identity service provider\n\nThis Chapter outlines the requirements that MUST be met by ISPs.","sortOrder":27},{"sectionNumber":"3.1","sectionType":"part","heading":"Technical integration requirements","content":"### 2.4.4 Data representation\n\nWhen disclosing IXP specific attributes, an IXP MUST use the data representation as prescribed in Schedule 3 (AGDIS Attribute Profile).\n\nAn IXP MAY use the data representation, defined in Schedule 3 (AGDIS Attribute Profile), to validate attribute payloads received from ISPs and ASPs.\n\nAn IXP MUST NOT alter payloads received from an ISP or ASP unless the relevant attribute sharing polices explicitly permit alteration to occur.\n\n# 3. Identity service provider\n\nThis Chapter outlines the requirements that MUST be met by ISPs.\n\n## 3.1 Technical integration requirements\n\n### 3.1.1 Protocol requirements\n\nAn ISP MUST implement the ISP requirements in Schedule 2 (AGDIS OpenID Connect Profile).\n\n### 3.1.2 Identity resolution\n\nAn ISP MAY generate GPIs as prescribed in section 1.2.1 of this Schedule.\n\nAn ISP SHOULD generate pairwise identifiers as prescribed in section 1.2.2 of this Schedule.\n\nAn 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.\n\n### 3.1.3 Single sign on\n\nAn ISP MAY support an SSO scheme operated by one or more of its connected IXPs.\n\nWhere 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.\n\nIf an ISP is unable to fulfill a request of SSO then it MUST re-authenticate the user.\n\n### 3.1.4 Single logout\n\nThe ISP MUST support the SLO scheme operated by its connected IXPs.\n\nThe ISP MUST support the SLO scheme (of its connected IXPs) regardless of whether the ISP has supported the SSO.","sortOrder":28},{"sectionNumber":"3.1.1 Protocol requirements","sectionType":"division","heading":"3.1.1 Protocol requirements","content":"### 3.1.1 Protocol requirements\n\nAn ISP MUST implement the ISP requirements in Schedule 2 (AGDIS OpenID Connect Profile).","sortOrder":29},{"sectionNumber":"3.1.2 Identity resolution","sectionType":"division","heading":"3.1.2 Identity resolution","content":"### 3.1.2 Identity resolution\n\nAn ISP MAY generate GPIs as prescribed in section 1.2.1 of this Schedule.\n\nAn ISP SHOULD generate pairwise identifiers as prescribed in section 1.2.2 of this Schedule.\n\nAn 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.","sortOrder":30},{"sectionNumber":"3.1.3 Single sign on","sectionType":"division","heading":"3.1.3 Single sign on","content":"### 3.1.3 Single sign on\n\nAn ISP MAY support an SSO scheme operated by one or more of its connected IXPs.\n\nWhere 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.\n\nIf an ISP is unable to fulfill a request of SSO then it MUST re-authenticate the user.","sortOrder":31},{"sectionNumber":"3.1.4 Single logout","sectionType":"division","heading":"3.1.4 Single logout","content":"### 3.1.4 Single logout\n\nThe ISP MUST support the SLO scheme operated by its connected IXPs.\n\nThe ISP MUST support the SLO scheme (of its connected IXPs) regardless of whether the ISP has supported the SSO.","sortOrder":32},{"sectionNumber":"3.2","sectionType":"part","heading":"Data requirements","content":"## 3.2 Data requirements\n\n### 3.2.1 Attribute requirements\n\nAn ISP MUST support the disclosure of attributes based on support and fulfilment requirements outlined in Schedule 3 (AGDIS Attribute Profile).\n\nFor each of their supported federation protocols, an ISP MUST implement the specific attribute profile and attribute mapping.\n\n### 3.2.2 Computed attributes\n\nAn ISP MUST support computed attributes as outlined in Schedule 3 (AGDIS Attribute Profile).\n\nAn 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).\n\n# 4. Attribute service provider\n\nThis Chapter outlines the requirements that MUST be met by ASPs.\n\n## 4.1 Technical integration requirements\n\n### 4.1.1 Protocol requirements\n\nAn ASP, in addition to these requirements, is subject to TRP requirements as outlined in section 1.7 of Schedule 2 (AGDIS OpenID Connect Profile).\n\nAn 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.\n\nThe ASP MUST implement the technical relying party profile for one of the federation protocols supported by the IXP it is connecting to.\n\nAt the time this instrument was made, the only technical relying party profile for the AGDIS is in Schedule 2 (AGDIS OpenID Connect Profile).\n\n### 4.1.2 Access channels\n\nAn access channel is any mechanism that allows ASP managed attributes to be provided either:\n\n (a) directly to a PRP; or\n (b) to a PRP via an IXP.\n\nExamples 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.\n\nAn ASP MAY make multiple access channels available for IXPs or PRPs to access the attributes they control.","sortOrder":33},{"sectionNumber":"3.2.1 Attribute requirements","sectionType":"division","heading":"3.2.1 Attribute requirements","content":"### 3.2.1 Attribute requirements\n\nAn ISP MUST support the disclosure of attributes based on support and fulfilment requirements outlined in Schedule 3 (AGDIS Attribute Profile).\n\nFor each of their supported federation protocols, an ISP MUST implement the specific attribute profile and attribute mapping.","sortOrder":34},{"sectionNumber":"3.2.2 Computed attributes","sectionType":"division","heading":"3.2.2 Computed attributes","content":"### 3.2.2 Computed attributes\n\nAn ISP MUST support computed attributes as outlined in Schedule 3 (AGDIS Attribute Profile).\n\nAn 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).","sortOrder":35},{"sectionNumber":"4. Attribute service provider","sectionType":"part","heading":"4. Attribute service provider","content":"# 4. Attribute service provider\n\nThis Chapter outlines the requirements that MUST be met by ASPs.","sortOrder":36},{"sectionNumber":"4.1","sectionType":"part","heading":"Technical integration requirements","content":"## 3.2 Data requirements\n\n### 3.2.1 Attribute requirements\n\nAn ISP MUST support the disclosure of attributes based on support and fulfilment requirements outlined in Schedule 3 (AGDIS Attribute Profile).\n\nFor each of their supported federation protocols, an ISP MUST implement the specific attribute profile and attribute mapping.\n\n### 3.2.2 Computed attributes\n\nAn ISP MUST support computed attributes as outlined in Schedule 3 (AGDIS Attribute Profile).\n\nAn 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).\n\n# 4. Attribute service provider\n\nThis Chapter outlines the requirements that MUST be met by ASPs.\n\n## 4.1 Technical integration requirements\n\n### 4.1.1 Protocol requirements\n\nAn ASP, in addition to these requirements, is subject to TRP requirements as outlined in section 1.7 of Schedule 2 (AGDIS OpenID Connect Profile).\n\nAn 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.\n\nThe ASP MUST implement the technical relying party profile for one of the federation protocols supported by the IXP it is connecting to.\n\nAt the time this instrument was made, the only technical relying party profile for the AGDIS is in Schedule 2 (AGDIS OpenID Connect Profile).\n\n### 4.1.2 Access channels\n\nAn access channel is any mechanism that allows ASP managed attributes to be provided either:\n\n (a) directly to a PRP; or\n (b) to a PRP via an IXP.\n\nExamples 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.\n\nAn ASP MAY make multiple access channels available for IXPs or PRPs to access the attributes they control.","sortOrder":37},{"sectionNumber":"4.1.1 Protocol requirements","sectionType":"division","heading":"4.1.1 Protocol requirements","content":"### 4.1.1 Protocol requirements\n\nAn ASP, in addition to these requirements, is subject to TRP requirements as outlined in section 1.7 of Schedule 2 (AGDIS OpenID Connect Profile).\n\nAn 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.\n\nThe ASP MUST implement the technical relying party profile for one of the federation protocols supported by the IXP it is connecting to.\n\nAt the time this instrument was made, the only technical relying party profile for the AGDIS is in Schedule 2 (AGDIS OpenID Connect Profile).","sortOrder":38},{"sectionNumber":"4.1.2 Access channels","sectionType":"division","heading":"4.1.2 Access channels","content":"### 4.1.2 Access channels\n\nAn access channel is any mechanism that allows ASP managed attributes to be provided either:\n\n (a) directly to a PRP; or\n (b) to a PRP via an IXP.\n\nExamples 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.\n\nAn ASP MAY make multiple access channels available for IXPs or PRPs to access the attributes they control.","sortOrder":39},{"sectionNumber":"4.2","sectionType":"part","heading":"Audit logging","content":"## 4.2 Audit logging\n\nAn ASP’s audit log MUST include any individual’s consent managed by the ASP that enables the sharing of attributes with PRPs.\n\nAn ASP’s audit log MUST include the value of the RP Audit ID supplied by the IXP:\n\n when binding a digital ID brokered by the IXP to any of the attributes managed by the ASP;\n if the IXP directly retrieves the attributes; and\n if the ASP provides attributes indirectly and the RP Audit ID is available.","sortOrder":40},{"sectionNumber":"4.3","sectionType":"part","heading":"Attribute schema","content":"## 4.3 Attribute schema\n\nAn ASP MUST publish an attribute schema for any attributes it provides.\n\nThe 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.\n\nA published attribute schema MUST outline data types and constraints for the fields that comprise the attribute sets managed by the ASP.\n\nThe published attribute schema MUST support a data format compatible with the federation protocol the ASP uses to connect to the IXP.\n\nAn ASP MUST establish procedures to publish updates to their attribute schema in accordance with Schedule 3 (AGDIS Attribute Profile).","sortOrder":41},{"sectionNumber":"List of Figures","sectionType":"part","heading":"List of Figures","content":"# List of Figures\n\nFigure 1 JSON WEB Key Set example...........................................4\n\nFigure 2 Example authorisation request..........................................7\n\nFigure 3 Sample Token Endpoint HTTP POST request..............................8\n\nFigure 4 Client authentication JWT example.....................................11\n\nFigure 5 Normative example of the well-known configuration........................14\n\nFigure 6 Requesting authentication assurance level with claims......................17\n\nFigure 7 Token Endpoint private JWT example...................................22\n\nFigure 8 UserInfo endpoint example request.....................................23\n\nFigure 9 Sample ID Token signature............................................29\n\nFigure 10 Claims used to the generate the prior signature...........................29\n\nFigure 11 Sample assurance level requests using claims...........................31","sortOrder":42},{"sectionNumber":"1. Identity exchange","sectionType":"part","heading":"1. Identity exchange","content":"# 1. Identity exchange\n\nThis 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.\n\nInteroperability between IXPs is not within scope for this release of the Digital ID (AGDIS) Data Standards 2024.","sortOrder":43},{"sectionNumber":"1.2.1 Full Client with User Delegation","sectionType":"division","heading":"1.2.1 Full Client with User Delegation","content":"### 1.2.1 Full Client with User Delegation\n\nAn IXP MUST support the Full Client with User Delegation client type.\n\nThis 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.\n\nAll 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.\n\nAn 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.\n\nAn IXP MUST associate the clients with a unique public key as described in section 1.5.1 of this Schedule.\n\nAn IXP MAY issue this client type a refresh token if the security parameters of the access request allow for it.","sortOrder":46},{"sectionNumber":"1.2.2 Native Client with User Delegation","sectionType":"division","heading":"1.2.2 Native Client with User Delegation","content":"### 1.2.2 Native Client with User Delegation\n\nA 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.\n\nAn IXP MAY support Native Clients with User Delegation.","sortOrder":47},{"sectionNumber":"1.2.3 Direct Access Client","sectionType":"division","heading":"1.2.3 Direct Access Client","content":"### 1.2.3 Direct Access Client\n\nA 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.\n\nAn IXP MAY only implement this client type to support interactions between itself and other entities participating in the AGDIS.\n\nIf an IXP supports the Direct Access Client type, the IXP MUST support the confidential client type and the client\\_credentials grant types.","sortOrder":48},{"sectionNumber":"1.4","sectionType":"part","heading":"Redirect URI","content":"## 1.4 Redirect URI\n\nAn IXP’s clients that use the authorisation code grant type MUST register its full redirect URIs.\n\nAn IXP MUST as the authorisation server validate the redirect URI given by the client at the Authorisation Endpoint using strict string comparison.\n\nAn IXP MUST ensure that the redirect URI used by a client is one of the following:\n\n hosted on a website with TLS protection (HTTPS);\n hosted on a local domain of the client (for example: [http://localhost/](http://localhost/)); or\n hosted on a client specific non-remote protocol URI scheme (for example: myapp:// or au.gov.app://).\n\nIf 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.\n\nAn 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.","sortOrder":50},{"sectionNumber":"1.4.1 Native Client Applications","sectionType":"division","heading":"1.4.1 Native Client Applications","content":"### 1.4.1 Native Client Applications\n\nThe use of client specific non-remote protocol URI schemes SHOULD be phased out for native application.\n\nAn IXP MAY allow existing native application clients to continue using non-remote protocol URI schemes in their redirect URI.\n\nWhen 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.","sortOrder":51},{"sectionNumber":"1.5","sectionType":"part","heading":"Connection to the authorisation server","content":"## 1.5 Connection to the authorisation server\n\n### 1.5.1 Client keys\n\nAn 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.\n\nAn 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.\n\nIf a client registers a jwks\\_uri, the IXP MUST require the URI to be reachable by the authorisation server.\n\nAn IXP SHOULD require the use of a jwks\\_uri as it allows for easier key rotation.\n\nAn 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.\n\nAs the authorisation server, a IXP MUST verify the content available from a client’s registered\n\njwks\\_uri contains a valid JSON Web Key Set. The example below is of a 2048-bit RSA key.\n\n{\n\n\"keys\": \\[{ \n\"alg\": \"RS256\",\n\n\"e\": \"AQAB\",\n\n\"n\": \"kAMYD62n\\_f2rUcR4awJX4uccDt0zcXRssq\\_mDch5aifcShx9aTtTVza23PTn3KaKrsBXwWcfioXR6zQn5eYdZQVGNBfOR4rxF5i7t3hfb4WkS50EK1gBYk2lO9NSrQzxG9QsUsAnN6RHksXqsdOqvnxjLexDfIJlgbcCN9h6TBC66ZXv7PVhl19gIYVifSU7liHkLe0l0fw7jUI6rHLHf4d96\\_neR1HrNIK\\_xssr99Xpv1EM\\_ubxpktX0T925qej9fMEpzzQ5HLmcNt1H2\\_VQ\\_Ww1JOLn9vRnH48FDj7TxlIT74XdTZgTv31w\\_GRPAOfyxEw\\_ZUmxhz5ZngTlQ\",\n\n\"kty\": \"RSA\",\n\n\"kid\": \"oauth-client\"\n\n}\\]\n\n}\n\nFigure 1 JSON WEB Key Set example\n\nAn IXP MAY allow native client applications to omit their key during registration if they are a Public Client using PKCE.","sortOrder":52},{"sectionNumber":"1.5.1 Client keys","sectionType":"division","heading":"1.5.1 Client keys","content":"### 1.5.1 Client keys\n\nAn 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.\n\nAn 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.\n\nIf a client registers a jwks\\_uri, the IXP MUST require the URI to be reachable by the authorisation server.\n\nAn IXP SHOULD require the use of a jwks\\_uri as it allows for easier key rotation.\n\nAn 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.\n\nAs the authorisation server, a IXP MUST verify the content available from a client’s registered\n\njwks\\_uri contains a valid JSON Web Key Set. The example below is of a 2048-bit RSA key.\n\n{\n\n\"keys\": \\[{ \n\"alg\": \"RS256\",\n\n\"e\": \"AQAB\",\n\n\"n\": \"kAMYD62n\\_f2rUcR4awJX4uccDt0zcXRssq\\_mDch5aifcShx9aTtTVza23PTn3KaKrsBXwWcfioXR6zQn5eYdZQVGNBfOR4rxF5i7t3hfb4WkS50EK1gBYk2lO9NSrQzxG9QsUsAnN6RHksXqsdOqvnxjLexDfIJlgbcCN9h6TBC66ZXv7PVhl19gIYVifSU7liHkLe0l0fw7jUI6rHLHf4d96\\_neR1HrNIK\\_xssr99Xpv1EM\\_ubxpktX0T925qej9fMEpzzQ5HLmcNt1H2\\_VQ\\_Ww1JOLn9vRnH48FDj7TxlIT74XdTZgTv31w\\_GRPAOfyxEw\\_ZUmxhz5ZngTlQ\",\n\n\"kty\": \"RSA\",\n\n\"kid\": \"oauth-client\"\n\n}\\]\n\n}\n\nFigure 1 JSON WEB Key Set example\n\nAn IXP MAY allow native client applications to omit their key during registration if they are a Public Client using PKCE.","sortOrder":53},{"sectionNumber":"1.6","sectionType":"part","heading":"Grant types","content":"## 1.6 Grant types\n\nThe grant type of authorisation\\_code MUST be supported by an IXP.\n\nThe 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.\n\nIf an IXP supports a Direct Access Client type, it MUST also support the grant type of\n\nclient\\_credentials.\n\nImplementation of the Client Credentials grant MUST conform to RFC 6749.","sortOrder":54},{"sectionNumber":"1.7","sectionType":"part","heading":"Technical Relying Party Profile","content":"## 1.7 Technical Relying Party Profile\n\nIn 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.","sortOrder":55},{"sectionNumber":"1.7.1 Requests to the Authorisation Endp","sectionType":"division","heading":"1.7.1 Requests to the Authorisation Endpoint","content":"### 1.7.1 Requests to the Authorisation Endpoint\n\nIXP’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.\n\nIXP’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.\n\nIXP’s clients MUST include their full redirect URI in the authorisation request.\n\nTo 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.\n\nThe Authentication Request MUST contain the following REQUIRED parameters and MAY contain the following OPTIONAL parameter values:\n\n client\\_id\n\n REQUIRED. Client Identifier (within the meaning of RFC 6749) valid at the authorisation server.\n response\\_type\n\n REQUIRED. Must be set to code.\n scope\n\n REQUIRED. Indicates the attributes being requested. The openid scope MUST always be present. Additional scopes are defined in Schedule 3 (AGDIS Attribute Profile).\n redirect\\_uri\n\n 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.\n state","sortOrder":56},{"sectionNumber":"1.7.2 Requests to the Token Endpoint","sectionType":"division","heading":"1.7.2 Requests to the Token Endpoint","content":"### 1.7.2 Requests to the Token Endpoint\n\nRequests 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.\n\nThe 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.","sortOrder":57},{"sectionNumber":"1.7.3 Token response","sectionType":"division","heading":"1.7.3 Token response","content":"### 1.7.3 Token response\n\nThe 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.","sortOrder":58},{"sectionNumber":"1.7.3.1 ID Tokens","sectionType":"division","heading":"1.7.3.1 ID Tokens","content":"### 1.7.3.1 ID Tokens\n\nAll clients MUST validate the signature of an ID Token before accepting it using the public key of the issuing server, published in JWK format.\n\nAn 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:\n\n  iss","sortOrder":59},{"sectionNumber":"1.7.4 Request to the UserInfo Endpoint","sectionType":"division","heading":"1.7.4 Request to the UserInfo Endpoint","content":"### 1.7.4 Request to the UserInfo Endpoint\n\nAn IXP MUST be able to accept UserInfo Request from clients using either the HTTP GET or POST methods.\n\nAn IXP MUST only accept Access Tokens from its clients when presented as Bearer Tokens, as outlined in the RFC 6750.","sortOrder":60},{"sectionNumber":"1.7.5 Request Object","sectionType":"division","heading":"1.7.5 Request Object","content":"### 1.7.5 Request Object\n\nA client MAY send request to the authorisation end point using the request parameters as outlined in OpenID Connect Core 1.0.\n\nRequest objects MUST be signed by the client’s public key.\n\nA client MAY encrypt the request object with the authorisation server’s public key.","sortOrder":61},{"sectionNumber":"1.7.6 Discovery","sectionType":"division","heading":"1.7.6 Discovery","content":"### 1.7.6 Discovery\n\nClients and protected resources MAY cache an IXP’s OpenID Connect metadata once the IXP has been discovered, as outlined in this Schedule.","sortOrder":62},{"sectionNumber":"1.8","sectionType":"part","heading":"Identity Exchange OpenID Connect provider Profile","content":"## 1.8 Identity Exchange OpenID Connect provider Profile\n\n### 1.8.1 Connecting to clients\n\n 1.8.1.1 Grant types\n\nThe 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.\n\nThe 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.\n\n### 1.8.1.2 Client authentication\n\nAn authorisation server MUST enforce client authentication for access to the authorisation server’s Token Endpoint.\n\nAn authorisation server MUST only authenticate clients using the private\\_key\\_jwt method as prescribed in the OpenID Connect Core 1.0.\n\nAn authorisation server MUST NOT authenticate clients using any other method.\n\nThe 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.\n\nAn authorisation server SHOULD:\n\n allow for clock skew of 300 seconds between systems when assessing the expiry of a JWT; and\n reject any JWT with expiry that is unreasonably far into the future.\n\nThe JWT MUST contain the following REQUIRED claims and MAY contain the following OPTIONAL claims:\n\n iss","sortOrder":63},{"sectionNumber":"1.8.1 Connecting to clients","sectionType":"division","heading":"1.8.1 Connecting to clients","content":"### 1.8.1 Connecting to clients\n\n 1.8.1.1 Grant types\n\nThe 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.\n\nThe 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.","sortOrder":64},{"sectionNumber":"1.8.1.2 Client authentication","sectionType":"division","heading":"1.8.1.2 Client authentication","content":"### 1.8.1.2 Client authentication\n\nAn authorisation server MUST enforce client authentication for access to the authorisation server’s Token Endpoint.\n\nAn authorisation server MUST only authenticate clients using the private\\_key\\_jwt method as prescribed in the OpenID Connect Core 1.0.\n\nAn authorisation server MUST NOT authenticate clients using any other method.\n\nThe 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.\n\nAn authorisation server SHOULD:\n\n allow for clock skew of 300 seconds between systems when assessing the expiry of a JWT; and\n reject any JWT with expiry that is unreasonably far into the future.\n\nThe JWT MUST contain the following REQUIRED claims and MAY contain the following OPTIONAL claims:\n\n iss","sortOrder":65},{"sectionNumber":"1.8.1.3 Dynamic registration","sectionType":"division","heading":"1.8.1.3 Dynamic registration","content":"### 1.8.1.3 Dynamic registration\n\nAn IXP MAY support the dynamic registration of clients.","sortOrder":66},{"sectionNumber":"1.8.1.4 Discovery","sectionType":"division","heading":"1.8.1.4 Discovery","content":"### 1.8.1.4 Discovery\n\nEndpoints and parameters specified in the discovery document below MAY be considered public information regardless of the existence of the discovery document.\n\nAn IXP MUST provide a well-known endpoint for its configuration as described in the OpenID Connect Discovery 1.0.\n\nAn 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.\n\nThe discovery document published by a IXP MUST as a minimum contain the following fields:\n\n  issuer\n o REQUIRED. The fully qualified issuer URL of the server.\n  authorization\\_endpoint\n o REQUIRED. The fully qualified URL of the server’s Authorisation Endpoint defined in RFC 6749.","sortOrder":67},{"sectionNumber":"1.8.1.5 PKCE","sectionType":"division","heading":"1.8.1.5 PKCE","content":"### 1.8.1.5 PKCE\n\nAn 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).\n\nThe authorisation server MUST NOT allow a client to use the plain code challenge method (within the meaning of RFC 7636).","sortOrder":68},{"sectionNumber":"1.8.2 Response to Authorisation Requests","sectionType":"division","heading":"1.8.2 Response to Authorisation Requests","content":"### 1.8.2 Response to Authorisation Requests\n\nThe authorisation code flow’s authorisation response MUST return the following fields in the response:\n\n state\n\n The value of the state parameter passed in via the authentication request. This value MUST match exactly.\n code\n\n The authorisation code, a random string issued by the OIDC provider to be used request to the Token Endpoint.\n\nPKCE parameters MUST be associated with the “code” (refer above) within the meaning of RFC 7636.\n\nThis response MUST be sent to the client via a HTTP redirect to the URI specified in the request.","sortOrder":69},{"sectionNumber":"1.8.2.1 Authentication Error Response","sectionType":"division","heading":"1.8.2.1 Authentication Error Response","content":"### 1.8.2.1 Authentication Error Response\n\nThe Authentication Error Response is the message returned from an IXP’s Authorisation Endpoint in response to the Authorisation Request sent by the client.\n\nIf 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:\n\n  authentication\\_cancelled\n o The End-User did not proceed with the authentication interaction.","sortOrder":70},{"sectionNumber":"1.8.2.2 Responding to Invalid Claims","sectionType":"division","heading":"1.8.2.2 Responding to Invalid Claims","content":"### 1.8.2.2 Responding to Invalid Claims\n\nA 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).\n\nIf an IXP receives a request for a scope or claim it cannot fulfill, the IXP MUST ignore these scopes or claims.\n\nAn 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.","sortOrder":71},{"sectionNumber":"1.8.3 Token Response","sectionType":"division","heading":"1.8.3 Token Response","content":"### 1.8.3 Token Response\n\nAll tokens issued by an IXP MUST be signed with the IXP’s private key.\n\nFor 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).\n\nIf an IXP issues refresh token they MUST have a lifespan of no longer than 24 hours (which is 86,400 seconds).\n\nToken lifespans MAY be shorter than these prescribed values to meet the requirements of an IXP’s security risk assessment.","sortOrder":72},{"sectionNumber":"1.8.3.1 ID Token","sectionType":"division","heading":"1.8.3.1 ID Token","content":"### 1.8.3.1 ID Token\n\nAn 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.\n\nAn IXP issued ID Token MUST:\n\n expire; and\n have a lifespan of no longer than 300 seconds.\n\nAn IXP SHOULD assign lifespans of shorter than 300 seconds to an ID Token.\n\nAn 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:\n\n iss","sortOrder":73},{"sectionNumber":"1.8.4 UserInfo Endpoint","sectionType":"division","heading":"1.8.4 UserInfo Endpoint","content":"### 1.8.4 UserInfo Endpoint\n\nAn 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).\n\nWhen processing a UserInfo request, a IXP MUST only return the claims that are authorised within the authentication request associated with the presented access token.\n\nAn 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.\n\nThe sub claim MUST always be present in the UserInfo response.","sortOrder":74},{"sectionNumber":"1.8.5 Request Objects","sectionType":"division","heading":"1.8.5 Request Objects","content":"### 1.8.5 Request Objects\n\nAn IXP operating as OpenID Connect provider MUST accept requests containing a request object signed by the client’s private key.\n\nAn IXP MUST validate the signature on request objects using the client’s public key.\n\nAn IXP MUST implement support for receiving requests objects encrypted with one of its public keys.","sortOrder":75},{"sectionNumber":"1.8.6 Authentication Context","sectionType":"division","heading":"1.8.6 Authentication Context","content":"### 1.8.6 Authentication Context\n\nAn IXP MUST provide an ACR in line with the claims outlined in section 4.4.1.3 of Schedule 3 (AGDIS Attribute Profile).\n\nAn 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.","sortOrder":76},{"sectionNumber":"1.9","sectionType":"part","heading":"Entity information","content":"nonce\n\n If a nonce value was supplied with the authentication request, then this value is REQUIRED.\n jti\n\n REQUIRED. A unique identifier for the token which can be used to prevent the reuse of the token.\n exp, iat, nbf\n\n 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.\n\n### 1.8.4 UserInfo Endpoint\n\nAn 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).\n\nWhen processing a UserInfo request, a IXP MUST only return the claims that are authorised within the authentication request associated with the presented access token.\n\nAn 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.\n\nThe sub claim MUST always be present in the UserInfo response.\n\n### 1.8.5 Request Objects\n\nAn IXP operating as OpenID Connect provider MUST accept requests containing a request object signed by the client’s private key.\n\nAn IXP MUST validate the signature on request objects using the client’s public key.\n\nAn IXP MUST implement support for receiving requests objects encrypted with one of its public keys.\n\n### 1.8.6 Authentication Context\n\nAn IXP MUST provide an ACR in line with the claims outlined in section 4.4.1.3 of Schedule 3 (AGDIS Attribute Profile).\n\nAn 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.\n\n## 1.9 Entity information\n\n### 1.9.1 Claims supported\n\nAn 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.","sortOrder":77},{"sectionNumber":"1.9.1 Claims supported","sectionType":"division","heading":"1.9.1 Claims supported","content":"### 1.9.1 Claims supported\n\nAn 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.","sortOrder":78},{"sectionNumber":"1.9.2 Scope profiles","sectionType":"division","heading":"1.9.2 Scope profiles","content":"### 1.9.2 Scope profiles\n\nAn authorisation server MUST fulfill scopes on best effort basis.\n\nAn 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).","sortOrder":79},{"sectionNumber":"1.9.3 Valid ACR Claims","sectionType":"division","heading":"1.9.3 Valid ACR Claims","content":"### 1.9.3 Valid ACR Claims\n\nAssurance levels are outlined in section 2.1.3 of Schedule 1 (AGDIS Onboarding Specifications).\n\nAn IXP MUST implement support to allow its PRPs to use either the acr\\_values or acr claim to request their required ACR.\n\nAn IXP MUST reject any request that include both the acr\\_values and acr claims.\n\nWhen the acr claim is requested an IXP MUST support the acr claim being optionally marked as essential claim by the client. For example:\n\n“claims”: {\n\n“id\\_token”: {\n\n“acr”: {\n\n“essential”: true,\n\n“values”: \\[“urn:id.gov.au:tdif:acr:ip2:cl3”\\]\n\n}\n\n}\n\n}\n\nFigure 6 Requesting authentication assurance level with claims\n\nWhen the acr values are marked as an essential claim, the IXP MUST return a value that matches the requested values.\n\nIf the individual is unable to achieve the required level of assurance outlined in the request and the acr\n\nclaim is marked as essential, then an IXP MUST respond with an authentication error.\n\nIf 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.","sortOrder":80},{"sectionNumber":"1.10","sectionType":"part","heading":"User consent","content":"## 1.10 User consent\n\nGiven 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.","sortOrder":81},{"sectionNumber":"1.11","sectionType":"part","heading":"Privacy considerations","content":"## 1.11 Privacy considerations\n\nAn IXP MUST adhere to all the attribute sharing policies set out in Chapter 2 and Chapter 3 of Schedule 3 (AGDIS Attribute Profile).","sortOrder":82},{"sectionNumber":"1.12","sectionType":"part","heading":"Security considerations","content":"## 1.12 Security considerations\n\nAll clients of an IXP SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.","sortOrder":83},{"sectionNumber":"2. Identity service provider","sectionType":"part","heading":"2. Identity service provider","content":"# 2. Identity service provider\n\nThis Chapter outlines the requirements for:\n\n IXPs in their role as a TRP to ISPs; and\n ISPs in their roles as OIDC providers to IXPs.","sortOrder":84},{"sectionNumber":"2.1.1 Full Client with User Delegation","sectionType":"division","heading":"2.1.1 Full Client with User Delegation","content":"### 2.1.1 Full Client with User Delegation\n\nThis 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.\n\nAn ISP MUST only support clients of this type.\n\nAll 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.\n\nAn ISP MUST ensure that the user authenticates to the Authorisation Endpoint.\n\nThe 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.\n\nAn ISP MUST associate the clients with a unique public key as described in section 2.4 of this Schedule.\n\nIf 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.","sortOrder":86},{"sectionNumber":"2.5","sectionType":"part","heading":"Grant types","content":"## 2.5 Grant types\n\nAn ISP MUST only support the authorization\\_code grant type when providing services to IXPs.","sortOrder":90},{"sectionNumber":"2.6","sectionType":"part","heading":"Technical Relying Party Profile","content":"## 2.6 Technical Relying Party Profile\n\nThis section outlines the profile that an ISP MUST provide for the IXPs that are its TRPs.","sortOrder":91},{"sectionNumber":"2.6.1 Audit Logging","sectionType":"division","heading":"2.6.1 Audit Logging","content":"### 2.6.1 Audit Logging\n\nAn IXP MUST log all interactions with its ISPs using a unique audit identifier it has generated for an authentication request from its TRP.\n\nTo 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.","sortOrder":92},{"sectionNumber":"2.6.2 Request to the Authorisation Endpo","sectionType":"division","heading":"2.6.2 Request to the Authorisation Endpoint","content":"### 2.6.2 Request to the Authorisation Endpoint\n\nAn IXP making a request to the Authorisation Endpoint MUST use an unpredictable value for the\n\nstate parameter with at least 128 bits of entropy.\n\nAn IXP MUST validate the state parameter upon return to the redirect URI.\n\nAn 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.\n\nAn ISP MUST match the entire redirect URI using strict string comparison against registered values and reject request with missing or invalid redirect URIs.\n\nThe authentication request MUST contain the following REQUIRED parameters and MAY contain the following OPTIONAL parameters.\n\n client\\_id\n\n REQUIRED. Client Identifier (within the meaning of RFC 6749) assigned to a IXP by the ISP.\n response\\_type\n\n REQUIRED. MUST be set to code.\n scope\n\n REQUIRED. Indicates the attributes being requested. The openid scope MUST always be present.\n redirect\\_uri\n\n 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.\n state\n\n 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.\n An IXP SHOULD use a unique value for each authorisation request.\n nonce\n\n 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.\n acr\\_values\n\n 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.\n user\\_flow\n\n OPTIONAL. A string value that indicates the desired user flow for the user. Defined values are:\n\n sign\\_in: An Exchange requests this when a TRP expects the user to already have a digital ID and sign in at the ISP.","sortOrder":93},{"sectionNumber":"2.6.3 Request to the Token Endpoint","sectionType":"division","heading":"2.6.3 Request to the Token Endpoint","content":"### 2.6.3 Request to the Token Endpoint\n\nRequest 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.\n\nThe claims that are included in the JWT are summarised below:\n\n iss","sortOrder":94},{"sectionNumber":"2.6.4 Request to the UserInfo Endpoint","sectionType":"division","heading":"2.6.4 Request to the UserInfo Endpoint","content":"### 2.6.4 Request to the UserInfo Endpoint\n\nAn ISP MUST implement support for an IXP to send a UserInfo request using either the HTTP GET or POST methods.\n\nThe Access Token obtained from authentication request MUST be sent as a Bearer Token, as described in RFC 6750.","sortOrder":95},{"sectionNumber":"2.6.5 ID Tokens","sectionType":"division","heading":"2.6.5 ID Tokens","content":"### 2.6.5 ID Tokens\n\nAn IXP MUST validate the signature of an ID Token before accepting it by using the public key of the ISP that issued it.\n\nAn IXP MAY require an ISP to encrypt the ID Tokens it returns.\n\nIf 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:\n\n iss\n\n The issue field is the URL of the expected issuer.\n aud\n\n The audience field contains the client ID of the IXP.\n nonce\n\n String value used to associate the client session with the ID Token.\n exp, iat, nbf\n\n 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.","sortOrder":96},{"sectionNumber":"2.6.6 Request Objects","sectionType":"division","heading":"2.6.6 Request Objects","content":"### 2.6.6 Request Objects\n\nAn IXP MAY optionally send requests to the Authorisation Endpoint using the request parameter as defined in the OpenID Connect Core 1.0.\n\nAn IXP MUST sign the request object with its registered key.\n\nAn IXP MAY encrypt the request object using the ISP’s public key.","sortOrder":97},{"sectionNumber":"2.6.7 Discovery","sectionType":"division","heading":"2.6.7 Discovery","content":"### 2.6.7 Discovery\n\nAn IXP MAY cache the ISP’s OIDC provider metadata once the ISP has been discovered and used by that IXP.","sortOrder":98},{"sectionNumber":"2.7","sectionType":"part","heading":"Identity Provider Profile","content":"## 2.7 Identity Provider Profile\n\nAn ISP providing authentication services to an IXP using OpenID Connect Core 1.0 MUST implement this Schedule.","sortOrder":99},{"sectionNumber":"2.7.1 Audit Logging","sectionType":"division","heading":"2.7.1 Audit Logging","content":"### 2.7.1 Audit Logging\n\nAn ISP MUST log all authentication requests and responses, including the values of the client\\_id\n\nand the state parameters associated with the request.","sortOrder":100},{"sectionNumber":"2.7.2 Connecting to clients","sectionType":"division","heading":"2.7.2 Connecting to clients","content":"### 2.7.2 Connecting to clients\n\n 2.7.2.1 Grant types\n\nThe only supported grant type is authorization\\_code.\n\nThe 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.\n\nThe ISP MUST validate all redirect URIs for the authorization\\_code grant type.","sortOrder":101},{"sectionNumber":"2.7.2.2 Client authentication","sectionType":"division","heading":"2.7.2.2 Client authentication","content":"### 2.7.2.2 Client authentication\n\nAn ISP MUST enforce client authentication for access to the authorisation server’s Token Endpoint.\n\nAn ISP MUST only authenticate clients using the private\\_jwt\\_key method as prescribed in the OpenID Connect Core 1.0.\n\nAn ISP’s authorisation server MUST NOT authenticate clients using any other method.\n\nThe JWT used to authenticate the client MUST expire and have a lifetime of no longer than 300 seconds.\n\nAn ISP’s authorisation server MUST reject a JWT with an expiry time that has passed. An ISP SHOULD:\n\n allow for clock skew of 300 seconds between systems when assessing the expiry of a JWT; and\n reject any JWT with expiry that is unreasonably far into the future.\n\nThe JWT MUST contain the following REQUIRED claims and MAY contain the following OPTIONAL claims:\n\n iss","sortOrder":102},{"sectionNumber":"2.7.2.3 Dynamic registration","sectionType":"division","heading":"2.7.2.3 Dynamic registration","content":"### 2.7.2.3 Dynamic registration\n\nAn ISP MUST NOT support dynamic registration of IXPs as clients.","sortOrder":103},{"sectionNumber":"2.7.2.4 Discovery","sectionType":"division","heading":"2.7.2.4 Discovery","content":"### 2.7.2.4 Discovery\n\nEndpoints and parameters specified in the Discovery document MAY be considered public information regardless of the existence of the discovery document.\n\nAn ISP MAY provide a well-known endpoint for its OpenID configuration as described in the OpenID Connect Discovery 1.0.\n\nIf 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.\n\nIf an ISP publishes a discovery document, the document MUST as a minimum contain the following REQUIRED fields and MAY contain the OPTIONAL fields:\n\n  issuer\n o REQUIRED. The fully qualified issuer URL of the server.\n  authorization\\_endpoint\n o REQUIRED. The fully qualified URL of the server’s Authorisation Endpoint defined in RFC 6749.\n  token\\_endpoint\n o REQUIRED. The fully qualified URL of the server’s Token Endpoint defined in RFC 6749.\n  introspection\\_endpoint\n o OPTIONAL. The fully qualified URL of the server’s introspection endpoint defined in RFC 7662.\n  revocation\\_endpoint\n o OPTIONAL. The fully qualified URL of the server’s revocation endpoint as within the meaning of RFC 7009.\n  jwks\\_uri\n o REQUIRED. The fully qualified URI of the server’s public key in JWK Set format as defined in RFC 7517.\n  scopes\\_supported\n o REQUIRED. The list of scopes that MUST be made available by an ISP as defined in Schedule 3 (AGDIS Attribute Profile).\n  claims\\_supported","sortOrder":104},{"sectionNumber":"2.7.3 Requests to the Authorisation Endp","sectionType":"division","heading":"2.7.3 Requests to the Authorisation Endpoint (Authentication Request)","content":"### 2.7.3 Requests to the Authorisation Endpoint (Authentication Request)\n\nAn ISP MUST support all mechanisms for requesting a level of assurance as prescribed in section\n\n2.8.3 of this Schedule.","sortOrder":105},{"sectionNumber":"2.7.4 User consent","sectionType":"division","heading":"2.7.4 User consent","content":"### 2.7.4 User consent\n\nAs 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).\n\nAn IXP MUST provide the mechanisms to capture express consent from the individual.\n\nAn 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.","sortOrder":106},{"sectionNumber":"2.7.5 Response to Authorisation Requests","sectionType":"division","heading":"2.7.5 Response to Authorisation Requests","content":"### 2.7.5 Response to Authorisation Requests\n\nThe authorisation response to the authorisation code flow MUST return the following fields in the response:\n\n state\n\n The value of the state parameter passed in via the authentication request. This value MUST match exactly.\n code\n\n The authorisation code, a random string issued by the OIDC provider to be used request to the Token Endpoint.\n\nThe key requirements for these fields are described in section 4.1.2 (Authorization Response) of RFC 6749.\n\nThis response MUST be sent to the client via a HTTP redirect to the URI specified in the request.","sortOrder":107},{"sectionNumber":"2.7.5.1 Authentication Error Response","sectionType":"division","heading":"2.7.5.1 Authentication Error Response","content":"### 2.7.5.1 Authentication Error Response\n\nThe Authentication Error Response is the message returned from an ISP’s Authorisation Endpoint in response to the Authorisation Request sent by an IXP.\n\nIf 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:\n\n section 4.1.2.1 (Error Response) of RFC 6749; or\n section 3.1.2.6 (Authentication Error Response) of OpenID Connect Core 1.0. This profile defines an additional authentication error response:\n\n authentication\\_cancelled\n\n The End-User did not proceed with the authentication interaction.","sortOrder":108},{"sectionNumber":"2.7.6 Token Response","sectionType":"division","heading":"2.7.6 Token Response","content":"### 2.7.6 Token Response\n\nA 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.\n\nAn ISP MAY also include a Refresh Token in the Token Response.","sortOrder":109},{"sectionNumber":"2.7.6.1 ID Token","sectionType":"division","heading":"2.7.6.1 ID Token","content":"### 2.7.6.1 ID Token\n\nAn ISP MAY encrypt ID Tokens using the appropriate key of the requesting IXP.\n\nAn ISP issued ID Token MUST expire with a lifespan of no longer than 300 seconds.\n\nAn ISP SHOULD assign lifespans shorter than 300 seconds to the ID Tokens it issues.\n\nAn ISP issued ID Token MUST contain the following fields that are defined as REQUIRED.\n\n iss\n\n REQUIRED. The issuer field is the URL of the expected issuer.\n aud\n\n REQUIRED. The audience field contains the client ID of the client.\n sub\n\n REQUIRED. The identifier of the user. Note it MUST be a pairwise anonymous identifier and be unique to the client’s OpenID Sector.\n acr\n\n REQUIRED. This is the level of assurance at which the user was authenticated at.\n nonce\n\n If a nonce value was supplied with the authentication request, then this value is REQUIRED.\n jti\n\n REQUIRED. A unique identifier for the token which can be used to prevent the reuse of the token.\n exp, iat, nbf\n\n 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.\n\nThe following is an example of an ID token signed using the server’s RSA key.\n\neyJhbGciOiJSUzI1NiJ9.eyJhdXRoX3RpbWUiOjE0 \nMTg2OTg3ODIsImV4cCI6MTQxODY5OTQxMiwic3ViI \njoiNldaUVBwblF4ViIsIm5vbmNlIjoiMTg4NjM3Yj \nNhZjE0YSIsImF1ZCI6WyJjMWJjODRlNC00N2VlLTR \niNjQtYmI1Mi01Y2RhNmM4MWY3ODgiXSwiaXNzIjoi \naHR0cHM6XC9cL2lkcC1wLmV4YW1wbGUuY29tXC8iL \nCJpYXQiOjE0MTg2OTg4MTJ9mQc0rtL56dnJ7\\_zO\\_f \nx8-qObsQhXcn-qN-FC3JIDBuNmP8i11LRA\\_sgh\\_om \nRRfQAUhZD5qTRPAKbLuCD451lf7ALAUwoGg8zAASI \n5QNGXoBVVn7buxPd2SElbSnHxu0o8ZsUZZwNpircW \nNUlYLje6APJf0kre9ztTj-5J1hRKFbbHodR2I1m5q \n \n\n8zQR0ql-FoFlOfPhvfurXxCRGqP1xpvLLBUi0JAw3 \nF8hZt\\_i1RUYWMqLQZV4VU3eVNeIPAD38qD1fxTXGV \nEd2XDJpmlcxjrWxzJ8fGfJrbsiHCzmCjflhv34O22 \nzb0lJpC0d0VScqxXjNTa2-ULyCoehLcezmssg\n\nFigure 9 Sample ID Token signature\n\nIts claims are as follows:\n\n{ \n\"auth\\_time\": 1418698782, \n\"exp\": 1418699412, \n\"sub\": \"6WZQPpnQxV\", \n\"nonce\": \"188637b3af14a\", \n\"aud\": \\[ \n\"c1bc84e4-47ee-4b64-bb52-5cda6c81f788\" \n\\], \n\"iss\": \"https://idp.gov.au/\", \n\"acr\":\"urn:id.gov.au:tdif:acr:ip3:cl2\", \n\"iat\": 1418698812, \n\"nbf\": 1418698812 \n}\n\nFigure 10 Claims used to the generate the prior signature","sortOrder":110},{"sectionNumber":"2.7.7 UserInfo Endpoint","sectionType":"division","heading":"2.7.7 UserInfo Endpoint","content":"### 2.7.7 UserInfo Endpoint\n\nAn ISP MUST support returning claims via the UserInfo endpoint as prescribed by the requirements outlined in Schedule 3 (AGDIS Attribute Profile).\n\nWhen processing a UserInfo request an ISP MUST only return the claims that are authorised within the authentication request associated with the presented access token.\n\nAn 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.\n\nThe sub claim MUST always be present in the UserInfo response.","sortOrder":111},{"sectionNumber":"2.7.8 Request Object","sectionType":"division","heading":"2.7.8 Request Object","content":"### 2.7.8 Request Object\n\nAn 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.\n\nAn ISP MUST implement support for receiving requests objects encrypted with one of its public keys.","sortOrder":112},{"sectionNumber":"2.7.9 Authentication context","sectionType":"division","heading":"2.7.9 Authentication context","content":"### 2.7.9 Authentication context\n\nAn 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.","sortOrder":113},{"sectionNumber":"2.8","sectionType":"part","heading":"Entity information","content":"### 2.7.9 Authentication context\n\nAn 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.\n\n## 2.8 Entity information\n\n### 2.8.1 Claims supported\n\nIXPs and ISPs MUST return claims on a best effort basis.\n\nAn ISP or its connected IXPs asserting it can provide a user claim does not imply that the data is available for all users.\n\nAn 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:\n\n the Act;\n the Accreditation Rules;\n the Digital ID Rules; or\n the Accreditation Data Standards.\n\n### 2.8.2 Scope profiles\n\nAn ISP MUST implement the OpenID Connect support ISP specific scopes and claims outlined as in Schedule 3 (AGDIS Attribute Profile).\n\n### 2.8.3 Valid ACR Claims\n\nAssurance levels are outlined in Schedule 1 (AGDIS Onboarding Specifications).\n\nAn ISP MUST implement support to allow its TRPs to use either the acr\\_values or acr claim to request their required ACR.\n\nAn ISP MUST reject any request that include both the acr\\_values and acr claims.\n\nWhen the acr claim is requested, an ISP MUST support the acr claim being optionally marked as essential claim by the client. For example:\n\n“claims”: {\n\n“id\\_token”: {\n\n“acr”: {\n\n“essential”: true,\n\n“values”: \\[“urn:id.gov.au:tdif:acr:ip2:cl3”\\]\n\n}\n\n}\n\n}\n\nFigure 11 Sample assurance level requests using claims\n\nWhen the acr values are marked as an essential claim, the ISP MUST return a value that matches the requested values.\n\nIf the individual is unable to achieve the required level of assurance outlined in the request and the acr\n\nclaim is marked as essential, then an ISP MUST respond with an authentication error.\n\nIf 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.\n\n## 2.9 Privacy Requirements\n\nAn 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).\n\n## 2.10 Security Considerations\n\nAll clients of an ISP:\n\n MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and\n SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.","sortOrder":114},{"sectionNumber":"2.8.1 Claims supported","sectionType":"division","heading":"2.8.1 Claims supported","content":"### 2.8.1 Claims supported\n\nIXPs and ISPs MUST return claims on a best effort basis.\n\nAn ISP or its connected IXPs asserting it can provide a user claim does not imply that the data is available for all users.\n\nAn 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:\n\n the Act;\n the Accreditation Rules;\n the Digital ID Rules; or\n the Accreditation Data Standards.","sortOrder":115},{"sectionNumber":"2.8.2 Scope profiles","sectionType":"division","heading":"2.8.2 Scope profiles","content":"### 2.8.2 Scope profiles\n\nAn ISP MUST implement the OpenID Connect support ISP specific scopes and claims outlined as in Schedule 3 (AGDIS Attribute Profile).","sortOrder":116},{"sectionNumber":"2.8.3 Valid ACR Claims","sectionType":"division","heading":"2.8.3 Valid ACR Claims","content":"### 2.8.3 Valid ACR Claims\n\nAssurance levels are outlined in Schedule 1 (AGDIS Onboarding Specifications).\n\nAn ISP MUST implement support to allow its TRPs to use either the acr\\_values or acr claim to request their required ACR.\n\nAn ISP MUST reject any request that include both the acr\\_values and acr claims.\n\nWhen the acr claim is requested, an ISP MUST support the acr claim being optionally marked as essential claim by the client. For example:\n\n“claims”: {\n\n“id\\_token”: {\n\n“acr”: {\n\n“essential”: true,\n\n“values”: \\[“urn:id.gov.au:tdif:acr:ip2:cl3”\\]\n\n}\n\n}\n\n}\n\nFigure 11 Sample assurance level requests using claims\n\nWhen the acr values are marked as an essential claim, the ISP MUST return a value that matches the requested values.\n\nIf the individual is unable to achieve the required level of assurance outlined in the request and the acr\n\nclaim is marked as essential, then an ISP MUST respond with an authentication error.\n\nIf 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.","sortOrder":117},{"sectionNumber":"2.9","sectionType":"part","heading":"Privacy Requirements","content":"## 2.9 Privacy Requirements\n\nAn 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).","sortOrder":118},{"sectionNumber":"2.10","sectionType":"part","heading":"Security Considerations","content":"## 2.10 Security Considerations\n\nAll clients of an ISP:\n\n MUST comply with the security considerations in section 10 (Security Considerations) of RFC 6749; and\n SHOULD consider the additional security considerations in section 5 (Security Considerations) of RFC 6819.","sortOrder":119},{"sectionNumber":"3. Protocol brokering","sectionType":"part","heading":"3. Protocol brokering","content":"# 3. Protocol brokering\n\nAn IXP MUST implement support to broker between the protocols used by its connected ISPs and PRPs.\n\nThe AGDIS only supports the OpenID Connect Core 1.0.","sortOrder":120},{"sectionNumber":"3.1.1 Mapping Claims and Scopes","sectionType":"division","heading":"3.1.1 Mapping Claims and Scopes","content":"### 3.1.1 Mapping Claims and Scopes\n\nIf the sub claim is specified it MUST be handled as outlined in section 3.1.2 of this Schedule.\n\nIf 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.\n\nAll 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).\n\nAn IXP MAY expand the scopes defined in an authentication request into underlying claims when brokering an authentication request to its ISPs and ASPs.\n\nScopes 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.","sortOrder":122},{"sectionNumber":"3.1.2 Handling of Subject ID","sectionType":"division","heading":"3.1.2 Handling of Subject ID","content":"### 3.1.2 Handling of Subject ID\n\nAn IXP MAY support the sub claim in authentication requests.\n\nIf an IXP implements support the sub claim in authentication requests:\n\n 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\n the IXP MAY return an error if the pairwise identifier for the user cannot be resolved to the target ISP.","sortOrder":123},{"sectionNumber":"3.1.3 Mapping assurance levels","sectionType":"division","heading":"3.1.3 Mapping assurance levels","content":"### 3.1.3 Mapping assurance levels\n\nIf 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.\n\nIf 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.","sortOrder":124},{"sectionNumber":"3.1.4 Prompt Parameter","sectionType":"division","heading":"3.1.4 Prompt Parameter","content":"### 3.1.4 Prompt Parameter\n\nAn IXP MUST implement these processing rules to broker the OIDC prompt parameter.\n\nTable 1 IXP prompt parameter brokering requirements\n\n| From Relying Party | To Identity Service Provider |\n| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| None | None |\n| Login | Login |\n| 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). |\n| Select Account | Service selection of identity or persona for user in context. |","sortOrder":125},{"sectionNumber":"3.1.5 ID Token Hint Parameter","sectionType":"division","heading":"3.1.5 ID Token Hint Parameter","content":"### 3.1.5 ID Token Hint Parameter\n\nIf an IXP has implemented support for the id\\_token\\_hint mechanism, the following processing rules apply:\n\n 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;\n the IXP MUST resolve the subject identifier at the ISP as per section 3.1.2 of this Schedule; and\n 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.","sortOrder":126},{"sectionNumber":"4. Attributes","sectionType":"part","heading":"4. Attributes","content":"# 4. Attributes\n\nSchedule 3 (AGDIS Attribute Profile) outlines the attributes and attribute sets that are available to PRPs.","sortOrder":127},{"sectionNumber":"Table of Figures","sectionType":"part","heading":"Table of Figures","content":"# Table of Figures\n\nFigure 1 Verified Documents sample claim request................................81\n\nFigure 2 Self-asserted address sample claim request..............................91\n\nFigure 3 Self-asserted other email address sample claim request.....................93\n\nFigure 4 Self-asserted other email address scope equivalent claim request.............93\n\nFigure 5 Self-asserted other phone number sample claim request using the contact type..94\n\nFigure 6 Self-asserted other phone number sample claim request using telephony type...94\n\nFigure 7 Self-asserted other phone number scope equivalent claim request............94","sortOrder":130},{"sectionNumber":"1. Operation of attributes","sectionType":"part","heading":"1. Operation of attributes","content":"# 1. Operation of attributes\n\nThis Chapter outlines how attributes operate within the context of the AGDIS and the components of an attribute sharing policy.","sortOrder":131},{"sectionNumber":"1.2.1 Consent types","sectionType":"division","heading":"1.2.1 Consent types","content":"### 1.2.1 Consent types\n\nConsent types prescribe requirements for gathering of express consent from the individual by an accredited entity participating in the AGDIS.\n\nThe consent types outlined in this Schedule are found in Table 1 below.\n\nAn attribute sharing policy MUST include a consent type and assign the management of that consent to either or both:\n\n a specific entity (which is a named accredited entity such as myGov as an ASP); and\n a specific role (such as the ASP, ISP and IXP).","sortOrder":134},{"sectionNumber":"1.2.2 Fulfilment requirements","sectionType":"division","heading":"1.2.2 Fulfilment requirements","content":"### 1.2.2 Fulfilment requirements\n\nNot all attributes have guaranteed availability, and some may not be available for the IP level associated with the authenticated session.\n\nThe 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.\n\nThe necessity to meet an attributes request is referred to as a fulfilment requirement in this Schedule.\n\nAn attribute sharing policy MUST have a fulfilment policy to inform the behaviours of entities participating in the AGDIS when attribute requests cannot be fulfilled.\n\nThe two fulfilment requirements used in this Schedule are outlined in Table 2 below.\n\nTable 2 Attribute fulfilment requirement classes\n\n| Fulfilment requirement | Criteria and description |\n| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| 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. |\n| 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. |","sortOrder":135},{"sectionNumber":"1.2.3 Access policy","sectionType":"division","heading":"1.2.3 Access policy","content":"### 1.2.3 Access policy\n\nAttributes 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.\n\nAn attribute sharing policy MUST outline the access policy that applies to its attributes or attribute sets.\n\nAn attribute sharing policy MAY extend the access policy for a given context provided the intent of the policy is not overridden.\n\nThe 4 access policies available under this Schedule are outline in Table 3 below.\n\nTable 3 Access policies that MUST be applied to attributes\n\n| Policy | Details |\n| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| 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. |\n| Not available | The attribute request MUST NOT be fulfilled.An ASP, ISP and IXP MAY respond with an error. |\n| 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. |\n| 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. |","sortOrder":136},{"sectionNumber":"1.2.4 Data representation","sectionType":"division","heading":"1.2.4 Data representation","content":"### 1.2.4 Data representation\n\nAn attribute sharing policy MUST be accompanied by a high-level specification of an attribute or attribute set’s underlying values.","sortOrder":137},{"sectionNumber":"2. Core Attributes","sectionType":"part","heading":"2. Core Attributes","content":"# 2. Core Attributes\n\nThis Chapter outlines the attribute sharing policies for the Core Attributes available from the AGDIS.","sortOrder":138},{"sectionNumber":"2.1.1 Core","sectionType":"division","heading":"2.1.1 Core","content":"### 2.1.1 Core\n\nCore Attributes are foundational elements used to identify an individual.\n\nA summary of the attribute sharing policies, outlined here for Core Attributes, is provided in Table 5 below.\n\nAll 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.\n\nAn IXP MUST request express consent from the individual for Core Attributes which have changed since consent was last recorded by the IXP.\n\nAn IXP MUST support brokering requests to its ISPs for all Core Attributes for requested IP Level of IP1 Plus or stronger.\n\nAt IP1 Plus or stronger, an ISP MUST fulfill an attribute request for:\n\n Family Name;\n Date of Birth;\n Core Attributes Last Updated.\n\nAn ISP MUST return an error if it cannot fulfill a request for the above attributes.\n\nAt IP1 Plus or stronger, an ISP MUST fulfill requests for the following attributes if they are available:\n\n Given Names;\n Middle Names.\n\nAt IP1 Plus or stronger, an ISP MAY fulfill an attribute request for Full Name.\n\nAt an IP Level less than IP1 Plus, an ISP SHOULD1 NOT fulfill a request for Core Attributes other than Preferred Name.\n\nAn 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.\n\nAny attribute returned at IP1 should be assumed self-asserted.\n\nAn 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.\n\nAn 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.","sortOrder":140},{"sectionNumber":"2.1.2 Validated Contact Details","sectionType":"division","heading":"2.1.2 Validated Contact Details","content":"### 2.1.2 Validated Contact Details\n\nContact 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.\n\nValidated Contact Details attributes are subject to an Open access policy.\n\n![](image.007.png) \n\n1 It is intended that this requirement will change to become ‘MUST’ (rather than ‘SHOULD’) 12 months from commencement of the Act.","sortOrder":141},{"sectionNumber":"2.1.3 Verified Other Names","sectionType":"division","heading":"2.1.3 Verified Other Names","content":"### 2.1.3 Verified Other Names\n\nAdditional 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.\n\nThese 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:\n\n Commencement of Identity Documents;\n Linking Documents;\n Photo ID Documents.\n\nA summary of the attribute sharing policy for Verified Other Names is outlined in Table 7 below.\n\nThe Verified Other Names attribute set is subject to an Open access policy (as defined above) at IP1 Plus and stronger.\n\nAn IXP MUST NOT broker requests for Verified Other Names for IP levels weaker than IP1 Plus.\n\nAn IXP MAY ignore attribute requests or raise an error if the requested assurance level is less than IP1 Plus.\n\nAn 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.\n\nAn ISP MUST support attribute requests for Verified Other Names.","sortOrder":142},{"sectionNumber":"2.1.4 Verified Documents","sectionType":"division","heading":"2.1.4 Verified Documents","content":"### 2.1.4 Verified Documents\n\nThe 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:\n\n Commencement of Identity Documents;\n Linking Documents;\n Photo ID Documents;\n Use in the Community Documents.\n\nNot all fields/attributes from a verified document can be readily verified.\n\nThe 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.\n\nAn IXP MUST request express consent from the individual on every use of the Verified Documents attribute set.\n\nAn 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.\n\nAn ISP MUST support attribute request for single or multiple Verified Documents.\n\nWhen processing generic requests for Verified Documents, an ISP MUST prepare a response that conforms to IP2 or higher.\n\nWhen 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.\n\nThe 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:\n\n Document Type Code with a value that MUST be one of the URNs outlined in Table 11 below;\n Document Verification Method that MUST be one of the enumerated values in Table 12 below;\n Document Verification Date MUST be valid a date and time value;\n Document Date of Birth MUST be a valid date extracted from the document;\n Document Identifiers is a collection that MUST contain one or more document identifiers outlined in the document type’s schema;\n Document Names is a collection that MUST contain the required document names for the document type’s schema;\n Document Attributes is a collection that MUST contain the required document attributes outlined in the document type’s schema.\n\nA more detailed overview of the fields is provided in Table 9 below.","sortOrder":143},{"sectionNumber":"2.1.4.1 Verified Birth Certificate schem","sectionType":"division","heading":"2.1.4.1 Verified Birth Certificate schema","content":"### 2.1.4.1 Verified Birth Certificate schema\n\nTable 18 Verified Birth Certificate schema\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | ---------------------- | -------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:BC”. |\n| Document Verification Method | - | Y | String | Only source verification is permitted for Birth Certificates. See Table 12 above for accepted values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| 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 |","sortOrder":144},{"sectionNumber":"2.1.4.2 Verified change of name schema","sectionType":"division","heading":"2.1.4.2 Verified change of name schema","content":"### 2.1.4.2 Verified change of name schema\n\nTable 19 Verified Change of Name Certificate schema\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | ---------------------- | -------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:NC”. |\n| Document Verification Method | - | Y | String | Only source verification is permitted for Change of Name Certificates. See Table 12 above for legitimate values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| 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. |","sortOrder":145},{"sectionNumber":"2.1.4.3 Verified Marriage Certificate sc","sectionType":"division","heading":"2.1.4.3 Verified Marriage Certificate schema","content":"### 2.1.4.3 Verified Marriage Certificate schema\n\nTable 20 Verified Marriage Certificate schema\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | ------------------------------------------------ | -------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:MC”. |\n| Document Verification Method | - | Y | String | Only source verification is permitted for Marriage Certificates. See Table 12 above for legitimate values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| 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. |","sortOrder":146},{"sectionNumber":"2.1.4.4 Verified Citizenship Certificate","sectionType":"division","heading":"2.1.4.4 Verified Citizenship Certificate schema","content":"### 2.1.4.4 Verified Citizenship Certificate schema\n\nTable 21 Verified Citizenship Certificate and Registration by Descent\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | ------------- | -------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| 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 |\n| Document Verification Method | - | Y | String | Only source verification is permitted for Certificates of Registration by Descent. See Table 12 above for legitimate values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| | 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. |","sortOrder":147},{"sectionNumber":"2.1.4.5 Verified Immigration Card schema","sectionType":"division","heading":"2.1.4.5 Verified Immigration Card schema","content":"### 2.1.4.5 Verified Immigration Card schema\n\nTable 22 Verified ImmiCard schema\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | ---------------------- | -------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:IM”. |\n| Document Verification Method | - | Y | String | Only source verification is permitted for ImmiCards. See Table 12 above for legitimate values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| 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. |\n| 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. |\n| Document Attributes | - | - | - | No attributes for the document. |","sortOrder":148},{"sectionNumber":"2.1.4.6 Verified Visa Request schema","sectionType":"division","heading":"2.1.4.6 Verified Visa Request schema","content":"### 2.1.4.6 Verified Visa Request schema\n\nTable 23 Verified Visa Request schema\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | ---------------------- | -------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |\n| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:VI”. |\n| Document Verification Method | - | Y | String | Only source verification is permitted for Visa Requests. See Table 12 above for legitimate values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| 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. |\n| 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. |","sortOrder":149},{"sectionNumber":"2.1.4.7 Verified Driver Licence schema","sectionType":"division","heading":"2.1.4.7 Verified Driver Licence schema","content":"### 2.1.4.7 Verified Driver Licence schema\n\nTable 24 Verified Driver Licence schema\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | ------------- | -------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:DL”. |\n| Document Verification Method | - | Y | String | Only source verification is permitted for Driver Licences. See Table 12 above for legitimate values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| | 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. |\n| | 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. |","sortOrder":150},{"sectionNumber":"2.1.4.8 Verified Medicare Card schema","sectionType":"division","heading":"2.1.4.8 Verified Medicare Card schema","content":"### 2.1.4.8 Verified Medicare Card schema\n\nTable 25 Verified Medicare Card schema\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | --------------------- | -------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------- |\n| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:MD”. |\n| Document Verification Method | - | Y | String | Only source verification is permitted for Medicare Cards. See Table 12 above for legitimate values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| Document Identifiers | Card Number | Y | String | MUST be a string of 10 numerical characters. |\n| | Individual Ref Number | Y | String | MUST be a single numeric character within the range of 1 to 9 inclusive. |\n| Document Attributes | Card Expiry | Y | Date | MUST meet the data format for the Card Type. See Table 15 for expiry date formats date. |","sortOrder":151},{"sectionNumber":"2.1.4.9 Verified Passport schema","sectionType":"division","heading":"2.1.4.9 Verified Passport schema","content":"### 2.1.4.9 Verified Passport schema\n\nTable 26 Verified Passport schema\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | ------------- | -------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:PP”. |\n| Document Verification Method | - | Y | String | Only source verification is permitted for Passports and Australian Travel Documents. See Table 12 above for legitimate values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| | 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. |","sortOrder":152},{"sectionNumber":"2.1.4.10 Verified Centrelink Concession ","sectionType":"division","heading":"2.1.4.10 Verified Centrelink Concession Card schema","content":"### 2.1.4.10 Verified Centrelink Concession Card schema\n\nTable 27 Verified Centrelink Concession Card schema\n\n| Section | Field Name(s) | Required | Type | Constraints |\n| ---------------------------- | ------------- | -------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Document Type Code | - | Y | URN | Value MUST be “urn:id.gov.au:tdif:doc:type_code:CO”. |\n| Document Verification Method | - | Y | String | Only source verification is permitted for Centrelink Concession Cards. See Table 12 above for legitimate values. |\n| Document Verification Date | - | Y | String | MUST be an RFC 3339 formatted date time value in coordinated universal time. |\n| 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. |\n| 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. |\n| 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 |","sortOrder":153},{"sectionNumber":"2.2.1 Common","sectionType":"division","heading":"2.2.1 Common","content":"### 2.2.1 Common","sortOrder":155},{"sectionNumber":"2.2.1.1 Digital ID Identifier","sectionType":"division","heading":"2.2.1.1 Digital ID Identifier","content":"### 2.2.1.1 Digital ID Identifier\n\nThe Digital ID Identifier is a unique identifier for an individual. The Digital ID Identifier:\n\n (a) For PRPs, is the pairwise identifier assigned to an individual by an IXP; and\n (b) for IXPs, the GPI or pairwise identifier assigned to an individual by an ISP.","sortOrder":156},{"sectionNumber":"2.2.1.2 Authentication Time","sectionType":"division","heading":"2.2.1.2 Authentication Time","content":"### 2.2.1.2 Authentication Time\n\nAuthentication Time is the date and time when the individual successfully authenticated at the ISP. An ISP MUST support this metadata value.\n\nAn IXP MUST support brokering requests for this metadata value.\n\nThe 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.","sortOrder":157},{"sectionNumber":"2.2.1.3 Assurance Level","sectionType":"division","heading":"2.2.1.3 Assurance Level","content":"### 2.2.1.3 Assurance Level\n\nThe Assurance Level of the authenticated digital ID outlines the IP level and authentication level attained during authentication at the ISP.\n\nAn 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.\n\nAn 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.\n\nThe data representation for this value is specified in Schedule 1 (AGDIS Onboarding Specifications) and illustrated in Table 29 below.","sortOrder":158},{"sectionNumber":"2.2.1.4 Authentication Method","sectionType":"division","heading":"2.2.1.4 Authentication Method","content":"### 2.2.1.4 Authentication Method\n\nThe Authentication Method value communicates to the PRP which ISP the individual used to authenticate themselves. The Authentication Method is an IXP managed value.\n\nAn IXP MAY provide the Authentication Method based on the ISP the individual has successfully authenticated themselves if required.\n\nAn IXP MAY cache the attribute to support subsequent SSO requests.\n\nAn IXP MUST NOT return any information about the Authentication Method if the authentication fails or is cancelled by the individual.\n\nThe data representation for the Authentication Method is a URN presented in Table 30 below.","sortOrder":159},{"sectionNumber":"2.2.1.5 Last Updated","sectionType":"division","heading":"2.2.1.5 Last Updated","content":"### 2.2.1.5 Last Updated\n\nLast Updated is the date and time that any of the individual’s attributes were last updated.","sortOrder":160},{"sectionNumber":"2.2.2 Audit","sectionType":"division","heading":"2.2.2 Audit","content":"### 2.2.2 Audit","sortOrder":161},{"sectionNumber":"2.2.2.1 RP audit Identifier","sectionType":"division","heading":"2.2.2.1 RP audit Identifier","content":"### 2.2.2.1 RP audit Identifier\n\nThe RP audit ID requirements are outlined in section 2.1.2 of Schedule 1 (AGDIS Onboarding Specifications).\n\nThe RP audit ID is an IXP specific value that ISPs do not need to support.\n\nAn RP audit ID is a unique audit identifier generated for every logical interaction between a PRP and an IXP to enable an audit trail.\n\nAn IXP MUST NOT share the RP audit ID it has generated for a PRP with ISPs.\n\nTo ensure uniqueness of the RP audit ID within the AGDIS a UUID is used. The UUID generation MUST conform to RFC 4122.\n\nTable 29 Authentication Assurance Levels\n\n| IP level | Authenticator level | URN |\n| -------- | ------------------- | ------------------------------- |\n| IP1 | AL1 | urn:id.gov.au:tdif:acr:ip1:cl1 |\n| | AL2 | urn:id.gov.au:tdif:acr:ip1:cl2 |\n| | AL3 | urn:id.gov.au:tdif:acr:ip1:cl3 |\n| IP1 PLUS | AL1 | urn:id.gov.au:tdif:acr:ip1p:cl1 |\n| | AL2 | urn:id.gov.au:tdif:acr:ip1p:cl2 |\n| | AL3 | urn:id.gov.au:tdif:acr:ip1p:cl3 |\n| IP2 | AL2 | urn:id.gov.au:tdif:acr:ip2:cl2 |\n| | AL3 | urn:id.gov.au:tdif:acr:ip2:cl3 |\n| IP2 PLUS | AL2 | urn:id.gov.au:tdif:acr:ip2p:cl2 |\n| | AL3 | urn:id.gov.au:tdif:acr:ip2p:cl3 |\n| IP3 | AL2 | urn:id.gov.au:tdif:acr:ip3:cl2 |\n| | AL3 | urn:id.gov.au:tdif:acr:ip2p:cl2 |\n| IP4 | AL3 | urn:id.gov.au:tdif:acr:ip4:cl3 |","sortOrder":162},{"sectionNumber":"2.3.1 Preferred Name","sectionType":"division","heading":"2.3.1 Preferred Name","content":"### 2.3.1 Preferred Name\n\nAn 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.\n\nGiven an individual may use the attribute at their ISP to satisfy cultural requirements the preferred name SHOULD be easy to update.\n\nPreferred Name attribute SHOULD be assumed to be self-asserted.\n\nAlthough 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).\n\nThe 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.","sortOrder":164},{"sectionNumber":"2.3.2 Addresses","sectionType":"division","heading":"2.3.2 Addresses","content":"### 2.3.2 Addresses\n\nAn individual MAY self-assert a residential, postal, business, or other addresses.\n\nAddresses MAY be collected during the identity proofing process or added by the individual during the normal use and management of their digital ID.\n\nThe 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:\n\n the address type;\n street address;\n locality;\n region;\n post code; and\n validated.\n\nThe data representation MAY also contain the following fields:","sortOrder":165},{"sectionNumber":"2.3.3 Other Email Addresses","sectionType":"division","heading":"2.3.3 Other Email Addresses","content":"### 2.3.3 Other Email Addresses\n\nAn individual MAY self-assert additional email addresses for use in different contexts, for example when accessing business services with their personal digital ID.\n\nAn 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.\n\nIf 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.\n\nAn 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.\n\nThe attribute response for other email addresses MAY be a single email address or a collection of email addresses.\n\nEach Other Email Address MUST contain:\n\n the email address;\n a flag indicating if the email address has been validated; and\n a contact type label.\n\nThe 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.\n\nThe contact type value MUST be one the contact type URNs enumerated in Table 35 below.\n\nAn 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.","sortOrder":166},{"sectionNumber":"2.3.4 Other Phone Numbers","sectionType":"division","heading":"2.3.4 Other Phone Numbers","content":"### 2.3.4 Other Phone Numbers\n\nAn 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.\n\nThe attribute response for other phone numbers MAY be a single phone number object or a collection of phone number objects.","sortOrder":167},{"sectionNumber":"2.3.5 Place of Birth","sectionType":"division","heading":"2.3.5 Place of Birth","content":"### 2.3.5 Place of Birth\n\nAn 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.\n\nIf an ISP supports this self-asserted attribute, they SHOULD ensure the location supplied by the individual is real if practical to do so.\n\nThe data representation for this attribute is a string with a maximum length of 255 characters.","sortOrder":168},{"sectionNumber":"2.3.6 Personal Titles","sectionType":"division","heading":"2.3.6 Personal Titles","content":"### 2.3.6 Personal Titles\n\nQualification, honorific or gender-based titles can be asserted by the individual to tailor user experiences at a PRP.\n\nAn ISP MAY allow an individual to specify their preferred title.\n\nAn ISP SHOULD appropriately limit the types of titles an individual may choose.\n\nThe data representation for this attribute is string with a maximum length of 100 characters.","sortOrder":169},{"sectionNumber":"3. Attribute Service Provider (ASP) Prof","sectionType":"part","heading":"3. Attribute Service Provider (ASP) Profiles","content":"# 3. Attribute Service Provider (ASP) Profiles\n\nThis Chapter provides the attribute sharing policies for the attributes and attribute sets provided by ASPs.\n\nAn IXP MUST implement support to broker access to these attributes in accordance with this Chapter’s attribute sharing policies.\n\nAn IXP MUST not broker requests for ASP managed attributes or attribute sets to ISPs to ensure AGDIS privacy requirements are maintained.\n\nTable 37 ASP managed attributes and attribute sets\n\n| Attribute Set | Attributes | Description |\n| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| 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). |\n| myGov linkID | myGov linkID | A pairwise identifier used by the myGov platform. This is attribute is subject to restrictions. |","sortOrder":171},{"sectionNumber":"4. OpenID Connect Attribute Profile","sectionType":"part","heading":"4. OpenID Connect Attribute Profile","content":"# 4. OpenID Connect Attribute Profile\n\nTo 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.\n\nThe 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.","sortOrder":174},{"sectionNumber":"4.1.1 Identity Exchange Provider Relying","sectionType":"division","heading":"4.1.1 Identity Exchange Provider Relying Party Mapping","content":"### 4.1.1 Identity Exchange Provider Relying Party Mapping\n\nThe scopes an IXP MUST make available for a PRP to request are:\n\n openid\n profile\n email\n phone\n tdif\\_other\\_names\n tdif\\_docs\n tdif\\_business\\_authorisations\n\nThe 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.\n\nAdditional scopes for Self-Asserted Attributes that an IXP SHOULD support brokering attribute requests for are:\n\n adgis\\_address\n agdis\\_other\\_email\n agdis\\_other\\_phone\n agdis\\_birth\\_place\n agdis\\_personal\\_title","sortOrder":176},{"sectionNumber":"4.1.2 Identity provider scopes and claim","sectionType":"division","heading":"4.1.2 Identity provider scopes and claims","content":"### 4.1.2 Identity provider scopes and claims\n\nThe scopes an ISP MUST make available for its IXPs to request are:\n\n openid\n tdif\\_core\n tdif\\_email\n tdif\\_phone\n tdif\\_other\\_names\n tdif\\_docs\n\nThe 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.\n\nAdditional scopes for Self-Asserted Attributes an ISP SHOULD make available for its IXPs to request are:\n\n adgis\\_address\n agdis\\_other\\_email\n agdis\\_other\\_phone\n agdis\\_birth\\_place\n agdis\\_personal\\_title\n\nThe 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.\n\nAn ISP SHOULD support attribute requests for each individual claim outlined in Table 44 and Table 45.\n\nAn ISP MAY fulfill attributes request via either the Token or UserInfo Endpoints.\n\nAn ISP SHOULD encrypt all scopes and claims, except for the common attributes set, when fulfilling and attribute requests via the Token Endpoint.","sortOrder":177},{"sectionNumber":"4.2.1 JavaScript Object Notation types","sectionType":"division","heading":"4.2.1 JavaScript Object Notation types","content":"### 4.2.1 JavaScript Object Notation types\n\nThe 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.","sortOrder":179},{"sectionNumber":"4.2.2 Simple data types","sectionType":"division","heading":"4.2.2 Simple data types","content":"### 4.2.2 Simple data types\n\nSimple 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.","sortOrder":180},{"sectionNumber":"4.2.2.1 NameString","sectionType":"division","heading":"4.2.2.1 NameString","content":"### 4.2.2.1 NameString\n\nA JSON string that can represent name attributes that are not mandatory. The value has a:\n\n (a) minimum length of zero characters; and\n (b) maximum length of 100 characters.","sortOrder":181},{"sectionNumber":"4.2.2.2 RequiredNameString","sectionType":"division","heading":"4.2.2.2 RequiredNameString","content":"### 4.2.2.2 RequiredNameString\n\nA JSON string that can represent name attributes that are mandatory. The value has a:\n\n (a) minimum length of 1 character; and\n (b) maximum length of 100 characters.","sortOrder":182},{"sectionNumber":"4.2.2.3 Boolean","sectionType":"division","heading":"4.2.2.3 Boolean","content":"## 4.2 Data types\n\n### 4.2.1 JavaScript Object Notation types\n\nThe 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.\n\n### 4.2.2 Simple data types\n\nSimple 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.\n\n### 4.2.2.1 NameString\n\nA JSON string that can represent name attributes that are not mandatory. The value has a:\n\n (a) minimum length of zero characters; and\n (b) maximum length of 100 characters.\n\n### 4.2.2.2 RequiredNameString\n\nA JSON string that can represent name attributes that are mandatory. The value has a:\n\n (a) minimum length of 1 character; and\n (b) maximum length of 100 characters.\n\n### 4.2.2.3 Boolean\n\n### 4.2.2.4 A JSON literal with values that can be true or false.Date\n\nRFC 3339 compliant date string that MUST conform to one of the following:\n\n YYYY\n YYYY-MM\n YYYY-MM-DD\n\nThis value is commonly used to represent birth dates.\n\n### 4.2.2.5 DateTime\n\nRFC 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:\n\n YYYY-MM-DDTHH:MM:SSZ\n YYYY-MM-DDTHH:MMZ","sortOrder":183},{"sectionNumber":"4.2.2.4 A JSON literal with values that ","sectionType":"division","heading":"4.2.2.4 A JSON literal with values that can be true or false.Date","content":"### 4.2.2.4 A JSON literal with values that can be true or false.Date\n\nRFC 3339 compliant date string that MUST conform to one of the following:\n\n YYYY\n YYYY-MM\n YYYY-MM-DD\n\nThis value is commonly used to represent birth dates.","sortOrder":184},{"sectionNumber":"4.2.2.5 DateTime","sectionType":"division","heading":"4.2.2.5 DateTime","content":"### 4.2.2.5 DateTime\n\nRFC 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:\n\n YYYY-MM-DDTHH:MM:SSZ\n YYYY-MM-DDTHH:MMZ","sortOrder":185},{"sectionNumber":"4.2.2.6 Unix Timestamp","sectionType":"division","heading":"4.2.2.6 Unix Timestamp","content":"### 4.2.2.6 Unix Timestamp\n\nA 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.\n\nNote: Follows the same format as the OIDC updated\\_at claim outlined in section 5.1 of the OpenID Connect Core 1.0 profile.","sortOrder":186},{"sectionNumber":"4.2.2.7 Email","sectionType":"division","heading":"4.2.2.7 Email","content":"### 4.2.2.7 Email\n\nA 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.","sortOrder":187},{"sectionNumber":"4.2.2.8 PhoneNumber","sectionType":"division","heading":"4.2.2.8 PhoneNumber","content":"### 4.2.2.8 PhoneNumber\n\nA 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.","sortOrder":188},{"sectionNumber":"4.2.2.9 UUID","sectionType":"division","heading":"4.2.2.9 UUID","content":"### 4.2.2.9 UUID\n\nA JSON string that MUST be at most 36 characters in length and is generated in accordance with RFC 4122.\n\nSelection 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.","sortOrder":189},{"sectionNumber":"4.2.3 Complex data types","sectionType":"division","heading":"4.2.3 Complex data types","content":"### 4.2.3 Complex data types","sortOrder":190},{"sectionNumber":"4.2.3.1 Other Names Object","sectionType":"division","heading":"4.2.3.1 Other Names Object","content":"### 4.2.3.1 Other Names Object\n\nAn 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.\n\nAt least one value of the claims MUST be present for the Other Name Object to be valid.\n\nTable 49 Other Names Object fields\n\n| Attribute | Claim/Field name | Required |\n| ----------- | ---------------- | -------- |\n| Family Name | family_name | Y |\n| Given Name | given_name | N |\n| Middle Name | middle_name | N |\n| Full Name | full_name | Y |","sortOrder":191},{"sectionNumber":"4.2.3.2 Address Object","sectionType":"division","heading":"4.2.3.2 Address Object","content":"### 4.2.3.2 Address Object\n\nThe 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.\n\nTable 50 Address Object fields definitions\n\n| Attribute | Field name | Data type | Required |\n| -------------- | -------------- | ----------------------------------------- | -------- |\n| Address Type | address_type | URN from values outlined in Table 33above | Y |\n| Formatted | formatted | string | N |\n| Street Address | street_address | string | Y |\n| Locality | locality | string | Y |\n| Region | region | string | Y |\n| Post Code | post_code | string | Y |\n| Country | country | string | N |\n| Validated | validated | Boolean | Y |","sortOrder":192},{"sectionNumber":"4.2.3.3 Other Email Address Object","sectionType":"division","heading":"4.2.3.3 Other Email Address Object","content":"### 4.2.3.3 Other Email Address Object\n\nThe Other Email Address Object is a JSON Object that is intended to be used for the self-asserted other email address scope and claim.\n\nThe 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.\n\nTable 51 Other Email Address type field definitions\n\n| Attribute | Field name | Data type | Required |\n| --------------- | --------------- | ------------------------------------------------ | -------- |\n| Email | email | Email | Y |\n| Email Validated | email_validated | Boolean | Y |\n| Contact Type | contact_type | URN from the values prescribed in Table 35 above | Y |","sortOrder":193},{"sectionNumber":"4.2.3.4 Other Phone Number Object","sectionType":"division","heading":"4.2.3.4 Other Phone Number Object","content":"### 4.2.3.4 Other Phone Number Object\n\nThe Other Phone Number Type is a JSON Object that is intended to be sued for the self-asserted other phone numbers scope and claim.\n\nThe 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.\n\nTable 52 Other Phone Number type field definitions\n\n| Attribute | Field name | Data type | Required |\n| -------------------------- | --------------------- | ------------------------------------------------ | -------- |\n| Other Phone | other_phone | Phone | Y |\n| Other Phone Validated | other_phone_validated | Boolean | Y |\n| Other Phone Telephony Type | telephony_type | URN from the values prescribed in Table 34 above | Y |\n| Contact Type | contact_type | URN from the values prescribed in Table 35 above | Y |","sortOrder":194},{"sectionNumber":"4.3.1 Core","sectionType":"division","heading":"4.3.1 Core","content":"### 4.3.1 Core\n\nEach 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.\n\nTable 53 Core claim requirements\n\n| Claim | AGDIS data type | Requirements |\n| -------------------- | ------------------ | ----------------------------------------------------------------------------------------------------------------- |\n| name | RequiredNameString | Value MUST be a concatenation of given_name, middle_name and family_name.The joining character SHOULD be a space. |\n| family_name | RequiredNameString | MUST NOT be an empty string. |\n| given_name | NameString | MAY be excluded from attribute responses when value is an empty string. |\n| middle_name | NameString | MAY be excluded from attribute responses when value is an empty string. |\n| birthdate | Date | SHOULD be validated to ensure dates that satisfying the RFC 3339 format and are reasonable. |\n| updated_at | Unix Timestamp | MUST be derived from the most recently updated Core Attribute. |\n| tdif_core_updated_at | Unix Timestamp | IXPs MUST NOT broker this claim to PRPs.ISPs MUST supply this claim. |","sortOrder":196},{"sectionNumber":"4.3.2 Validated Contact Details","sectionType":"division","heading":"4.3.2 Validated Contact Details","content":"### 4.3.2 Validated Contact Details\n\nAs 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.\n\nAll claims MUST be returned when fulfilling the email and phone scopes.\n\nAn ISP MUST not fulfill this request if the related email or phone number have not been validated.\n\nTable 54 Requirements for Validated Email claims\n\n| Claim | AGDISdata type | Required for scope | Constraints |\n| --------------------- | -------------- | ------------------ | ---------------------------------------------------------------------------------------------------- |\n| email | Email | Y | |\n| email_verified | Boolean | Y | If the email has not been successfully validated the scope for these claims should not be fulfilled. |\n| tdif_email_updated_at | Unix Timestamp | Y | |\n\nTable 55 Requirements for Validated Phone Number claims\n\n| Claim | AGDISdata type | Required for scope | Constraints |\n| ---------------------------- | -------------- | ------------------ | ----------------------------------------------------------------------------------------------------------- |\n| phone | Phone Number | Y | |\n| phone_verified | Boolean | Y | If the phone number has not been validated successfully the scope for these claims should not be fulfilled. |\n| tdif_phone_number_updated_at | Unix Timestamp | Y | |","sortOrder":197},{"sectionNumber":"4.3.3 Verified Other Names","sectionType":"division","heading":"4.3.3 Verified Other Names","content":"### 4.3.3 Verified Other Names\n\nThe Verified Other Names scope and claim uses the Other Names object for each of the verified other names returned in an attribute request.\n\nAn 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.\n\nAn ISP fulfilling this request MUST return a JSON array of Other Name object when two or more Other Verified Names are available.","sortOrder":198},{"sectionNumber":"4.3.4 Verified Documents","sectionType":"division","heading":"4.3.4 Verified Documents","content":"### 4.3.4 Verified Documents\n\nA 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.\n\nThe 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.\n\nAn attribute response for multiple verified documents MUST be serialised as a JSON Array of Verified Document Objects.\n\nAn 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.\n\nUsing 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.","sortOrder":199},{"sectionNumber":"4.3.4.1 Document Identifiers Object","sectionType":"division","heading":"4.3.4.1 Document Identifiers Object","content":"### 4.3.4.1 Document Identifiers Object\n\nThe Document Identifiers field of a Verified Document Object is a JSON Object with keys and values determined by the parent objects document type.\n\nThe 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.\n\nFor a Document Identifiers Object to be valid it MUST:\n\n (a) only have keys that map to the parent object’s Document Type field; and\n (b) be compliant with value data types prescribed in Table 58 below for a given identifier.\n\nTable 58 Verified Document Identifiers with data types\n\n| Document identifier string | Value data type | Value requirements | Used by document types |\n| -------------------------- | --------------- | ------------------------------------------------------------------------------- | ---------------------- |\n| Registration Number | string | Maximum length 10 characters.Only available for ACT, NT, NSW, TAS, VIC, and WA. | BC, MC, NC |\n| Registration Date | Date | - | BC, MC, NC |\n| Registration Year | Number | Integer value for the year. | BC, MC, NC |","sortOrder":200},{"sectionNumber":"4.3.4.2 Document Names Object","sectionType":"division","heading":"4.3.4.2 Document Names Object","content":"### 4.3.4.2 Document Names Object\n\nThe Document Names Object field of a Verified Document Object is a JSON Object with keys and values determined by the parent objects document type.\n\nThe 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","sortOrder":201},{"sectionNumber":"4.3.4.3 Document Attributes Object","sectionType":"division","heading":"4.3.4.3 Document Attributes Object","content":"### 4.3.4.3 Document Attributes Object\n\nThe Document Attributes field of a Verified Document Object is a JSON Object with keys and values determined by the parent objects document type.\n\nThe 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.\n\nFor a Document Identifiers Object to be valid it MUST:\n\n only comprise keys that map to the parent object’s Document Type field; and\n have values that are compliant with data types prescribed in Table 60 below for a given identifier.\n\nTable 60 Verified Document Attributes with data types\n\n| Document attribute string | Value data type | Value requirements | Used by document types |\n| ------------------------- | --------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------- |\n| Registration State | string | An up to 3 letter abbreviation of the registration state name.See Table 13 above for accepted values. | BC, MC, NC |\n| Date of Event | Date | DVS valid dates are between 1753-01-01 to 3000-12-31. | MC |\n| Acquisition Date | Date | DVS valid dates are between 1753-01-01 to 3000-12-31. | CC, RDDVS request input field but is not checked. |","sortOrder":202},{"sectionNumber":"4.4","sectionType":"part","heading":"Identity System Metadata","content":"## 4.4 Identity System Metadata\n\n### 4.4.1 Common\n\nOpenID Connect Core 1.0 data representation for the common attribute sets defined in section 2.2.1 of this Schedule.\n\nTable 61 Common attributes definition\n\n| Claim | AGDIS Data Type | Constraints |\n| ---------- | ------------------ | ------------------------------------------------------ |\n| sub | string | Maximum length 255 characters. |\n| auth_time | Unix Timestamp | - |\n| acr | URNorArray of URNs | See section 2.2.1.3, section 4.4.1.3 of this Schedule. |\n| amr | URN | Must be one of the values outlined in Table 30 above. |\n| updated_at | Unix Timestamp | - |\n\n### 4.4.1.1 Subject ID\n\nCommonly 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.\n\nISPs and IXPs assigned subject IDs MUST be conform to the requirements outlined in section 1.2 of Schedule 1 (AGDIS Onboarding Specifications).\n\n### 4.4.1.2 Authentication Time\n\nAn ISP MUST implement support for authentication time, the auth\\_time claim, as outlined in Table 47 above.\n\n### 4.4.1.3 Assurance Level\n\nWhen 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","sortOrder":203},{"sectionNumber":"4.4.1 Common","sectionType":"division","heading":"4.4.1 Common","content":"### 4.4.1 Common\n\nOpenID Connect Core 1.0 data representation for the common attribute sets defined in section 2.2.1 of this Schedule.\n\nTable 61 Common attributes definition\n\n| Claim | AGDIS Data Type | Constraints |\n| ---------- | ------------------ | ------------------------------------------------------ |\n| sub | string | Maximum length 255 characters. |\n| auth_time | Unix Timestamp | - |\n| acr | URNorArray of URNs | See section 2.2.1.3, section 4.4.1.3 of this Schedule. |\n| amr | URN | Must be one of the values outlined in Table 30 above. |\n| updated_at | Unix Timestamp | - |","sortOrder":204},{"sectionNumber":"4.4.1.1 Subject ID","sectionType":"division","heading":"4.4.1.1 Subject ID","content":"### 4.4.1.1 Subject ID\n\nCommonly 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.\n\nISPs and IXPs assigned subject IDs MUST be conform to the requirements outlined in section 1.2 of Schedule 1 (AGDIS Onboarding Specifications).","sortOrder":205},{"sectionNumber":"4.4.1.2 Authentication Time","sectionType":"division","heading":"4.4.1.2 Authentication Time","content":"### 4.4.1.2 Authentication Time\n\nAn ISP MUST implement support for authentication time, the auth\\_time claim, as outlined in Table 47 above.","sortOrder":206},{"sectionNumber":"4.4.1.3 Assurance Level","sectionType":"division","heading":"4.4.1.3 Assurance Level","content":"### 4.4.1.3 Assurance Level\n\nWhen 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","sortOrder":207},{"sectionNumber":"4.4.1.4 Authentication Method","sectionType":"division","heading":"4.4.1.4 Authentication Method","content":"### 4.4.1.4 Authentication Method\n\nWhen 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.\n\nThe addition of other values Internet Assigned Numbers Authority registered in line with the specification for the Authentication Method Reference response are permitted.","sortOrder":208},{"sectionNumber":"4.4.1.5 Last Updated","sectionType":"division","heading":"4.4.1.5 Last Updated","content":"### 4.4.1.5 Last Updated\n\nAn ISP MUST implement support for this claim as outlined in Table 44 above using a Unix Timestamp.","sortOrder":209},{"sectionNumber":"4.4.2 Audit","sectionType":"division","heading":"4.4.2 Audit","content":"### 4.4.2 Audit\n\nThe claim outlined in this section is for the RP Audit ID only.\n\nAudit and transaction identifiers for the ISP to IXP transactions are left to the discretion of IXPs and accordingly not defined here.\n\nTable 62 Audit attribute definitions\n\n| Claim | AGDISdata type | Constraints |\n| ------------- | -------------- | ----------- |\n| tdif_audit_id | UUID | - |","sortOrder":210},{"sectionNumber":"4.4.2.1 RP Audit Identifier","sectionType":"division","heading":"4.4.2.1 RP Audit Identifier","content":"### 4.4.2.1 RP Audit Identifier\n\nAn IXP MUST implement RP Audit ID, the tdif\\_audit\\_id claim, as outlined in section 2.2.2.1 of this Schedule.","sortOrder":211},{"sectionNumber":"4.5","sectionType":"part","heading":"Self-Asserted Attributes","content":"## 4.5 Self-Asserted Attributes\n\nAssumed 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.","sortOrder":212},{"sectionNumber":"4.5.1 Preferred Name","sectionType":"division","heading":"4.5.1 Preferred Name","content":"### 4.5.1 Preferred Name\n\nThe 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.","sortOrder":213},{"sectionNumber":"4.5.2 Addresses","sectionType":"division","heading":"4.5.2 Addresses","content":"### 4.5.2 Addresses\n\nThe Address claim MAY represent one or more Address Objects.","sortOrder":214},{"sectionNumber":"4.5.3 Other Email Addresses","sectionType":"division","heading":"4.5.3 Other Email Addresses","content":"### 4.5.3 Other Email Addresses\n\nThe Other Email Addresses scope MUST only return the default email address nominated by the individual.\n\nThe Other Email Address claim MAY represent one or more Other Email Address Objects.\n\nA 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.\n\nA request for one or more other email addresses MUST be returned as a JSON array of Other Email Address Objects.\n\nAn 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.\n\nA request MAY include the default contact type along with other contact type URNs.\n\n{ \n…, \n“userinfo”: { \n…, \n“agdis\\_address”: { \n“values”: \\[ \n“urn:id.gov.au:agdis:address:default”, \n“urn:id.gov.au:agdis:address:residential” \n\\] \n}, \n… \n}, \n… \n}\n\nFigure 2 Self-asserted address sample claim request","sortOrder":215},{"sectionNumber":"4.5.4 Other Phone Numbers","sectionType":"division","heading":"4.5.4 Other Phone Numbers","content":"### 4.5.4 Other Phone Numbers\n\nThe Other Phone Numbers scope request MUST only return the default other phone number nominated by the individual.\n\nThe Other Phone Numbers claim MAY represent one or more Other Phone Number Objects.\n\nA 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.\n\nA request for one or more other phone numbers MUST be returned as a JSON array of Other Phone Number Objects.\n\nAn 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.","sortOrder":216},{"sectionNumber":"4.5.5 Place of Birth","sectionType":"division","heading":"4.5.5 Place of Birth","content":"### 4.5.5 Place of Birth\n\nPlace of Birth MUST be a non-empty string with a maximum length of 255 characters.","sortOrder":217},{"sectionNumber":"4.5.6 Personal Titles","sectionType":"division","heading":"4.5.6 Personal Titles","content":"### 4.5.6 Personal Titles\n\nA personal title MUST be a non-empty string with a maximum length of 100 characters.","sortOrder":218},{"sectionNumber":"4.6","sectionType":"part","heading":"Computed Attributes Data Definitions","content":"## 4.6 Computed Attributes Data Definitions\n\nPresently no Computed Attributes are defined in this Schedule.","sortOrder":219},{"sectionNumber":"4.7","sectionType":"part","heading":"Attribute Service Providers","content":"## 4.7 Attribute Service Providers\n\nThe OpenID Connect attribute for AGDIS ASP is presented in this section.","sortOrder":220},{"sectionNumber":"4.7.1 Business Authorisations","sectionType":"division","heading":"4.7.1 Business Authorisations","content":"### 4.7.1 Business Authorisations\n\nThe 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.\n\nAs the ASP providing these attributes RAM SHOULD provide guidance to PRPs consuming these attributes to support use.\n\nTable 64 Business Authorisation data representation\n\n| Field | OIDC payload field name | Data type | Constraints |\n| ----------------------------- | ----------------------- | ------------ | ---------------------------------------------------------------------------------------------------------- |\n| Schemas | schemas | Arry of URNs | MUST contain a URN that maps to the schema version follow the format defined in Table 39 above. |\n| 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. |\n| Entity ID | subjectId | string | A JSON string that MUST adhere the lengths constraints of the entity type. |\n| Entity Type | subjectIdType | string | A value from the enumeration defied in Table 41 above. |","sortOrder":221},{"sectionNumber":"4.7.2 myGov","sectionType":"division","heading":"4.7.2 myGov","content":"### 4.7.2 myGov\n\nDetailed definition of the data representation for the myGov linkID is not defined in this Schedule.\n\nAn IXP or a PRP seeking further information on the format of this attribute SHOULD consult the myGov member service documentation.","sortOrder":222},{"sectionNumber":"4.8","sectionType":"part","heading":"Normative OIDC Profile Attribute Examples","content":"## 4.8 Normative OIDC Profile Attribute Examples\n\n### 4.8.1 Core\n\nEach Core Attribute example is presented on its own. In practice these values would be presented in the ID Token or UserInfo response.\n\nTable 65 Core Attributes normative examples for claims\n\n| Attribute | OIDC Claim | Normative Example |\n| ------------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Family Name Full Name | family_name name | Valid:“family_name”: “Moore”“name”: “John David Citizen”Invalid“family_name”: “”“family_name”: “family_name”: null |\n| Given Name Middle Name Preferred Name | given_name middle_name preferred_username | Valid:“given_name”: “Trentino”“given_name”: “”Invalid:“given_name”: “given_name”: null |","sortOrder":223},{"sectionNumber":"4.8.1 Core","sectionType":"division","heading":"4.8.1 Core","content":"### 4.8.1 Core\n\nEach Core Attribute example is presented on its own. In practice these values would be presented in the ID Token or UserInfo response.\n\nTable 65 Core Attributes normative examples for claims\n\n| Attribute | OIDC Claim | Normative Example |\n| ------------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Family Name Full Name | family_name name | Valid:“family_name”: “Moore”“name”: “John David Citizen”Invalid“family_name”: “”“family_name”: “family_name”: null |\n| Given Name Middle Name Preferred Name | given_name middle_name preferred_username | Valid:“given_name”: “Trentino”“given_name”: “”Invalid:“given_name”: “given_name”: null |","sortOrder":224},{"sectionNumber":"4.8.2 Validated Contact Details","sectionType":"division","heading":"4.8.2 Validated Contact Details","content":"### 4.8.2 Validated Contact Details\n\nNote grouped examples claims are where the data types are the same. The examples provided for the group claims may be used interchangeably.\n\nTable 66 Validated contact details normative examples for claims\n\n| Attribute | OIDC Claim | Normative Example |\n| --------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------- |\n| Validated Email | email | Valid:“email”: “jane.citizen@example.com”Invalid“email”: null“email”: “malformed.email.address” |\n| Validated Phone | phone_number | Valid:“given_name”: “Trentino”“given_name”: “”Invalid:“given_name”: “given_name”: null |","sortOrder":225},{"sectionNumber":"4.8.3 Verified Other Names","sectionType":"division","heading":"4.8.3 Verified Other Names","content":"### 4.8.3 Verified Other Names\n\nTable 68 Verified other names normative examples for claims\n\n| Attribute | OIDC Claim | Normative Example |\n| -------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Verified Other Names | tdif_other_names | ValidSingle Other Verified Name available (no array):“tdif_other_names”: { “family_name”: “Moore”, “given_name”: “Trentino”}ValidSingle Other Verified Name available in an array:“tdif_other_names”: [{“family_name”: “Moore”, “given_name”: “Trentino” }] |","sortOrder":226},{"sectionNumber":"4.8.4 Verified Documents","sectionType":"division","heading":"4.8.4 Verified Documents","content":"### 4.8.4 Verified Documents","sortOrder":227},{"sectionNumber":"4.8.4.1 Birth Certificate","sectionType":"division","heading":"4.8.4.1 Birth Certificate","content":"### 4.8.4.1 Birth Certificate\n\nTable 69 Birth certificate verified document claim normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:BC\", \"verification_method\": \"S\",

\"verification_date\": \"2022-12-06T23:21:19.0231031Z\", \"names\": {

\"family_name\": \"Maximus\", \"given_name\": \"Michael\"

},

\"birthdate\": \"1989-01-03\",

verification_method

Y

verification_date

Y

names2

family_name

Y

given_name

Y

birthdate

Y

identifiers3

Registration Number

N

Certificate Number

N

attributes

Registration Date

N

\n```\n\n![](image.008.png) \n\n2 On birth certificates issued by the NSW, VIC, WA BDM, given name may be left blank if family name has a value, and family name may be left blank if given name has a value.\n\n3 The identifiers used for birth certificates will vary significantly depending on the state and territory which issued the birth certificate.","sortOrder":228},{"sectionNumber":"4.8.4.2 Centrelink Concession Card","sectionType":"division","heading":"4.8.4.2 Centrelink Concession Card","content":"### 4.8.4.2 Centrelink Concession Card\n\nTable 70 Centrelink concession card verified document claim normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:CO\", \"verification_method\": \"S\",

\"verification_date\": \"2022-12-06T23:21:19.0231031Z\", \"names\": {

\"name\": \"Jane Citizen\"

},

\"birthdate\": \"1976-02-15\", \"identifiers\": [

{

\"type\": \"CRN\", \"value\": \"1234567890\"

verification_method

Y

verification_date

Y

names

name

Y

birthdate

N

identifiers

CRN

Y

attributes

CardExpiry

Y

CardType

Y

\n```","sortOrder":229},{"sectionNumber":"4.8.4.3 Change of Name Certificate","sectionType":"division","heading":"4.8.4.3 Change of Name Certificate","content":"### 4.8.4.3 Change of Name Certificate\n\nPlease see footnotes 2 and 3 in Table 69 to clarify name handling.\n\nTable 71 Change of Name Certificate verified document claim normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:NC\", \"verification_method\": \"S\",

\"verification_date\": \"2022-12-07T00:52:48.2Z\", \"names\": {

\"family_name\": \"Southsoil\", \"given_name\": \"Jakub\"

},

\"birthdate\": \"1992-12-07\", \"identifiers\": [

verification_method

Y

verification_date

Y

names4

family_name

Y

given_name

Y

birthdate

N

identifiers

Registration Number

N

Certificate Number

N

attributes

Registration Date

N

Registration State

Y

\n```\n\n![](image.008.png) \n\n4 For Change of Name Certificates issued by the NSW, VIC or WA BDM, given name may be left blank if family name has a value, and family name may be left blank if given name has a value.","sortOrder":230},{"sectionNumber":"4.8.4.4 Citizenship Certificate","sectionType":"division","heading":"4.8.4.4 Citizenship Certificate","content":"### 4.8.4.4 Citizenship Certificate\n\nTable 72 Citizenship Certificate verified document claim normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:CC\", \"verification_method\": \"S\",

\"verification_date\": \"2022-12-06T23:22:01.6116772Z\", \"names\": {

\"family_name\": \"Doe\", \"given_name\": \"John\"

},

\"birthdate\": \"1986-04-18\", \"identifiers\": [

{

verification_method

Y

verification_date

Y

names

family_name

Y

given_name

N

birthdate

Y

identifiers

Stock Number

Y

attributes5

\n```\n\n![](image.008.png) \n\n5 Please note that the Acquisition Date field, while requested input for the DVS, is not checked nor is it currently available on the AGDIS.","sortOrder":231},{"sectionNumber":"4.8.4.5 Registration by Descent Certific","sectionType":"division","heading":"4.8.4.5 Registration by Descent Certificate","content":"### 4.8.4.5 Registration by Descent Certificate\n\nTable 73 Registration by Descent Certificate verified document normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:RD\", \"verification_method\": \"S\",

\"verification_date\": \"2022-12-06T23:22:01.6116772Z\", \"names\": {

\"family_name\": \"Citizen\", \"given_name\": \"Birdy\"

},

\"birthdate\": \"1986-04-18\", \"identifiers\": [

{

verification_method

Y

verification_date

Y

names

family_name

Y

given_name

N

birthdate

Y

identifiers

Stock Number

Y

attributes6

\n```\n\n![](image.008.png) \n\n6 Please note that the Acquisition Date field, while supported by requested input for the DVS, is not checked nor is it currently available on the AGDIS","sortOrder":232},{"sectionNumber":"4.8.4.6 Australian Driver Licence","sectionType":"division","heading":"4.8.4.6 Australian Driver Licence","content":"### 4.8.4.6 Australian Driver Licence\n\nTable 74 Australian Driver Licence verified document normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:DL\", \"verification_method\": \"S\",

\"verification_date\": \"2022-12-06T23:22:01.6116772Z\", \"names\": {

\"family_name\": \"Bisan\", \"given_name\": \"Wizard\"

},

\"birthdate\": \"1986-04-18\",

verification_method

Y

verification_date

Y

names

family_name

Y

given_name

Y

middle_name

N

birthdate

Y

identifiers

Licence Number

Y

Card Number7

N

attributes

State of Issue

Y

\n```\n\n![](image.008.png) \n\n7 If Card Number is recorded by an ISP, it is expected to be passed as part of a Driver Licence. Refer to DVS Match Specification Driver Licence for details of Driver Licence Card Number across jurisdictions.","sortOrder":233},{"sectionNumber":"4.8.4.7 ImmiCard","sectionType":"division","heading":"4.8.4.7 ImmiCard","content":"### 4.8.4.7 ImmiCard\n\nTable 75 ImmiCard verified document normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:IM\", \"verification_method\": \"S\",

\"verification_date\": \"2022-12-06T23:22:01.6116772Z\", \"names\": {

\"family_name\": \"Moore\", \"given_name\": \"Trentino Bici\"

verification_method

Y

verification_date

Y

names

family_name

Y

given_name

Y

birthdate

Y

identifiers

ImmiCard Number

Y

attributes

empty

Y

\n```","sortOrder":234},{"sectionNumber":"4.8.4.8 Marriage Certificate","sectionType":"division","heading":"4.8.4.8 Marriage Certificate","content":"### 4.8.4.8 Marriage Certificate\n\nTable 76 Marriage Certificate verified document normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:MC\", \"verification_method\": \"S\",

\"verification_date\": \"2022-12-06T23:21:19.0231031Z\", \"names\": {

\"family_name\": \"O’Keeffe\", \"given_name\": \"Mickey\", \"family_name2\": \"Louis\", \"given_name2\": \"Jesse\"

},

\"birthdate\": \"1989-01-03\", \"identifiers\": [

verification_method

Y

verification_date

Y

names

family_name

Y

given_name

Y

family_name2

Y

given_name2

Y

birthdate

Y

identifiers

Registration Number

N

Certificate Number

N

attributes

Registration Date

N

Registration State

Y

\n```","sortOrder":235},{"sectionNumber":"4.8.4.9 Medicare Card","sectionType":"division","heading":"4.8.4.9 Medicare Card","content":"### 4.8.4.9 Medicare Card\n\nTable 77 Medicare Card verified documents normative example","sortOrder":236},{"sectionNumber":"4.8.4.10 Australian Travel Document","sectionType":"division","heading":"4.8.4.10 Australian Travel Document","content":"### 4.8.4.10 Australian Travel Document\n\nTable 78 Australian Travel Document verified document normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:PP\",

\"verification_method\": \"S\",

\"verification_date\": \"2022-12-06T23:22:01.6116772Z\",

\"names\": {

\"family_name\": \"Mason\",

\"given_name\": \"Master\"

},

\"birthdate\": \"1930-04-18\",

\"identifiers\": [

{

\"type\": \"Travel Document Number\",

\"value\": \"PA0002020\"

}

],

\"attributes\": [

{

“type”: “Gender”,

“value”: “F”

}

]

}

verification_method

Y

verification_date

Y

names

family_name

Y

given_name

N

birthdate

Y

identifiers

Travel Document Number

Y

attributes

Gender

N

\n```","sortOrder":237},{"sectionNumber":"4.8.4.11 Visa","sectionType":"division","heading":"4.8.4.11 Visa","content":"### 4.8.4.11 Visa\n\nTable 79 Visa verified documents normative example\n\n```html\n

Field

Sub-field(s)

Required

Example

type_code

Y

{

\"type_code\": \"urn:id.gov.au:tdif:doc:type_code:VI\", \"verification_method\": \"S\",

\"verification_date\": \"2022-12-06T23:22:01.6116772Z\", \"names\": {

\"family_name\": \"Vino\", \"given_name\": \"Trentino\"

},

\"birthdate\": \"1962-08-10\", \"identifiers\": [

{

\"type\": \"Passport Number\",

verification_method

Y

verification_date

Y

names

family_name

Y

given_name

Y

birthdate

Y

identifiers

Passport Number

Y

attributes

\n```","sortOrder":238},{"sectionNumber":"4.8.5 Identity System Metadata","sectionType":"division","heading":"4.8.5 Identity System Metadata","content":"### 4.8.5 Identity System Metadata","sortOrder":239},{"sectionNumber":"4.8.5.1 Digital ID Pairwise Identifier","sectionType":"division","heading":"4.8.5.1 Digital ID Pairwise Identifier","content":"### 4.8.5.1 Digital ID Pairwise Identifier\n\nTable 80 Digital ID pairwise examples\n\n| Attribute | OIDC Claim | Normative Example |\n| ------------------------------ | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Digital ID Pairwise Identifier | sub | Valid:“sub”: “234932875989812”“sub”: Invalid:“sub”: “sub”: null“sub”: 123145124 |","sortOrder":240},{"sectionNumber":"4.8.5.2 Authentication Time and Updated ","sectionType":"division","heading":"4.8.5.2 Authentication Time and Updated At","content":"### 4.8.5.2 Authentication Time and Updated At\n\nTable 81 Authentication time and Update at examples\n\n| Attribute | OIDC Claim | Normative Example |\n| -------------------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| Authentication Time Last Updated | auth_time updated_at | Valid:“auth_time”: 1711929600“updated_at”: 1585699200Invalid:“auth_time”: “1711929600”“updated_at”: “20240401T00:00Z” |","sortOrder":241},{"sectionNumber":"4.8.5.3 Authentication Method","sectionType":"division","heading":"4.8.5.3 Authentication Method","content":"### 4.8.5.3 Authentication Method\n\nTable 82 Authentication Method examples\n\n| Attribute | OIDC Claim | Normative Example |\n| ------------------------------- | ---------- | ------------------------------------------------------------------------------ |\n| Authentication Method Reference | amr | Valid:“amr”: [“urn:id.gov.au:idp:myid”]Invalid:“amr”: “urn:id.gov.au:idp:myid” |","sortOrder":242},{"sectionNumber":"4.8.5.4 Audit Identifiers","sectionType":"division","heading":"4.8.5.4 Audit Identifiers","content":"### 4.8.5.4 Audit Identifiers\n\nTable 83 Audit Identifier examples\n\n| Attribute | OIDC Claim | Informative Example |\n| ----------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------- |\n| RP Audit ID | tdif_audit_id | Valid:“tdif_audit_id”: “702b45ce-d2d6-451d-84cd-9fbcf299533b”Invalid:“tdif_audit_id”: 4093809“tdif_audit_id”: “”“tdif_audit_id”: null |","sortOrder":243},{"sectionNumber":"4.8.6 Self-Asserted Attributes","sectionType":"division","heading":"4.8.6 Self-Asserted Attributes","content":"### 4.8.6 Self-Asserted Attributes","sortOrder":244},{"sectionNumber":"4.8.6.1 Addresses","sectionType":"division","heading":"4.8.6.1 Addresses","content":"### 4.8.6.1 Addresses\n\nTable 84 Addresses normative examples\n\n| Attribute | OIDC Claim | Normative Example |\n| --------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Addresses | agdis_address | Valid all fields:{“address_type”: “urn:id.gov.au:agdis:address:postal”, “street_address”: “1 Canberra Ave”,“locality”: “Forrest”, “region”: “ACT”,“post_code”: “2603”, “country”: “Australia”,“formatted”: “1 Canberra Ave\\nForrest ACT 2603\\nAustralia”, “validated”: false}Valid only required fields:{“address_type”: “urn:id.gov.au:agdis:address:postal”, “street_address”: “1 Canberra Ave”,“locality”: “Forrest”, “region”: “ACT”,“post_code”: “2603”, “validated”: false} |","sortOrder":245},{"sectionNumber":"4.8.6.2 Other Email Addresses","sectionType":"division","heading":"4.8.6.2 Other Email Addresses","content":"### 4.8.6.2 Other Email Addresses\n\nTable 85 Other Email Addresses\n\n| Attribute | OIDC Claim | Normative Example |\n| --------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Other Email Addresses | agdis_other_email | Valid:{“email”: “jane.cizten@exmaplebusiness.com.au”, “email_validated”: false,“contact_type”: “urn:id.gov.au:agdis:contact:business”}{“email”: “jane.cizten@exmaple.com.au”, “email_validated”: true,“contact_type”: “urn:id.gov.au:agdis:contact:other”}Invalid:{“email”: “not-a-valid-email”, “email_validated”: true,“contact_type”: “urn:id.gov.au:agdis:contact:other”} |","sortOrder":246},{"sectionNumber":"4.8.6.3 Other Phone Numbers","sectionType":"division","heading":"4.8.6.3 Other Phone Numbers","content":"### 4.8.6.3 Other Phone Numbers\n\nTable 86 Other Phone Numbers normative examples\n\n| Attribute | OIDC Claim | Normative Example |\n| ------------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Other Phone Numbers | agdis_other_phone_numbers | Valid individual claims:{“other_phone”: “+83 (4) 555 2401”, “other_phone validated”: false, “telephony type”: mobile,“contact_type”: “urn:id.gov.au:agdis:contact:personal”}Invalid:{“other_phone”: “not a valid number”, “other_phone validated”: false, “telephony type”: mobile,“contact_type”: “urn:id.gov.au:agdis:contact:personal} |","sortOrder":247},{"sectionNumber":"4.8.6.4 Personal Title Normative Example","sectionType":"division","heading":"4.8.6.4 Personal Title Normative Examples","content":"### 4.8.6.4 Personal Title Normative Examples\n\nTable 88 Personal Titles Normative Examples\n\n| Attribute | OIDC Claim | Normative Example |\n| -------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Personal Title | agdis_personal_title | Valid:“agdis_personal_title”: “Professor”“agdis_personal_title”: Invalid:“agdis_personal_title”: “”“agdis_personal_title”: null“agdis_personal_title”: |","sortOrder":248},{"sectionNumber":"4.8.7 Business Authorisations","sectionType":"division","heading":"4.8.7 Business Authorisations","content":"### 4.8.7 Business Authorisations\n\nTable 89 Business Authorisations\n\n| Attribute | OIDC Scope and Claim | Normative Example |\n| ----------------------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Business Authorisations | tdif_business_authorisations | {\"schemas\": [\"urn:id.gov.au:tdif:authorisations:business:1.0\"],\"id\": \"78dfcb8c-dbb7-4c36-9807-70125dca90ca\", \"subjectId\": \"49090058647\",\"subjectIdType\": \"ABN\", \"subjectName\": \"ALTONWAY LTD\", \"relationshipType\":\"ASSOCIATE\",\"startTimestamp\":\"2019-08-09T14:00:00Z\", \"endTimestamp\":null,\"attributes\":[{\"name\":\"pid\",\"value\":\"668\"},{\"name\":\"subId\",\"value\":\"ABRP:49090058647_668\"},{\"name\":\"previousPid\",\"value\":null},{\"name\":\"previousSubId\",\"value\":null}],\"permissions\":[ \"QLD_IDENTITY_LOGIN/FULL\"],\"roles\":[\"AUTHORISATION_ADMINISTRATOR\", \"MACHINE_CREDENTIAL_ADMINISTRATOR\", \"PRINCIPAL_AUTHORITY\"],\"email\": \"IndustryRDTI1@test.gov.au\", \"lastModified\": \"2021-01-04T00:20:14.2453821Z\"} |","sortOrder":249}],"analysis":{"flash_summary":{"complexity_score":8,"scope_assessment":{"changed":false,"description":"From the content supplied, the instrument stays within the technical and operational scope of a data and protocol standard for a federated digital identity ecosystem: it specifies how participants must authenticate, broker protocols, share attributes and log/audit transactions. The inclusion of extensive attribute schemas (verified documents, business authorisations, myGov linkID) increases operational detail compared with a minimal protocol profile, but that is consistent with a standards instrument intended to define precise interoperability and data formats rather than a substantive expansion of policy objectives. There is no clear evidence in the text provided that the instrument expands its regulatory scope beyond setting technical, privacy and data-sharing obligations for accredited participants."},"complexity_factors":["Extensive cross-referencing across three schedules (Schedule 1 onboarding specs, Schedule 2 OpenID Connect profile, Schedule 3 Attribute Profile) and multiple external RFCs (RFC 6749, RFC 6819, RFC 7517, RFC 4122, RFC 7636, RFC 7591, RFC 6750, RFC 8529).","Many role-specific rule sets: separate and sometimes asymmetric obligations for IXPs, ISPs and ASPs (e.g. audit, identifier issuance, client registration, dynamic registration rules).","Large attribute model: dozens of attributes and attribute sets with per-attribute consent, fulfilment, access policy and JSON schema constraints (Schedule 3 Chapters 2–4).","Numerous specific, short token and assertion lifetime limits and strict crypto requirements (ID token ≤ 300s, access token ≤ 3600s, refresh ≤ 86400s; private_key_jwt only; jwks/jwks_uri validations).","Multiple conditional rules and mutual exclusivities (e.g. if ISP issues pairwise identifiers it MUST NOT issue a GPI; sector identifier one-to-one mappings).","Nested processing rules for brokering and claim/scope mapping, including prompt/claim/id_token_hint treatment and federation protocol translation logic (Schedule 2 §3 and §4 mappings).","Detailed per-document schemas (multiple verified-document schemas with many required fields and constraints — birth certificate, driver licence, passport, Medicare, ImmiCard, visa, etc.).","High repetition and duplicated sections in the draft text increasing maintenance and implementation interpretation risk."],"plain_english_summary":"**What this instrument does (mechanics)\n\n- 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).\n\n- 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.)\n\n- 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.)\n\n- 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.)\n\n- 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.)\n\n- 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.)\n\n- 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.)\n\n\nWho this affects (practical population)\n\n- Technical operators and vendors building or operating IXPs, ISPs and ASPs.\n- Downstream relying parties (PRPs) who request identity or attribute data through AGDIS.\n- Privacy, compliance and security teams inside participating agencies and vendors (because of consent, audit and crypto requirements).\n\n\nWhy it matters (practical consequences and behaviour changes)\n\n- 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.\n\n- 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.\n\n- 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).\n\n- 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).\n\n\nAnalytical lens — incentives, costs, trade-offs, and operational risks\n\n- 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).\n\n- 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.\n\n- 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).\n\n- 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.\n\n- 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).\n\n- 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).\n\n- 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).\n\n\nSelected concrete citations (where key obligations appear)\n\n- Security obligations: must comply with RFC 6749 §10 and consider RFC 6819 §5 (see §1.1 Security considerations).\n- Identity resolution rules: GPI rules and pairwise identifier requirements (see §1.2.1 and §1.2.2).\n- Audit ID: IXP generation of RP Audit ID and non-sharing with ISPs (see §2.1.2; Schedule 3 §2.2.2.1).\n- Protocol profile: implementation of Schedule 2 OpenID Connect profile and authorization_code-only flow (see §2.1.1/§1.8.1 and §1.6).\n- Client authentication: private_key_jwt only; JWT expiry ≤ 300s (see §1.8.1.2 / §1.7.2).\n- Token lifetimes: ID token ≤ 300s; access token ≤ 3,600s; refresh token ≤ 86,400s (see §1.8.3 & §1.8.3.1).\n- Attribute policies: all attributes transmitted across AGDIS MUST have an attribute sharing policy describing consent, fulfilment and access policy (see Schedule 3 §1.2).\n- Access policies: enumerated four-tier access policy (Open / Not available / Restricted / Platform) (see Schedule 3 §1.2.3).\n- User dashboard/consent: IXP obligations to provide dashboard and obtain consent prior to redirect (see §2.3; §1.10).\n\n\nBottom-line summary in one short paragraph\n\nThis 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)."},"flash_summary_failed":{"failed":true,"reason":"Unauthenticated. Configure AI_GATEWAY_API_KEY or use a provider module. Learn more: https://ai-sdk.dev/unauthenticated-ai-gateway","source":"analysis-cron"},"kimi_summary":{"_metrics":{"completionTokens":673},"content_quality":"ok","complexity_score":9,"scope_assessment":{"changed":false,"description":"The legislation appears consistent with its original purpose — establishing technical data standards for the Australian Government Digital ID System. The extensive detail on OpenID Connect implementation, attribute schemas, and document verification aligns with the stated goal of creating interoperable technical specifications for accredited entities."},"complexity_factors":["Extensive cross-referencing to external standards (RFC 6749, RFC 6819, RFC 7517, RFC 4122, OpenID Connect Core 1.0, ITU-T E.164)","Multiple nested schedules with interdependent requirements (Schedule 1 onboarding, Schedule 2 OpenID Connect profile, Schedule 3 attribute profile)","47+ defined terms including technical acronyms (IXP, ISP, ASP, PRP, TRP, GPI, OIDC, JWT, PKCE, SLO, SSO, ACR, AMR, URN)","Highly conditional logic with MUST/MAY/SHOULD/SHOULD NOT layered throughout","Document-specific validation rules with state/territory variations (e.g., NSW/VIC/WA birth certificates have different name field rules)","Cryptographic requirements including key rotation, JWT expiry windows (300 seconds), clock skew allowances","Four-tier access policy system (Open, Not available, Restricted, Platform) with entity-specific exceptions","Legacy acronym mapping required (cl to AL in URNs)","Duplicate and overlapping section numbering with repeated content throughout the instrument"],"plain_english_summary":"This law sets the technical rules for Australia’s Digital ID (AGDIS), telling accredited Identity Exchange Providers, Identity Service Providers and Attribute Service Providers how to handle identity data when Australians log into government and approved private services. It mandates strong security (short-lived tokens, encryption, key-based auth), privacy-preserving pairwise identifiers, user dashboards for consent, and strict data‑minimisation and verified‑document controls.\n\nIt’s the technical backbone enabling secure, privacy-preserving online identity and reduced password use across services."}},"importantCases":[],"_links":{"self":"/api/acts/digital-id-agdis-data-standards-2024","history":"/api/acts/digital-id-agdis-data-standards-2024/history","analysis":"/api/acts/digital-id-agdis-data-standards-2024/analysis","conflicts":"/api/acts/digital-id-agdis-data-standards-2024/conflicts","importantCases":"/api/acts/digital-id-agdis-data-standards-2024/important-cases","documents":"/api/acts/digital-id-agdis-data-standards-2024/documents"}}