Introspection Endpoint RFC vs Standards clarification

Question

For context the Introspection endpoint response and the documentation (CDS vs RFC) is conflicting:

The CDS (https://consumerdatastandardsaustralia.github.io/standards/#end-points) states:

“A Token Introspection End Point Response SHALL include, at least, the following fields:

• active: Boolean indicator of whether or not the presented token is currently active.
• exp: A JSON number representing the number of seconds from 1970-01-01T00:00:00Z to the UTC expiry time.
• scope: A JSON string containing a space-separated list of scopes associated with this token.
• cdr_arrangement_id: A unique identifier of the CDR arrangement related to the authorisation.”

While the RFC (https://tools.ietf.org/html/rfc7662#section-2) says that:

“If the introspection call is properly authorized but the token is not active, does not exist on this server, or the protected resource is not allowed to introspect this particular token, then the authorization server MUST return an introspection response with the "active" field set to "false".  The authorization server SHOULD NOT include any additional information about an inactive token, including why the token is inactive.”

Does the CDS overwrite the RFC? When active = true or false the Introspective Response returns at least the following fields (active, exp, scope, cdr_arrangement_id)

Or

Does the RFC overwrite the CDR? When active = false do we only return 1 field (active)? When active = true we return the following fields (active, exp, scope, cdr_arrangement_id)

Answer

The statements around required fields are not meant to override the normative standards that define the behaviour of the introspection end point.  Specifically, it should not be seen as overriding or conflicting with the statements in the latter half of section 2.2 that describes how to respond to requests with invalid or expired tokens.

The field section is intended to modify the earlier part of section 2.2 which makes a variety of fields option and is not seen to be in conflict with the RFC.  It is clarification aligned with the parts of section 2.2 that specifically allow for authorisation servers to extend or modify the introspection payload.

Essentially the fields section in the Standards ensures that data holders always provide the `exp` and `scope` fields (when it is valid to do so) so that ADRs can validate token capabilities.  The `cdr_arrangement_id` is a CDS specific extension to support more complex consent scenarios.