[Openid-specs-ab] Spec Call Notes 12-Mar-20

Brian Campbell bcampbell at pingidentity.com
Mon Mar 16 14:57:42 UTC 2020

I also have 2¢

On Thu, Mar 12, 2020 at 10:21 AM Torsten Lodderstedt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> >                            Joseph said that in FAPI, people have a lot
> more deployment problems with MTLS than private_key_jwt
> >               Python doesn't successfully process self-signed client
> certificates
> >                            Brian thinks that you can do this in Java by
> overriding a certificate verification method
> The standard solution is to terminate TLS at a web server and just send
> the certificate to the app server as a header.

'Terminating' TLS at some component acting as a reverse proxy and passing
the client certificate or some info about it to the backend apps as
header(s) in the dispatched HTTP request is somewhat common practice today.
Somewhat tangentially, I'm working on a draft that would aim to standardize
the header(s)
and trying to find a home for that work to progress.

Although somewhat new relatively speaking in the grand scheme of things,
allowing for self-signed client certificates is an out-of-the-box
configuration setting for servers such as NGINX and Apache these days with
an `optional_no_ca` option.


> >               The Federation spec uses private_key_jwt at the
> authorization endpoint
> >                            This requires that the audience be the
> authorization endpoint
> >               Brian stated that MTLS isn't defined or possible at the
> authorization endpoint
> >                            Only at the token endpoint
> >               Roland will take this offline with Brian and the authors
> The issues I raised was:
> - the federation spec requires client authentication at the authorization
> endpoint in order to use the automatic registration.
> - This functionality relies on private_key_jwt or put it the other way
> around: A client cannot use it in conjunction with other client
> authentication methods. I don’t see a compelling reason for this
> restriction.
> - I kind of understand why there is a desire to authenticate the client in
> the authorization request. But client authentication in OAuth and OpenId
> traditionally happens at the token endpoint. Automatic registration could
> do the same.
> - If people want early authentication and refusal, just adopt PAR, which
> provides this capability without restricting the client authentication
> methods.
> Side note: the current spec does not prevent replay, so an attacker
> passing as a user could obtain a valid assertion and replay it at other
> endpoints to pose as the legit client.

Just to add to that a bit: The end-user interacts with the authorization
endpoint via a browser. The client directs the user's browser there but
does not itself actually interact directly with the authorization endpoint.
Trying to use client authentication methods (which are designed for direct
client-to-AS invocations) at the authorization endpoint is really
problematic. In some cases, like private_key_jwt, it can sorta be made to
look like it works but won't really provide the same security benefits.
Other cases would be glaringly insecure (client_secret_post) or outright
impossible or nonsensical (client_secret_basic, tls_client_auth,

_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-ab/attachments/20200316/fb853a03/attachment.html>

More information about the Openid-specs-ab mailing list