Drawbacks of defining request_authentication_methods_supported as JSON object

[Razumain]

When defining request_authentication_methods_supported as JSON object, the document changes a long tradition of not doing so, which I think has significant drawbacks.

Traditionally, metadata profiles makes great effort to define metadata as string, integer, boolean or an array of the former in some form.

This creates many metadata parameters, but it also has the advantage of making it easy to process metadata parameters as well as allowing effective policy processing.

We can now see that objects are added as optional type of metadata values, but I have serious doubts that this will work in practice. To really implement policy processing of metadata values in JSON object form will be a huge challenge.

Taking authorization_endpoint as example.
The following has already been defined elsewhere:

authorization_endpoint

Wouldn't it then be better and more consistent to define:

authorization_endpoint_request_auth_methods_supported

And then do the same for other endpoint types. I.e "{endpoint_metadata_name}_request_auth_methods_supported"
Here are the advantages I can see:

1. Staying in line with how metadata parameters are defined in general.
2. These metadata values can be influenced by policy in a much more straightforward fashion.
3. Standard tools for processing metadata values can be used without modification. Easier development and better backwards compatibility with existing tools.

[selfissued]

You raise a good point about consistency and using standard processing rules. I'll go so far as to say that applying metadata policies would be easier if the syntax were more straightforward.

I believe that the current syntax is the way it is because different endpoints may and will have different supported authentication methods. The multi-level object can represent that. But flattening things, as you suggest, could represent that as well.

For context illustrate the current structure of request_authentication_methods_supported, an example at https://openid.net/specs/openid-federation-1_0-ID4.html#name-openid-provider is:

"request_authentication_methods_supported": {
"authorization_endpoint": [
"request_object"
],
"pushed_authorization_request_endpoint": [
"request_object",
"private_key_jwt",
"tls_client_auth",
"self_signed_tls_client_auth"
]
}

[selfissued]

On the 14-Aug-24 Federation editors' call, @vdzhuvinov agreed that we should flatten this. He said that we don't have metadata policy operators to handle hierarchical structured metadata. I will create a PR.

We should also add guidance saying that metadata values should be individual values or array values.

[Razumain]

@selfissued. What is the status on this one. I would like to update my implementation, but I have to wait until the resolution is defined.

[selfissued]

Thanks for checking in, Stefan. I plan to work on this one today.

[selfissued]

There are deeper issues hiding behind this one. Due to #83, we always require the use of request objects when using automatic registration. So you could always authenticate the request using the request object signature. Does that mean that we don't need to be able to authenticate requests using any of the PAR methods private_key_jwt, tls_client_auth, or self_signed_tls_client_auth?

However, we don't say anything about requiring the use of request objects for authentication requests when explicit registration is used. Is that why we may need to use the PAR methods to authenticate the request, because we don't necessarily have a request object?

Clarification/additional specification appears to be in order. I'd love to hear from the implementers on this.

Cc: @TakahikoKawasaki @rohe @vdzhuvinov @jcmelati @cicnavi @peppelinux