[Openid-specs-mobile-profile] Review comments on openid-client-initiated-backchannel-authentication-core-01
dave.tonge at momentumft.co.uk
Tue Feb 5 06:55:53 UTC 2019
Thanks for the detailed review.
Please see my comments below.
On Sun, 3 Feb 2019 at 17:01, Torsten Lodderstedt <torsten at lodderstedt.net>
> 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.
Fair point - I've opened this issue:
> - 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).
I may be missing something here, but even in the 3rd example in OIDC core,
the sector identifier is used. I agree that the word "calculation" could be
a bit misleading, as it could be a lookup rather than some hash function,
but please let me know if i've missed something.
> — 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.
Yep, I see this issue - but we should probably raise it against OIDC Core
> 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.
So at the moment my understanding of our requirements here are:
- in PING/POLL mode, Client must register with jwks_uri
- if sector_identifier_uri is provided, it must point to a file that must
CONTAIN the jwks_uri
So I don't think we are requiring a host comparison - rather we are already
following your suggestion (with the exception that we aren't
Please let me know if I've missed something or if you think the wording can
> — 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.
I agree that it would be preferable for the check to be performed at
registration time. I'm not sure if this requires a normative change -
possibly some additional guidance would help. I've opened this issue:
> - 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).
I thought that we discussed this, but I'm struggling to find the issue. @Joseph
Heenan <joseph.heenan at fintechlabs.io> or @Brian Campbell
<bcampbell at pingidentity.com> can you remember?
> — 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 (:—)).
> This is a valid concern, but perhaps the difference here is that users
won't be forced to use the mechanism. The idea is that they will have to
explicitly opt-in to get this added protection. @Petteri Stenius
<Petteri.Stenius at ubisecure.com> do you have any thing else to add here?
Perhaps we need some guidance around this issue?
> - 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?
That was the original approach. But we decided there were too many
differences and that it would be cleaner to define it from scratch.
> — page 10 - the example shows the signed request and additionally a Basic
> AUTHORIZATION header. Do you intentionally use two mechanisms to authorize
> the request?
Yes, we took the decision that authentication at the backchannel endpoint
should be the same as at the token endpoint. So whatever the client has
set-up to use at the token endpoint - they use the same at the backchannel
endpoint. The ability to sign the request is for non-repudiation purposes
rather than authentication.
> - 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.
I think this is a good suggestion, I've opened this issue:
> - 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
:-) Good point, although at the moment CIBA is probably tied to OIDC in a
few more ways. I'll open an issue to look at this.
> - 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,
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
[image: Moneyhub Enterprise]
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120
Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Technology is registered in England & Wales, company registration number
Moneyhub Financial Technology Limited 2018 ©
DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-mobile-profile