Guidance around verification of ownership of keys at jwks_uri for PPID

[Dave Tonge]

From Torsten:

The third paragraph [in Poll and Ping Modes with Pairwise Identifiers] specifies in rather weak language how the client shall demonstrate possession of the respective private keys. Moreover, the check is deferred to the actual use of the CIBA functions. In contrast, in case of standard OIDC the check whether a redirect_uri belongs to the authorized destinations for certain PPIDs is checked at registration time. Deferring the check to the CIBA use puts the respective RP record in kind of a middle state.

Have you considered to let the dynamic registration function of the OP perform the check? One could use one of the methods cited in the spec (mTLS or private_key_jwt) to conduct the proof. Such an approach would allow to conduct all the checks necessary in one place and a single action and either accept or refuse the registration.

[Dave Tonge]

This was discussed on Feb 5th:

After a lot of discussions, and questions about the applicability of the proposal, the issue is kept open.

[Dave Tonge]

We discussed again on the call.

Brian made the point that oftentimes it will be a runtime check - which in a way is analogous to our PPIDs work with redirect_uris.

So the process with PPIDs in CIBA is:

Registration OP makes sure that Client registers jwks_uri

Auth Request OP makes sure that Client either: - uses a signed request (with a key present in the jwks_uri) - authenticates with private_key_jwt (with a key present in the jwks_uri) - authenticates with mutual tls - self-signed method (with a cert present in the jwks_uri)

OP issues PPID based on the jwks_uri

[Bjorn Hjelm]

From Torsten:

The third paragraph [in Poll and Ping Modes with Pairwise Identifiers] specifies in rather weak language how the client shall demonstrate possession of the respective private keys. Moreover, the check is deferred to the actual use of the CIBA functions. In contrast, in case of standard OIDC the check whether a redirect_uri belongs to the authorized destinations for certain PPIDs is checked at registration time. Deferring the check to the CIBA use puts the respective RP record in kind of a middle state.

Have you considered to let the dynamic registration function of the OP perform the check? One could use one of the methods cited in the spec (mTLS or private_key_jwt) to conduct the proof. Such an approach would allow to conduct all the checks necessary in one place and a single action and either accept or refuse the registration.

[Bjorn Hjelm]

From Torsten:

The third paragraph [in Poll and Ping Modes with Pairwise Identifiers] specifies in rather weak language how the client shall demonstrate possession of the respective private keys. Moreover, the check is deferred to the actual use of the CIBA functions. In contrast, in case of standard OIDC the check whether a redirect_uri belongs to the authorized destinations for certain PPIDs is checked at registration time. Deferring the check to the CIBA use puts the respective RP record in kind of a middle state.

Have you considered to let the dynamic registration function of the OP perform the check? One could use one of the methods cited in the spec (mTLS or private_key_jwt) to conduct the proof. Such an approach would allow to conduct all the checks necessary in one place and a single action and either accept or refuse the registration.

[Torsten Lodderstedt]

I agree with Brian’s assessment. The final “check” in case of standard OpenID Connect is the exact redirect URI checking against the client’s registration data. The equivalent would be the proof of possession of key listed in a file serving as sector identifier URI.

I think the text about sector identifiers needs polishing. It confused me first stating

“In that way the OpenID Provider can use the host component of the "jwks_uri" as the Sector Identifier to generate the PPIDs for the Client.“,

which creates the impression the jwks_uri is the only way to determine a sector identifier in CIBA whereas later it states

“If a "sector_identifier_uri" is explicitly provided, then the "jwks_uri" must be included in the list of URIs pointed to by the "sector_identifier_uri".”

Please note: the sector_identifier_uri as defined in OIDC Dynamic Client registration is supposed to refer to a file containing an array of redirect URIs. This does not match the current text in CIBA as your expectation would be that this array contains a jwk_uri as well.

[Dave Tonge]

Discussed on the call - I will propose some text to address this issue

[Dave Tonge]

https://bitbucket.org/openid/mobile/pull-requests/70/improve-test-describing-the-ppid-mechanism/diff

[Dave Tonge]

Above PR has this proposed text:

In OIDC the sector_identifier_uri contains a document with a list of redirect_uris and the Sector Identifier is defined as either the host component of the sector_identifier_uri or if this is not provided then the host component of the redirect_uri.

In CIBA Poll & Ping modes the jwks_uri is used in place of the redirect_uri. In CIBA Push mode the backchannel_client_notification_endpoint is used in place of the redirect_uri.

In situations where the PPID must be shared among multiple RPs, then a sector_identifier_uri can be registered. This specification extends the purpose of the sector_identifier_uri such that it can contain jwks_uris and backchannel_client_notification_endpoints as well as redirect_uris.

In order to support Pairwise Pseudonymous Identifiers in Ping and Poll modes, the RP must provide either a sector_identifier_uri or a "jwks_uri" at the registration phase when the "urn:openid:params:grant-type:ciba" grant type is registered. In that way the OpenID Provider can use the host component of the sector_identifier_uri or ”jwks_uri" as the Sector Identifier to generate the PPIDs for the Client.

When an OpenID Provider that supports PPIDs receives a dynamic registration request for a Client that indicates that it wishes to use the Poll or Ping CIBA modes, it MUST check if a valid "jwks_uri" is set when the "subject_type" is "pairwise". If a "sector_identifier_uri" is explicitly provided, then the "jwks_uri" must be included in the list of URIs pointed to by the "sector_identifier_uri".

‌

[Dave Tonge]

pull request has been merged