-
Notifications
You must be signed in to change notification settings - Fork 37
Description
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: #140 (comment)_