Resolve Response and subject's federation jwks

[zachmann]

I start with a concrete use case:

• An entity wants to verify a trust mark
• It needs to build a trust chain to the trust mark issuer and relies on a resolver to do so
• It needs to verify the signature of the trust mark

Normally, it would obtain the jwks of the trust mark issuer from the tmi's entity configuration as part of the trust chain. However, we used a resolver, the resolve response does not contain the entity configuration or the subject's jwks.

There are different ways how this could be solved:

1. The jwks is included in the metadata under federation_entity in the resolve response
2. The jwks is in the entity configuration of the TMI, which is included in the trust_chain in the resolve response
3. The jwks is in the entity configuration of the TMI which can be simply queried.

I see different challenges with all of these approaches:

1. jwks in the federation_entity metadata is not required; the claim is not defined specifically for the federation_entity entity type, but is a common claim that can be used with all entity types, where section 5.2.1 states "Note that these keys are distinct from the Federation Entity Keys used to sign Entity Statements." which is obviously true for all entity types except federation_entity. It's unclear to me if for federation_entity the jwks there MAY/SHOULD/MUST be equivalent to the federation entity keys from the entity configuration. So it's not clear if this claim from the metadata can be used (even if it is set) to obtain the TMI's federation entity keys.
2. The trust_chain parameter is optional and might not be present. Furthermore it's add complexity for the client to parse the jwt to only obtain the federation entity keys.
3. This is always possible, but requires an additional request and again jwt parsing. Also it's unclear to me if the payload can be trusted (with regards to the jwks claim only) because the resolver was able to successfully build a trust chain or if the entity configuration would need to be properly verified, in which case the resolve request was superfluous.

The easiest solution would be to include the federation entity keys in the resolve response.

What do other's think about this?

[Razumain]

I think I do not fully understand the problem here.

When you say that you use a Resolver to build a trust chain, I think something has gone wrong. Or perhaps this is a particular use-case I don't understand or have never seen.

First, the resolver is used to resolve data about an entity. If that Entity has a Trust Mark, it has already been validated by the resolver, so there is no need to verify it again. If you trust the resolver, the Trust Mark can be considered valid if present.

Second, it is not the primary purpose of a resolver to deliver a trust chain. To provide a trust chain is optional and may not be part of the resolver response. So using a resolver for this task is IMO a bad solution.

If you don't trust the resolver to verify the Trust Mark, you will have to do it yourself without the resolver (Like the resolver does).

So I personally se no issues.

[zachmann]

Indeed, this might be an edge case.

I think it is viable to use a resolver to (only) verify that an entity has a trust path to a trust anchor - even thought you might not be interested in the resolve metadata - if this truly is what you want to know. But you are right, that it makes sense to check if this is really what you want to know or if something else is more suitable.

You are right that the resolver might not return the trust chain, I also said that in my initial statement. But the same is true for the trust marks, so while I could use a resolver to verify the trust marks for an entity, it might also be the case that my particular resolver does not support this and I have to verify the trust mark myself. I can construct different theoretical cases where an entity would need to verify a trust mark even though it uses a resolver, but it's all rather exotic.

I still think it can be useful to obtain the subject's federation entity keys from a resolver. Either as a direct claim or inside the metadata in federation_entity. But for me it's not clear that metadata.federation_entity.jwks is equal to the top level jwks of an entity statement. I guess it's best to open a separate issue for this.