request_authentication_methods_supported inconsistently defined

Issue #1477 resolved
Michael Jones created an issue

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)

  1. Joseph Heenan

    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 if client_registration_types_supported contains automatic.

  2. Log in to comment