Subject: [OAUTH-WG] PAR metadata

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 31 Dec 2019 15:38:21 +0100

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.

---

From: Filip Skokan <[email-masked]>
Date: Tue, 31 Dec 2019 16:22:23 +0100

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 <[email-masked]>
wrote:

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

---

From: Brian Campbell <[email-masked]>
Date: Tue, 31 Dec 2019 08:55:51 -0700

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 <[email-masked]> wrote:

> This I do not follow, auth methods and their signing is dealt with by
> using `token_endpoint_auth_methods_supported` and
> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#table-client-metadata> by

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 31 Dec 2019 17:06:06 +0100

Hi Filip, 

> On 31. Dec 2019, at 16:22, Filip Skokan <[email-masked]> 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 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.

Dammed! You are so right. Sorry, I got confused somehow. 

> 
> PS: I also found this comment related to the same question about auth metadata but for CIBA.

Thanks for sharing. 

> Filip

thanks,
Torsten. 

> 
> 
> On Tue, 31 Dec 2019 at 15:38, Torsten Lodderstedt <[email-masked]> wrote:
> Hi all,
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 31 Dec 2019 17:06:33 +0100

wfm

Have a great new year!

> On 31. Dec 2019, at 16:55, Brian Campbell <[email-masked]> wrote:
> 
> 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
> 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.
> 
> 
> 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.