[Openid-specs-mobile-profile] CIBA Authentication Request format

[Brian Campbell]

 Coming to this relatively new and reading CIBA with the perspective of
potentially implementing it (due to FAPI profiling CIBA), I feel there's
some ambiguity around the format of the Authentication Request (sec 4.1
<http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-authentication-1_0.html#rfc.section.4.1>
in the published version and sec 7.1
<https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.7.1>
of the latest from source). The example shows a POST with application/json
in the body while the text defers to authorization/authentication request
of OAuth/OIDC, which uses application/x-www-form-urlencoded parameters. The
text (in the latest source) also says that OpenID Connect Signed Request
Object (referencing OIDC §6.3.2
<https://openid.net/specs/openid-connect-core-1_0.html#SignedRequestObject>)
can be used, which could be interpreted to mean form-urlencoded parameters
with request=[JWT] or request_uri=[URL to JWT] and also requiring the
scope, response_type and client_id parameters to be present as form
parameters and that their values match the same named claims in the JWT.
OIDC also says that parameters MAY also be passed using the OAuth 2.0
request syntax (regular form parameters) even when a Request Object is used
and that both are considered with the values contained in the JWT Request
Object superseding those passed using the OAuth 2.0 request syntax. I
rather doubt that the intent of CIBA was to bring in all that baggage from
OIDC's request object but that's how OIDC defines it and so is a not
unreasonable interpretation of the CIBA draft, particular for someone
familiar with Connect or pedantic about reading its details.

I see the idea behind CIBA wanting to just kinda defer to the OAuth 2.0
Authorization Request / OIDC Authentication Request in this back-channel
context but those are designed to pass through a user's browser via
redirection, which is rather different than direct a client to AS request
like CIBA needs. I think basing the CIBA request on the OIDC/OAuth
front-channel requests actually causes more issues than it solves. And it'd
be more appropriate and straightforward for CIBA to directly define the
parameters and format/encoding. The relevant parameters are already defined
in the Authentication Request section. The format/encoding just needs to be
more clearly stated. From what's there now, I suspect that the intent is to
have the request be JSON in the body with the parameters as top level
members of that JSON and the content-type would be application/json. That's
what the example in the draft has now but the normative text doesn't
unambiguously say it. For a 'signed request'  the content-type should
probably be application/jwt with the body of the request being just the JWT
that's payload is the claims that would be the JSON of the actual request
parameters. The JWT should probably be required/encouraged to also have an
audience and expiration.

-- 
_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/20180706/30eb8dc9/attachment-0001.html>