[Openid-specs-mobile-profile] Review comments on openid-client-initiated-backchannel-authentication-core-01

Torsten Lodderstedt torsten at lodderstedt.net
Sun Feb 3 16:01:06 UTC 2019

Hi all, 

please find some comments on the CIBA draft below.

First of all, I would like to thank you for moving this draft forward. The result is really impressive!

- The term „consumption device“ is first used Section 1, 1st paragraph without description. Readers not familiar with the Mobile Connect/MODRNA terminology don’t know this term. 

- Section 4

-- Poll and Ping Modes with Pairwise Identifiers

„… which allows the OP to consider the host component of that URI as the Sector Identifier for the pairwise identifier calculation per Section 8.1 of OpenID Connect Core“ 

This text is a bit misleading as there are ways the OP can determine PPIDs without to incorporate the sector identifier URL (see 3rd example in OpenID Connect spec, section 8.1).

— The second paragraph describes the way to ensure the RP is entitled to obtain PPIDs for a certain sector identifier. I see two drawbacks:

1) only the host component of the URIs involved is used to check for equality. This means RP’s residing on the same host in a shared environment automatically share the same sector identifier even if they are good citizens and use different sector identifier URIs. This is basically an issue of the OpenID Connect Core spec.

2) The comparison of the host component of the JWKS URI and the sector identifier URI should work but to me seems like a workaround and imposes restrictions on the way RP construct URIs. Have you considered to put the respective JWKS URIs in the sector identifier JSON document? The syntax would need to be extended (as it is a simple JSON array right know). But this document serves a similar purpose for RPs than the openid-configuration file for OPs. So putting more metadata into it seems like a reasonable solution.  

— The third paragraph 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. 
- section 7.1.  

— client_notification_token - limiting the size of the token to 1024 characters seems a bit short in case the RP decides to use self contained tokens (e.g. JWTs).

— user_code - I think I understand the rationale of this feature but I’m a bit concerned about its practicability. It shall ensure no CIBA request is sent out to the user’s authentication device without prior confirmation using a secret the user knows. It reminds me of the static PIN codes in the Mastercard 3DS authorization scheme. It failed simply because users set up and immediately forgot their PIN codes resulting in terrible conversion rates. I bet user’s will most likely forget this use code as well. 3DS solved the problem by introducing dynamic PIN codes, e.g. sent to the user via text message. That’s most likely not a viable solution for CIBA (:—)).

- section 7.1.1.

— Isn’t this section describing a OIDC request object (or JAR) just sent via a POST request? Why don’t you just referrer to it and focus the text on the extensions/differences needed in CIBA?

— page 10 - the example shows the signed request and additionally a Basic AUTHORIZATION header. Do you intentionally use two mechanisms to authorize the request?

- section 7.2

— bullet 1. "… It is RECOMMENDED that Clients not send shared secrets in the Authentication Request but rather that public key cryptography be used.“

I agree with this recommendation but all examples use shared secrets (Basic authz) to authenticate and authorize the respective RP. I suggest you change the examples to use public crypto.

- section 10.3.1.

— Binding the iss & auth_req_id together with a signature is a good way to ensure authenticity of the data delivered to the RP via the push mechanism. Using the ID token as detached signature mechanism makes it a OpenID Connect only solution. That happened before with FAPI and we have seen what headache it might cause if such a mechanism shall be used for API authorization (OAuth) latter on. So basically you are limiting (at least the push mechanisms) to OpenID. I would advocate to come up with a solution applicable in both scenarios, OpenID and OAuth. Sending the data in a JWT and digitally signing it (like with JARM https://openid.net/specs/openid-financial-api-jarm-ID1.html) would be an option. 

- section 14

— „The OP SHOULD ensure that the "backchannel_client_notification_endpoint" configured at registration time is in the administrative authority of the Client. Otherwise, the OP would post authentication results to the wrong Client. How this check is done is outside the scope of this specification."  

Any idea how the OP should fulfill this requirement? I haven't found a similar requirement on redirect URI handling in the OpenID Connect Core spec although the risk is the same. 

I think the notification endpoint could also be placed in the sector identifier URI (or shall we call it rp-openid-configuration :-)).

kind regards,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3923 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20190203/61bb27b8/attachment-0001.p7s>

More information about the Openid-specs-mobile-profile mailing list