[Federation][OP Metadata] jwks claim

[Giuseppe De Marco]

In OIDC Dynamic Client Registration we have jwks and jwks_uri as OPTIONAL claim for RPs.
In OpenID Connect Discovery 1.0 we have only jwks_uri as REQUIRED for OPs.

Why OpenID Connect Discovery 1.0 doesn’t have jwks as well, as for RP?

In OpenID Federation we have signed_jwks_uri for RP and OP, as OPTIONAL metadata claim.
signed_jwks_uri points to a signed JWT containing the jwks, this JWT MUST be signed with the jwks published in the Entity Statement of its issuer.

In the OIDC Federation specs I propose to have the jwks claim in the OP metadata, to allow the OIDC public keys to be signed directly in the Entity Statement and trusted with the Chain, without any additional pointer/check to another url as it is for signed_jwks_uri (that adds an additional verification of the signature and then so much complexity).

Do you think it is possible to open a PR on OIDC Federation to get jwks among the claims of the OP metadata?

[Roland Hedberg]

Sure

[Giuseppe De Marco]

Here @Roland Hedberg
https://bitbucket.org/openid/connect/pull-requests/166

[Michael Jones]

The reason that OP Metadata doesn’t have a “jwks” option is that it wouldn’t facilitate key rotation in the same way that “jwks_uri” does. Therefore, I am opposed to adding a “jwks” option to OP metadata.

‌

[Giuseppe De Marco]

This proposal is linked to the possibility that disputes may arise between a RP and a OP relating to different organisations.

We are looking at the possibility that access that has taken place in the past, in the dimension of authorisation that has been obtained, can be repudiated. This is obviously covered by the electronic signature evidence of the request object (RP side) from the released tokens (OP side). However, if one of the parties changes its keys, there is no way to trace a certifiable history to a trusted third party.

If a OP forged an authorization granted to a RP in the past, using a fake signature, there would be no certifiable evidence of all the public keys of that RP used in the past.

Getting jwks inside a entity configuration (metadata), for example, gives a trusted third party the ability to collect certificates, sign them, and store them in a history. Moreover, obtaining jwks in the metadata of an OP offers the possibility to apply the metadata rules also on jwks by a superior. I don’t want to "add problems or invent new ones" but I have an obligation to explore the possibilities offered by OIDC Fed to understand how to fill this gap. Getting jwks in the metadata would seem to be a general and preferable solution.

[Giuseppe De Marco]

Here a linked issues that may be adopted in addition to this proposal or as alternative to this
https://bitbucket.org/openid/connect/issues/1494/federation-resolve-entity-endpoint-proof

[Giuseppe De Marco]

However, is this a typo in the text?
This statement assumes that a OP CAN use the claim jwks in its metadata.

Having said that we CAN’T enable the claim jwks in the OP metadata, is this intended as an error in the text that must be therefore fixed?

‌

[Roland Hedberg]

The reasoning about accountability is actually quite good. It makes my want to accept jwks.

But only jwks not jwks_uri.

[Giuseppe De Marco]

The goal is way to certify a jwk by a third party.
Ok, we have options

this definitely removes the jwks claim from the OP metadata: https://bitbucket.org/openid/connect/pull-requests/174 (Roland may accept this)
this definitely enables the jwks claim in the OP metadata: https://bitbucket.org/openid/connect/pull-requests/166 (Mike don’t want this)

using jwks this can be certified by a superior
using a redefinition of the signed_jwks_uri (https://bitbucket.org/openid/connect/issues/1498/federation-metadata-redefinition-of) we can obtain the same result in a different way.

[Giuseppe De Marco]

Closed by

https://bitbucket.org/openid/connect/pull-requests/166