search

ConsumerDataStandardsAustralia / standards-maintenance

This repository houses the interactions, consultations and work management to support the maintenance of baselined components of the Consumer Data Right API Standards and Information Security profile.
41 stars 9 forks source link

OpenID Provider Configuration End Point parameter requirements #522

Closed CDR-API-Stream closed 12 months ago

CDR-API-Stream commented 2 years ago

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

Option 2: Remove required parameters defined within upstream specifications

perlboy commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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

commbankoss commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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]

[RFC8414]

[MTLS]

[RFC9126]

[JARM]

In addition, the Data Holder metadata MUST also include:

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 commented 1 year ago

The proposal above has been edited to

markverstege commented 1 year ago

This change has been staged for review: https://github.com/ConsumerDataStandardsAustralia/standards-staging/compare/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

nils-work commented 12 months ago

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