wfm Have a great new year!
> On 31. Dec 2019, at 16:55, Brian Campbell <bcampb...@pingidentity.com> wrote: > > 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 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 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
