Yeah, I agree. The insights in that comment Filip referenced (copied below) are very very wise and explain why we should not define pushed_authorization_endpoint_auth_methods_supported and pushed_authorization_endpoint_auth_signing_alg_values_supported metadata.
There's some historical weirdness to how client authentication has come to be represented (and named) in metadata. Client registration metadata has only a token_endpoint_auth_method, which despite the name has become the de facto place in the client data model to say how the client will authenticate to the AS when making any direct client -> AS call. The parameter name is a bit unfortunate but I believe it makes sense to have a single (backchannel) authentication method per client. RFC 8414 took a different direction and has revocation_endpoint_auth_methods_supported and introspection_endpoint_auth_methods_supported etc., which I believe was a mistake. I don't see a clear use case for needing or allowing a different set of auth methods for the different endpoints. And having a bunch of _supported parameters for different endpoints seems likely to clutter up the metadata document with a bunch of redundant info. I'd propose that some text be added into CIBA core that says that, for the backchannel authentication endpoint, the AS supports the same client authentication methods as indicated with token_endpoint_auth_methods_supported. And state that, for a client, the token_endpoint_auth_method is the authentication method registered for its client_id regardless of the endpoint being called. On Tue, Dec 31, 2019 at 8:22 AM Filip Skokan <panva...@gmail.com> wrote: > I don't think we need a *_auth_method_* metadata for every endpoint the > client calls directly, none of the new specs defined these (e.g. device > authorization endpoint or CIBA), meaning they also didn't follow the scheme > from RFC 8414 where introspection and revocation got its own metadata. In > most cases the unfortunately named `token_endpoint_auth_method` and its > related metadata is what's used by clients for all direct calls anyway. > > The same principle could be applied to signing (and encryption) algorithms >> as well. > > > This I do not follow, auth methods and their signing is dealt with by > using `token_endpoint_auth_methods_supported` and > `token_endpoint_auth_signing_alg_values_supported` - there's no encryption > for the `_jwt` client auth methods. > Unless it was meant to address the Request Object signing and encryption > metadata, which is defined and IANA registered > <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#table-client-metadata> > by > OIDC. PAR only references JAR section 6.1 and 6.2 for decryption/signature > validation and these do not mention the metadata (e.g. > request_object_signing_alg) anymore since draft 07. > > PS: I also found this comment > <https://bitbucket.org/openid/mobile/issues/102#comment-48494839> related > to the same question about auth metadata but for CIBA. > > Best, > *Filip* > > > On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > >> Hi all, >> >> Ronald just sent me an email asking whether we will define metadata for >> >> pushed_authorization_endpoint_auth_methods_supported and >> pushed_authorization_endpoint_auth_signing_alg_values_supported. >> >> The draft right now utilises the existing token endpoint authentication >> methods so there is basically no need to define another parameter. The same >> principle could be applied to signing (and encryption) algorithms as well. >> >> What’s your opinion? >> >> best regards, >> Torsten. > > -- _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._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
