Re: [OAUTH-WG] PAR metadata

[Brian Campbell <[e-mail]>]

Yeah, I agree. The insights in that comment Filip referenced (copied below)
are very very wise and explain why we should not define
pushed_authorization_endpoint_auth_methods_supported and
pushed_authorization_endpoint_auth_signing_alg_values_supported metadata.


There's some historical weirdness to how client authentication has come to
be represented (and named) in metadata. Client registration metadata has
only a token_endpoint_auth_method, which despite the name has become the de
facto place in the client data model to say how the client will
authenticate to the AS when making any direct client -> AS call. The
parameter name is a bit unfortunate but I believe it makes sense to have a
single (backchannel) authentication method per client. RFC 8414 took a
different direction and has revocation_endpoint_auth_methods_supported and
introspection_endpoint_auth_methods_supported etc., which I believe was a
mistake. I don't see a clear use case for needing or allowing a different
set of auth methods for the different endpoints. And having a bunch of
_supported parameters for different endpoints seems likely to clutter up
the metadata document with a bunch of redundant info.

I'd propose that some text be added into CIBA core that says that, for the
backchannel authentication endpoint, the AS supports the same client
authentication methods as indicated with
token_endpoint_auth_methods_supported. And state that, for a client, the
token_endpoint_auth_method is the authentication method registered for its
client_id regardless of the endpoint being called.


On Tue, Dec 31, 2019 at 8:22 AM Filip Skokan <[e-mail]> wrote:

> 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.
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._