OpenID Provider Configuration End Point parameter requirements

[CDR-API-Stream]

Description

The OpenID Provider Configuration End Point section describes a minimum set of mandatory parameters that authorisation servers must advertise. There are often other parameters required by upstream normative references. Typically, metadata parameters are registered with IANA and these parameters are described within the RFCs. For example PAR - RFC9126 and JARM.

In the Maintenance Iteration 11 call, streamlining of the Consumer Data Standards was discussed. Rather than list out the required metadata parameters, and update this to include JARM and PAR, it was proposed by the community that another option was to remove this section and refer implementers to the upstream specifications.

If this approach is taken, the non-normative example would be trimmed down and the OpenID Provider Configuration End Point section would remove required parameters except for any parameters defined or constrained by the CDS information security profile.

Area Affected

OpenID Provider Configuration End Point section

Change Proposed

Option 1: Expand list of required parameters

• Update the CDS to exhaustively list all newly required parameters
• Update the non-normative example accordingly

Option 2: Remove required parameters defined within upstream specifications

• Remove any redundantly required parameters and allow implementers to explicitly reference upstream specifications
• Reduce the non-normative example to contain only the CDS defined parameters and constrained parameters

[perlboy]

Option 2 is preferred as it is more flexible to future extensions. Suggest FAPI 1.0 like wording along the lines of:

In addition to the Discovery Document requirements outlined in [OIDD], [PAR] etc the OpenID Discovery Document shall include:

• cdr_arrangement_revocation_endpoint representing the URL of the CDR Arrangement Revocation endpoint

[anzbankau]

Our preference is Option 1 - this in order for the specifications to be explicit and reduce the chances of incompatibility due to participants misinterpreting upstream specifications.

[NationalAustraliaBank]

Option 1 is preferred, this is to ensure any ambiguity referring to upstream specification is avoided

[commbankoss]

CBA is also supportive of option 1. While we acknowledge that this approach results in some overlap between the Consumer Data and upstream standards, from an implementation point of view, the team finds it to be useful to have these references in the CDS as well as the non-normative examples provided.

[CDR-API-Stream]

Discussion in the maintenance iteration call indicated a desire for certainty when it came time to implementation testing. It was argued that being exhaustive in listing the required parameters may assist implementation consistency across a large set of data holders. It was also suggested that comprehensive test cases and standard guidance articles may play an important role in providing better implementation certainty/consistency whilst keeping the Data Standards Information Security profile as a profile over FAPI by only listing constraints, variations and additional requirements.

The DSB is also seeking questions regarding legal defence where participants refer to upstream standards incorporated by reference and how any published CDR test cases and/or support guidance is relied upon for implementation.

[CDR-API-Stream]

Given the views from participants, the proposal is to select Option 1 and provide a normative list of metadata parameters that apply. With future Security Profile uplifts it would be worthwhile revisiting this to consider a lighter weight CDS profile.

[markverstege]

The following change to the OpenID Provider Configuration End Point metadata list is proposed. If there are any parameters required that are omitted in the below proposal please feel free to comment. As a proposal, the list will be separated by the normative reference that registers the parameters. Please note the links in the text refer to anchors inline to the Data Standards, not this issue.

Metadata requirements

At a minimum, the Data Holder metadata MUST include:

[OIDD]

• acr_values_supported: The supported ACR values
• authorization_endpoint: URL of the Authorization End Point
• claims_supported: The list of supported claims
• grant_types_supported: The list of the OAuth 2.0 Grant Type values supported
• id_token_encryption_alg_values_supported: The list of the supported JWE algorithms for securing the issued ID tokens. Must conform to [FAPI-RW-Draft] and [OIDD]. Required for Data Holders supporting OIDC Hybrid Flow
• id_token_encryption_enc_values_supported: The list of the supported JWE encryption methods for securing the issued ID tokens. Required for Data Holders supporting OIDC Hybrid Flow
• id_token_signing_alg_values_supported: The list of the JWS signing algorithms (alg values) supported
• issuer: URL that the Data Holder asserts as its Issuer Identifier
• jwks_uri: The JSON Web Key Set for the data holder
• registration_endpoint: URL of the Client Registration End Point
• request_object_signing_alg_values_supported: The list of the JWS signing algorithms (alg values) supported for signing request objects.
• response_modes_supported: The list of the OAuth 2.0 response_mode values supported
• response_types_supported: The list of the OAuth 2.0 response_type values supported
• scopes_supported: The list of supported scopes
• subject_types_supported: list of the Subject Identifier types supported
• token_endpoint: URL of the Token End Point
• token_endpoint_auth_methods_supported: The list of Client Authentication methods supported by the Token Endpoint
• token_endpoint_auth_signing_alg_values_supported: The list of the JWS signing algorithms (alg values) supported by the token endpoint for the signature on the JWT [JWT] used to authenticate the client at the token endpoint for the "private_key_jwt" authentication method
• userinfo_endpoint: URL of the UserInfo End Point

[RFC8414]

• code_challenge_methods_supported: JSON array containing a list of [PKCE (RFC7636)] code challenge methods supported
• introspection_endpoint: URL of the Introspection End Point
• revocation_endpoint: URL of the Revocation End Point

[MTLS]

• tls_client_certificate_bound_access_tokens: Indicates support for mutual-TLS client certificate-bound access tokens. Value MUST be set to true

[RFC9126]

• pushed_authorization_request_endpoint: URL of the Pushed Authorisation End Point used to support [PAR]
• require_pushed_authorization_requests: Boolean parameter indicating whether the authorization server accepts authorization request data only via PAR

[JARM]

• authorization_encryption_alg_values_supported: A JSON array containing a list of the JWE encryption algorithms (alg values) supported by the authorization endpoint to encrypt the response. If response encryption is used, Data Holders must support at least one of "RSA-OAEP" or "RSA-OAEP-256"
• authorization_encryption_enc_values_supported: A JSON array containing a list of the JWE encryption algorithms (enc values) supported by the authorization endpoint to encrypt the response. Required if “authorization_encryption_alg_values_supported” is provided. If response encryption is used, Data Holders must support at least one of "A256GCM" or "A128CBC-HS256"
• authorization_signing_alg_values_supported: A JSON array containing a list of the JWS signing algorithms (alg values) supported by the authorization endpoint to sign the response. Required if Authorization Code Flow (response_type “code”) is supported

In addition, the Data Holder metadata MUST also include:

• cdr_arrangement_revocation_endpoint: The URL of the CDR Arrangement Revocation End Point for consent revocation

Non-Normative Example

## Request

GET /.well-known/openid-configuration HTTP/1.1
Host: www.dh.com.au

## Response - FAPI 1.0 Final Phase 3 Obligations

HTTP/1.1 200 OK
Content-Type: application/json
{
    "acr_values_supported": ["urn:cds.au:cdr:2","urn:cds.au:cdr:3"],
  "authorization_endpoint": "https://www.dh.com.au/authorise",
  "claims_supported": ["name", "given_name", "family_name", "acr", "auth_time", "sub", "refresh_token_expires_at", "sharing_expires_at"],
  "grant_types_supported": ["authorization_code", "client_credentials", "urn:openid:params:modrna:grant-type:backchannel_request"],
  "id_token_encryption_alg_values_supported": [ "RSA-OAEP", "RSA-OAEP-256", "dir", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A192KW", "ECDH-ES+A256KW", "A128KW", "A192KW", "A256KW", "A128GCMKW", "A192GCMKW", "A256GCMKW" ],
  "id_token_encryption_enc_values_supported": [ "A128CBC-HS256", "A192CBC-HS384", "A256CBC-HS512", "A128GCM", "A192GCM", "A256GCM" ],
  "id_token_signing_alg_values_supported": ["ES256", "PS256"],
  "issuer": "https://www.dh.com.au",
  "jwks_uri": "https://www.dh.com.au/jwks",
  "registration_endpoint": "https://www.dh.com.au/register",
  "request_object_signing_alg_values_supported": ["ES256", "PS256"],
  "response_modes_supported": ["fragment", "jwt"],
  "response_types_supported": ["code id_token", "code"],
  "subject_types_supported": ["pairwise"],
  "scopes_supported": ["openid", "profile", "..."],
  "token_endpoint": "https://www.dh.com.au/token",
  "token_endpoint_auth_methods_supported": ["private_key_jwt"],
  "token_endpoint_auth_signing_alg_values_supported": ["ES256", "PS256"],
  "userinfo_endpoint": "https://www.dh.com.au/userinfo",
  
  "code_challenge_methods_supported": "S256",
  "introspection_endpoint": "https://www.dh.com.au/introspect",
  "revocation_endpoint": "https://www.dh.com.au/revoke",
  
  "tls_client_certificate_bound_access_tokens": true,

  "pushed_authorization_request_endpoint": "https://data.holder.com.au/par",
  "require_pushed_authorization_requests": true,
  
  "authorization_encryption_alg_values_supported": ["RSA-OAEP", "RSA-OAEP-256"],
  "authorization_encryption_enc_values_supported": ["A256GCM", "A128CBC-HS256"],
  "authorization_signing_alg_values_supported": ["ES256", "PS256"],

  "cdr_arrangement_revocation_endpoint": "https://data.holder.com.au/arrangements/revoke"
}

[markverstege]

The proposal above has been edited to

• re-order parameter listing by prioritising OIDD over RFC8414 which provides a generalisation.
• Change the OIDC group to be OIDD
• Correct the anchor link for RFC8414
• Include ID token signing requirements
• Apply Markdown formatting fixes

[markverstege]

This change has been staged for review: ConsumerDataStandardsAustralia/standards-staging@release/1.24.0...maintenance/522

Note it is compared against the previous release. At present no draft 1.25.0 release has been staged but it is expected this change will target 1.25.0 for release at the end of maintenance iteration 15.

[perlboy]

There is an existing statement in the Standards of:

Data Holders MAY advertise they do not support authorisation response encryption: either by omitting these values from their OpenID Provider Metadata, or by presenting an empty array for the supported parameters.

The MUST statements in the proposed discovery document clarification are potentially ambiguous when cross checked against the existing statement. Suggest this be clarified or one of the statements be modified so as to avoid encountering Regulator misunderstanding (Discovery documents have been previously and incorrectly flagged by the ACCC as non-compliant due to legitimate and compliant missing attributes).

[markverstege]

Good pick up. Given there are requirements around the use of authorisation response encryption, if used, I'd suggest we take that out of the minimum set of MUSTs and have it standalone:

Where Data Holders support authorisation response encryption according to [JARM], the following parameter provisions MUST be supported:

authorization_encryption_enc_values_supported: A JSON array containing a list of the JWE encryption algorithms (enc values) supported by the authorization endpoint to encrypt the response. Required if “authorization_encryption_alg_values_supported” is provided. If response encryption is used, Data Holders must support at least one of "A256GCM" or "A128CBC-HS256"

authorization_signing_alg_values_supported: A JSON array containing a list of the JWS signing algorithms (alg values) supported by the authorization endpoint to sign the response. Required if Authorization Code Flow (response_type “code”) is supported

[markverstege]

These changes have been incorporated in the staged standards for review: ConsumerDataStandardsAustralia/standards-staging@release/1.25.0...maintenance/522

[nils-work]

Standards version 1.25.0 has now been published, incorporating this change.