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

[Brian Campbell]

A few additional little comments inline:

On Mon, Feb 4, 2019 at 11:56 PM Dave Tonge <dave.tonge at momentumft.co.uk>
wrote:

>
> On Sun, 3 Feb 2019 at 17:01, Torsten Lodderstedt <torsten at lodderstedt.net>
> wrote:
>
> — 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
>

I believe it has been raised
https://bitbucket.org/openid/connect/issues/1058/sector_identifier_uri-should-have-a-well
but would be a breaking change to finalized spec(s) so isn't likely to
change.


>
>> — 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:
> https://bitbucket.org/openid/mobile/issues/152/guidance-around-verification-of-ownership
>
>
>>
In many cases clients aren't actually dynamically registered but configured
with the AS/OP via some other means. Also I suspect that defining/using
client authentication methods for registration is nowhere near as
straightforward as it might seem.


- 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?
>

This is the one
https://bitbucket.org/openid/mobile/issues/104/ciba-client_notification_tokens-length-and

I chose 1024 somewhat arbitrarily to "allow for a reasonable sized JWT to
be used as the client_notification_token" but I suppose it depends on what
one views as "reasonable". I think 1024 is enough though.




>
>> — 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?
>
>
The whole mechanism is optional FWIW.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20190205/55593eab/attachment.html>