Re: [OAUTH-WG] PAR metadata

[Filip Skokan <[e-mail]>]

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
<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#table-client-metadata>
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
<https://bitbucket.org/openid/mobile/issues/102#comment-48494839> related
to the same question about auth metadata but for CIBA.

Best,
*Filip*


On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <[e-mail]>
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.