<div dir="ltr"><div>

<span></span>The <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/585e168fcc5d89bbb0e0908ecf2d7498982aac9f/draft-mobile-client-initiated-backchannel-authentication.xml">CIBA draft in bitbucket</a> in sec 7.1 (quoted below with similar bits from §7.2) says that the client authenticates to the Backchannel Authentication Endpoint using the authentication method registered for its client_id. This, of course, is also the same client authentication method used at the token endpoint. That's sensible and consistent with how client authentication has been done at other extension endpoints that the client makes direct requests to. <br></div><div><br></div><div> The text then goes on to say that the recommended authentication method is with an Signed Request Object. However, there is no OAuth client authentication method corresponding to a Signed Request Object or any signed request style client authentication method defined. So the text leaves the reader/implementer with a somewhat inconsistent and unworkable recommendation. <br></div><div><br></div><div>I'd argue that having the client authenticate to the Backchannel Authentication Endpoint using the authentication method registered for its client_id (and not just those defined by OpenID Core) is the appropriate thing for CIBA to specify. And that any requirements or options for signing the request payload (perhaps for non-repudiation) be treated as separate from general client authentication. Any such requirements or capabilities might also benefit from client and/or server metadata parameters defined for them. <br></div><div><br></div><div><br></div><div>From §7.1:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>The Client MUST authenticate to the Backchannel Authentication Endpoint 
using the authentication method registered for its client_id. The 
RECOMMENDED method to authenticate the Client is using an <a href="https://openid.net/specs/openid-connect-core-1_0.html#SignedRequestObject">OpenID Connect Signed Request Object</a>
 as described in OpenID.Core. If a Signed Request Object is not used for
 authentication then one of the authentication methods of Section 9 of <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#OpenID.Core" class="gmail-xref">[OpenID.Core]</a> should be used.  <br></div></blockquote><div><br></div><div><br></div><div>And from §7.2</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Authenticate the Client.  <br> The client SHOULD use a <a href="https://openid.net/specs/openid-connect-core-1_0.html#SignedRequestObject">OpenID Connect Signed Request Object</a> as defined in Section 6.3.2 of <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#OpenID.Core" class="gmail-xref">[OpenID.Core]</a>.
  Then that signature MUST be validated and the Authentication Request 
MUST fail if the signature is not valid.  If the value of the 
signature's "alg" parameter is "none" then another method of Client 
authentication MUST be used as described in Section 9 on <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#OpenID.Core" class="gmail-xref">[OpenID.Core]</a>.
  CIBA is allowing the same Client authentication methods for the 
Authorization Endpoint that OpenID.Core uses for the Token Endpoint.   <br></div></blockquote></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>