request_authentication_methods_supported inconsistently defined
Issue #1477
resolved
The request_authentication_methods_supported
example is as follows:
"request_authentication_methods_supported":{ "ar":[ "request_object" ], "par":[ "private_key_jwt", "self_signed_tls_client_auth" ] }
However, the definition of request_authentication_methods_supported
says nothing about the hierarchical structure in the example, nor anything about the identifiers ar
or par
. Is the example wrong or is the definition?
Comments (6)
-
-
I’ll draft a proposal.
-
reporter Roland drafted https://bitbucket.org/openid/connect/pull-requests/165 to address this issue.
-
- changed status to open
Being addressed by PR 165
-
-
- changed status to resolved
- Log in to comment
It took me a while to fully understand the purpose of this metadata in the context of PAR; the text around https://bitbucket.org/openid/connect/src/e1a87ae9009baf64dd2f8638a8ae1d8ad48320de/openid-connect-federation-1_0.xml#lines-842 could do with a little finessing to explain that a client authentication method that proves possession of the keys must be used.
I’m not sure it’s a good idea to explicitly constraint the possible keys within
request_authentication_methods_supported
to private_key_jwt/tls_client_auth/self_signed_ths_client_auth, as that effectively prevents using other future client authentication methods - it might be as well to just say “The authentication method used must allow the OP to verify possession of the key, for example private_key_jwt/tls_client_auth/self_signed_ths_client_auth”. (I’m not entirely convinced by my argument here, the “Processing the Authentication Request”
section explicitly describes how the key possession is checked in each case, so there’s probably an argument you have to update the federation spec to allow new client auth types anyway.)It might be good to say that that
request_authentication_methods_supported
is required ifclient_registration_types_supported
containsautomatic
.