Long shot proposal for expressing different entity metadata for different TAs

[cicnavi]

Since there seems to be growing awareness that federation entities will (want / have to) know their TAs, and maybe even express them in their ECs, maybe they could also express different metadata for each of them. If they don't, then the standard / default one can be used.

So, for scenarios in which one entity is member of multiple federations, the proposal is to add a new optional claim to ECs, for example called trust_anchor_metadata (not proposing the actual claim name, just trying to make it descriptive), which would contain TA specific entity metadata.

{
  "metadata": {
    // General, default metadata that applies to all trust anchors
  },
  "trust_anchor_metadata": {
    "https://trust-anchor-1.example.com": {
      "openid_relying_party": {
        "client_registration_types": ["automatic"],
        "token_endpoint_auth_method": "private_key_jwt"
      }
    },
    "https://trust-anchor-2.example.com": {
      "openid_relying_party": {
        "client_registration_types": ["explicit"],
        "token_endpoint_auth_method": "client_secret_post"
      }
    }
  }
}

So, during trust chain resolution, the chosen trust anchor’s metadata section, if it exists, would override the default metadata values before the policy application. Entities that do not need per-anchor metadata can continue to use the metadata section as is, so things should not break for existing implementations. However, this should be relatively easy to implement / refactor on existing implementation.

Alternative: introduce an optional trust_anchor query parameter / hint for the Configuration Endpoint (again, not suggesting actual name, it can be aligned with existing ones when the name is settled #131).

GET /.well-known/openid-configuration?trust_anchor=https://trust-anchor-1.example.com

Based on this hint, entity could then respond with metadata specific to that trust anchor, or return default metadata if no hint is provided or fallback to default if it doesn't have specific metadata / doesn't support the feature (again this should not break existing implementations).

This could also be used for explicit error returning in case if entity doesn't trust the hinted TA, but that's another story...

The whole proposal is probably alternative or maybe addition to #12

[Razumain]

As I stated in another issue here. I consider it a mistake to let the leaf entity decide or modify its metadata based on what TA that is used. This will introduce all kinds of complexity that will be extremely hard to handle.

I suggest that the choice of TA is the choice of the verifier, not the verified party. The leaf entity should simply state its capabilities and preferences disregarding what TA the verifier may use. That is solved by the extended client metadata.

However, I do see the underlying problem that I have pointed out before. The underlying problem I see here is that we have defined policy modifiers that can change the metadata from the values set by the leaf entity. This makes it impossible for the leaf entity to know what metadata the verifier sees. And it sor of requires the leaf to know what TA the verifier will use.

I still believe that policy should only contain value checks, and never add to the metadata declared by the leaf. That would solve that problem. Only the superior IE that issue the Entity Statement for the leaf should be able to modify metadata using the metadata claim if necessary. This is easy to check by the leaf and should be done in close cooperation with the leaf.

[cicnavi]

I've opened this issue because in one of the meetings it was mentioned that inability to specify metadata for/per specific federation is problematic. This idea cross my mind and so I shared it. I'm totally ok for closing this as not relevant any more in favor of extended client metadata (if, for example, expressing client capabilities per federation is not valuable).

I still believe that policy should only contain value checks, and never add to the metadata declared by the leaf.

I see this as a bit contradictory in contrast to "The leaf entity should simply state its capabilities and preferences disregarding what TA the verifier may use. "

[selfissued]

I'm skeptical of

federation entities will (want / have to) know their TAs

I'm more sympathetic to

The leaf entity should simply state its capabilities and preferences

I'm OK with leaving this open while we discuss the Trust Anchor issues, but I'm extremely skeptical of effectively having case statements with different metadata values for different trust anchors.