<div dir="ltr"><div>It is somewhat awkward that the requests to the backchannel authentication endpoint are application/json while requests to the token endpoint are application/x-www-form-urlenco<wbr>ded and a CIBA client will call both endpoints directly so have to use two different request formats. Having the backchannel authentication request be JSON seems to be the WGs preference, however. As a few people said on the July 10 call, a client has to have JSON capabilities anyway to consume the token endpoint response so it doesn't seem too cumbersome to require the client to format a request body in JSON. Both can be done with curl. An application/jwt for signed requests to the backchannel endpoint would be an optional format that's used by clients in situations that need nonrepudiation or whatever. That's my gauge of the WG and this draft anyway from my rather short involvement. Perhaps others will correct me. But I'm looking to get the current ambiguity in the draft fixed. <br></div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 12, 2018 at 5:14 AM, Petteri Stenius <span dir="ltr"><<a href="mailto:Petteri.Stenius@ubisecure.com" target="_blank">Petteri.Stenius@ubisecure.com</a><wbr>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="FI">
<div class="gmail-m_8946156117167829671gmail-m_7435881343959167619m_295544505364983531m_6705010408889787065gmail-m_-3252066131568520198WordSection1">
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Some thoughts from an implementors perspective<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">It would be nice if the backchannel endpoint was so simple that for testing and exploring you could invoke it with a simple command line tool like curl. For me this implies using form
 post for request body format and client_secret_basic or client_secret_post for client authentication.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">However I do like the idea of using application/jwt for signed requests to the backchannel endpoint. The downside is that this is a new request format for most OAuth and OIDC implementations.
 Also in the context of CIBA the request format for backchannel endpoint will be different from the request format for token endpoint. This makes implementations unnecessary complex as they need to implement two different request formats for these two endpoints.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I'd like to suggest for backchannel endpoint to reuse the request format and client authentication methods of other server to server endpoints such as token endpoint (not the authorization
 endpoint). This makes CIBA look more like for example draft-ietf-oauth-device-flow which I think is quite closely related to CIBA.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Maybe in the future there is a major update to OAuth/OIDC that defines JSON and JWT request formats for all server to server endpoints.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Petteri<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Openid-specs-mobile-profile <<a href="mailto:openid-specs-mobile-profile-bounces@lists.openid.net" target="_blank">openid-specs-mobile-profile-b<wbr>ounces@lists.openid.net</a>>
<b>On Behalf Of </b>Brian Campbell via Openid-specs-mobile-profile<br>
<b>Sent:</b> lauantai 7. heinäkuuta 2018 1.14<br>
<b>To:</b> Openid-specs-mobile-profile <<a href="mailto:openid-specs-mobile-profile@lists.openid.net" target="_blank">openid-specs-mobile-profile@l<wbr>ists.openid.net</a>><br>
<b>Subject:</b> [Openid-specs-mobile-profile] CIBA Authentication Request format<u></u><u></u></span></p><span class="gmail-m_8946156117167829671gmail-m_7435881343959167619m_295544505364983531m_6705010408889787065gmail-">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">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 (<a href="http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-authentication-1_0.html#rfc.section.4.1" target="_blank">sec
 4.1</a> in the published version and <a href="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" target="_blank">
sec 7.1</a> 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-urlenco<wbr>ded parameters. The text (in the latest
 source) also says that OpenID Connect Signed Request Object (referencing <a href="https://openid.net/specs/openid-connect-core-1_0.html#SignedRequestObject" target="_blank">
OIDC §6.3.2</a>) 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.
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</span><p class="MsoNormal"><br>
<b><i><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(85,85,85);border:1pt none windowtext;padding:0cm">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.</span></i></b><u></u><u></u></p>
</div>
</div>

</blockquote></div><br></div></div></div>

<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">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.</font></span></i>