Federation: jwks in entity statements

[Torsten Lodderstedt]

Why is thejwks claim mandatory in entity statements. Wouldn’t it be sufficient to assert attributes about the entity and refer to the respective entity using the entity id in the sub claim? The signing keys of the respective entity can be obtained via entity id/entity configuration/jwks or jwks_uri.

Forcing deployments to add the keys to the entity statements makes key rotation harder.

[Giuseppe De Marco]

We have Federation jwks and Oauth2/OIDC jwks in the metadata types.
I assume that your question is related to the Federation jwks involved for federation operations.

the federation jwks in the entity statement issued for a descendant give us the public key to be used for the validation of the entity configuration (self-issued entity statement) of the descendant. Those jwks represent the concrete proof that a TA/intermediary knows the descendant and give us the jwks to verify the statement issued by it, it’s the basic component of the trust mechanism in Federation.

the level of security relies in more than a single component, the federation jwks are published in two different places by two different organizations. The OAuth2/OIDC jwks may be published in a entity statement, in the metadata parameter, issued by a superior, so even in this case we have more than a single place to check the consistency and the validity of what, differently, would be declared by a single subject. This increases the security of the solution, moving a system that would otherwise be based on self-declarations to one based on verifiable third-party declarations.

this aspect is only an implementation that Federation proposes, its requirement rely on an underlying trust framework/model, where more than a single organization must be involved to establish the trust on the mechanisms of delegation.

We have a mitigation to reduce the costs of federation keys rotation: jwks is a list, so new jwks can be added and old one can be removed after a while (in the trust chain exp time window). In italy we’re considering to adopt onboarding APIs to have this in a completely automatic way, and removing the need for an human to update the federation jwks by hands, in the onboarding system of TA/intermediary.

[Torsten Lodderstedt]

Thanks for describing the difference between the different jwks.

I guess I have different requirements/ ideas in my head that I need to sort out:

1) I think it makes sense to distinguish how the entity statement is delivered. If it is delivered as part of a trust chain, those federation keys are the only way to securely link the chain together. However, if the statements are delivered through the entities federation endpoint(s), the checks can rely on the entity identifiers (sub) and secure access to the respective federation data. That simplifies validation in those cases.

2) If the jwks are provided in the statement, they could also refer to a certain jwks_uri (which kind of has elements of (1)).

‌

[Giuseppe De Marco]

1. Taken an entity statement issued by a Trusted third party and assuming that It would publish the entire metadata of the subject Is probably a solution, that seems close to what we already have in saml2 with MDQ. What you propose Is Instead giving only the subjectid but this doesnt give you the assurance that the subject have not been compromised (DNS zone transfer). Federation give by default a very High security profile. If this doesnt matter we have two option: a. Federation jwks remain mandatory, b. Federation jwks would be optional. I'm completely against the option B. The schema of the security profile must not change, an implementation profile May ignore the federation jwks but federation should not decrease the security of its solution that It offers by default.

2. It Is already in this way and regarding specific metadata types, and not federation jwks. A superior can publish a metadata policy that force for a OP a specific jwks_uri. Or did you meant jwks_uri for federation jwks? Is there the need to have this feature in the federation jwks? If yes we have discussed It but then we have realizer that federation entity Discovery produces many https connections and we have found this feature quite expensive. If It would as you propose the parameter would be signed_jwks_uri for the federation jwks, because these are signed inside the statement that envelopes them, so using an external resource from the statement they would be signed at the same way, with the federation jwks published in the entity configuration of its issuer

I want to share clear pointers, i dont want to stop the discussion here or in this way. The scope of this issue Is not the resolution of itself but the consensus on the solutions given.

Can you describe in a bullet point the solution you're looking for? The interaction of the entities driven by statements and parameters, It would help other contributions

[Michael Jones]

Entity statements are currently always signed JWTs. The jwks provides the keys used to sign them.

In the new text I plan to write to resolve https://bitbucket.org/openid/connect/issues/1728, I'll note that the keys are unnecessary when the Entity Statement is secured with Web PKI rather than as a JWT.

[Giuseppe De Marco]

this PR made a clarification about the role of federation entity jwks and its usage in the trust marks validation.
https://bitbucket.org/openid/connect/pull-requests/380

I’ll try to find how to improve the text to get more explicit the differences between it and the oidc/oauth2 metadata jwks

[Michael Jones]

The need for explicitly publishing the keys is motivated by the Cryptographic Trust Mechanism described in https://bitbucket.org/openid/connect/pull-requests/447. I propose this issue be closed after that PR is merged.

[Giuseppe De Marco]

Closed by https://bitbucket.org/openid/connect/pull-requests/447