[msporny]

This is an attempt at a fix for issue M-02 from the Security Review by SING: w3c/security-request#141 (comment)

WARNING: I'm not convinced that the text being proposed is what we want to do. I tried to address the issue as raised, but it seems to be somewhat related to issue #121, and feels a bit inelegant. I can't quite put my finger on what's wrong... help.

/cc @simoneonofri

---

Preview | Diff

[onthebreeze]

@TallTed says

+[=Recognition validation=] then checks the assembled chain. Healthy Tots is
+recognized to issue by GS1 Utopia, which is what the key credential needs.
+GS1 Utopia is an intermediate in this chain, so it is checked as well: the
+GS1 Global Office credential recognizes GS1 Utopia to issue, so GS1 Utopia
+was allowed to perform the action it recognized Healthy Tots to perform. Had
+the GS1 Global Office recognized GS1 Utopia to perform some or no other
+action(s), the chain would be rejected even though every recognizedIn
+reference resolves and every proof verifies.

Unless I misunderstand, this is exactly the problem I was presenting today. Dept of education issues a recognized-entity credential to brainy university that does two things - (1) says that they are a university, and (2) says that they are recognisedTo issue degree certificates.

Now brainy university issues a student ID card VC and faces a problem

• If the do NOT link that student ID VC to their dept of education issued recognized entity then the studentID is worthless because my brother could have issued it.
• if they DO link that student ID VC to their dept of education issued recognized entity then, according to the text above, the verification fails because the recognized entity credential does not list that recognized action

This is not an edge case. it's the most common baseline scenario. So I'm still of the position that either the data model or the validation rules are wrong.

Adding this to the ticket as well

[TallTed]

@onthebreeze wrote:

@TallTed says

[=Recognition validation=] then checks the assembled chain. Healthy Tots is
recognized to `issue` by GS1 Utopia, which is what the key credential needs.
GS1 Utopia is an intermediate in this chain, so it is checked as well: the
GS1 Global Office credential recognizes GS1 Utopia to `issue`, so GS1 Utopia
was allowed to perform the action it recognized Healthy Tots to perform. **Had
the GS1 Global Office recognized GS1 Utopia to perform some or no other
action(s), the chain would be rejected even though every `recognizedIn`
reference resolves and every proof verifies**.

...

Please note -- I did not "say" the paragraph above. I suggested some minor tweaks to the following paragraph, from @msporny, to whom I think your comments should be addressed.

[=Recognition validation=] then checks the assembled chain. Healthy Tots is
recognized to `issue` by GS1 Utopia, which is what the key credential needs.
GS1 Utopia is an intermediate in this chain, so it is checked as well: the
GS1 Global Office credential recognizes GS1 Utopia to `issue`, so GS1 Utopia
was allowed to perform the action it recognized Healthy Tots for. Had the
GS1 Global Office recognized GS1 Utopia for some other action, or for none,
the chain would be rejected even though every `recognizedIn` reference
resolves and every proof verifies.

[iherman]

This was discussed during the vcwg meeting on 14 October 2026.

View the transcript

w3c/vc-recognized-entities#138

manu: Carolynn actually covered the main topic of discussion at the beginning of the call so I'll jump to a PR that we're unsure about. This came in from a security review on the specification.

manu: That review said that in the RE spec you have organizations that recognized other organizations to do certain things like issue a DL. However, the algorithm doesn't say -- if there are multiple hops in the chain, like a Global Authority that delegates to a National Authority and then to a Regional Authority, etc. -- you don't have anything in the spec that scopes that delegation down.

manu: There's nothing to say that something at the end of the chain can't just issue something for another country or whatnot.

manu: There's this question around -- "what are you allowed to do" per the RE spec. And that kicked off a fairly in depth discussion about that spec. Some people's mental model about the RE spec is that it says what an organization can and cannot do.

manu: And that is a bad mental model for what that spec is about. It's not about that at all.

<JoeAndrieu> +1 for redressing that mental model mistake

manu: VCs are about model world data models, anyone can say anything about anything.

manu: You can say that you recognize that something someone issues, but you can't restrict them.

manu: What someone can do, a Recognized Entity Credential issuer can say they'd recognize certain VCs from a University, but they can't stop that University from issuing whatever they want.

manu: So we're figuring out the proper language to use to respond to the security review here to make it clear how to prevent certain types of scoping attacks, but that the technology is not capable of preventing orgs from issuing other types of credentials.

JoeAndrieu: +1 to everything you just said, I really appreciate the continuing efforts to shift away from the allowance language.

JoeAndrieu: When I talked with Simone about this -- the language currently is about chain of authority and applies the legitimacy of transitive trust and that's a problem. I could choose to trust both AAMVA or AAA for some VCs.

JoeAndrieu: That pattern -- "I'm only trusting the list maker" follows a coherent trust model, but if we're creating a certificate hierarchy then you have to independently evaluate what it implies.

JoeAndrieu: The DNS architecture for TLS in particular, started out with an ambition about what it meant to get a green lock on a URL -- that turned out to be more burdensome than it was worth than to just secure the endpoint.

JoeAndrieu: Let's Encrypt just makes sure you can secure the traffic but no longer checks you as a company, etc.

<manu> Agree, Joe :)

brent: Awesome, thank you, Joe, Manu, everybody. We're at time. If any task force has questions for the TAG, the TAG has made themselves available to join our VCWG meeting, so let us know if you'd like them to be there.

brent: Thanks everyone, Dave, thanks for scribing.

dlongley: You're welcome!

---