Document ID: chunk:federal_register_of_legislation:F2024L01443:body:0:p15
Version: federal_register_of_legislation:F2024L01443
Segment Type: other
Provision Reference: 
Character Range: 52024–54941

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.

3.1.3      Single sign on

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

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

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

3.1.4      Single logout

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

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

3.2   Data requirements

3.2.1      Attribute requirements

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

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

3.2.2      Computed attributes

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

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

4.        Attribute service provider

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

4.1   Technical integration requirements

4.1.1      Protocol requirements

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

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

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

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

4.1.2      Access channels

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

     (a)            directly to a PRP; or
     (b)            to a PRP via an IXP.

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

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

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

 1.             provide documentation outlining the technical integration requirements for the IXP and/or the PRP, as the case may be;
 2.             outline