- edited description
[Federation][OP Metadata] jwks claim
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?
Comments (12)
-
reporter -
reporter - edited description
-
Sure
-
reporter Here @Roland Hedberg
https://bitbucket.org/openid/connect/pull-requests/166 -
reporter - changed title to [Federation][OP Metadata] jwks claim
-
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.
-
reporter 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.
-
reporter 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 -
reporter 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?
-
The reasoning about accountability is actually quite good. It makes my want to accept jwks.
But only jwks not jwks_uri.
-
reporter The goal is way to certify a jwk by a third party.
Ok, we have optionsthis 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. -
reporter - changed status to resolved
- Log in to comment