Open Razumain opened 1 month ago
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" ] }
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.
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:
Wouldn't it then be better and more consistent to define:
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: