[Openid-specs-mobile-profile] CIBA hint validation

Brian Campbell bcampbell at pingidentity.com
Mon Jul 9 18:40:53 UTC 2018


§7.2 of CIBA draft in bitbucket
<https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/585e168fcc5d89bbb0e0908ecf2d7498982aac9f/draft-mobile-client-initiated-backchannel-authentication.xml>
and §4.2 of the published version
<http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-authentication-1_0.html#rfc.section.4.2>
have the following text regarding validating the provided hint in the
authentication request.


The OpenID Provider MUST validate the hint provided (login_hint,
> login_token_hint or id_token_hint).
> e.g.: If a signature is provided it MUST be checked. If a validity date is
> provided it MUST be checked.
> If the hint is not valid or if the OP is not able to determine the user
> then an error should be returned to the Client as per section Authentication
> Error Response
> <http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-authentication-1_0.html#auth_error_response>.
>
>

Such validation doesn't really make sense for login_hint so it should
probably be omitted for the MUST here. Perhaps it could by said elsewhere
that if the login_hint value isn't recognized by the AS/OP then return an
error. But I think the requirements for checking each different hint type
should be have separate treatment in the draft.

For id_token_hint in particular this validation requirement is very
problematic as an ID Token is issued for a different context to a different
audience and typically with a shortish validity period. Whereas a CIBA
client might reasonably want to use an ID Token received days or weeks or
more ago as an id_token_hint value. Such an ID Token would be expired and
not have the AS/OP as an audience. It's possible that, due to key rotation,
the AS/OP doesn't even have access to the the keys to check the signature.
OIDC core kind of touches on the issue by saying the AS need not be listed
as an audience of the ID Token when used as an id_token_hint value. The
id_token_hint from OIDC core isn't the most clearly defined parameter to
begin with and while CIBA defers to OIDC for it's definition the usage is
somewhat different. But potentially more important to a CIBA flow. As it
is, consistent, interoperable, or useful treatment of id_token_hint seems
unlikely. I believe that the id_token_hint should be considered simply a
hint only and that it should not be validated.

Validating the login_hint_token does make sense as it is presumably issued
for this purpose. That requirement should just be stated separately from
the other hints.

I just noticed that the text quoted above uses login_token_hint while the
rest of the document uses login_hint_token, which should be fixed.

It would also be nice for implementations and profiles other than MODRNA
that want to use CIBA, if the login_hint_token was defined more generally
as a JWT that's content identifies the end user whom to authenticate in the
background rather than deferring to OpenID Connect MODRNA Authentication
Profile 1.0. I think, after reading the login_hint_token text from that
profile, that the login_hint_token can be a plain old JWT. But I think its
use in CIBA would be easier to understand if the text in CIBA said
something to the effect that it is a JWT/token used to pass a hint about
the user into the authentication process and then point to the MODRNA
profile as one example of such.

-- 
_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/20180709/268cf51e/attachment.html>


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