The single signed metadata in the single .well-known endpoint doesn't scale

[peppelinux]

In the current text we have the signed_metadata (here)

As discussed in our call, we need to highlight the scalability problem associated with having a single signed metadata, signed solely by one trusted third party, in a large ecosystem. In such an ecosystem, an entity may be part of multiple contexts/federations/trust-ecosystems and may need its metadata signed by more than one trusted party for different contexts, depending on which recognizable trusted third party (TTP) a wallet/verifier uses.

for instance: VCIX is part of both ecosystemA and NetworkB and has a signed metadata from TTPA. RP from NetworkB needs to evaluates the signed_metadata regarding VCIX issued by TTPB, while the solution provided in the current text doesn't allow this.

I would suggest to not stuck a single signed metadata but allow more than a single signed metadata, where multiple TTPs are possible, eg:

"signed_metadata": {
  "issuer1": $JWT,
  "issuer2": $JWT,
}

Even if I shared the idea above, I would not embed all those signed metadata in an unsigned metadata but using the OpenID Federation authority hints, where the signed metadata can be provided directly from one or more trusted superiors authorities within the Subordinate Entity Statement. But this is another story.

Despite the possible solutions, the scope of this issue is to raise the issue of the missing scalability of the single signed_metadata.

see: https://github.com/openid/OpenID4VCI/issues/140#issuecomment-1887561094_

[jogu]

I think I commented along these lines before but I can't find it so maybe it was only verbally on the call:

This isn't a matter of just changing from a string to an array, we would also need to define processing rules (i.e. how you combine the different signed metadata together, especially if you trust more than one and they have different contents).

I am not clear there is a need for this:

1. https://datatracker.ietf.org/doc/html/rfc8414 also only supports a single signed metadata.
2. If an issuer is participating in multiple networks it might be easier for it to just have multiple issuer identifiers (i.e. they would be one set of metadata for each network), which is already possible in the spec.

[peppelinux]

Apologies if I overlooked this earlier, and thank you for the insights.

1. I acknowledge the limitations. I agree with the evidence suggesting that only OpenID Federation provides the flexibility I'm seeking. It allows a single entity's metadata to be attested by more than one authority or trusted third party.
2. This point echoes the previous one.

These points pertain to the scalability of the model. If I need to modify (or duplicate with minor alterations) the same entity/metadata for different contexts, I view this as a limitation due to its lack of scalability.

I would argue that for this type of scalability, only OpenID Federation is suitable.