Prompt and scope
Several universities want to share verifiable directories of institutions and credential issuers without relying on one central registry. Explain how you would model RecognizedEntity, RecognizedAction, and VerifiableRecognitionCredential, and handle privacy, revocation, impersonation, and conflicting registries.
W3C Recognized Entities v1.0 is currently a First Public Working Draft. It describes a data model for an entity recognized by an ecosystem to perform a specific action, allowing recognition information to be published or handed directly to a verifier. The question tests verifiable data modeling and trust decisions without treating the Working Draft as a final standard.
What the interviewer evaluates
The interviewer looks for separate models for entities, actions, recognizers, credential validity, and verification policy, plus cross-registry checks, revocation, and privacy boundaries. A strong answer notes that a holder-provided credential need not be accepted by a verifier and that a recognition assertion is not automatic business authorization.
Clarifying questions before answering
- Who is the recognizer, recognized entity, and final verifier, and which registries does each trust?
- Is the recognized action issuing, verifying, or something else, and how is its output schema defined?
- Is the credential handed to the verifier directly, or must current status be fetched from the issuer?
- What revocation, validity, key-rotation, and privacy requirements apply?
- Who arbitrates and records the reason when registries disagree?
30-second answer framework
“I would model the entity, action, recognizer, and credential assertion as verifiable objects. RecognizedEntity links through recognizedTo to an action; the action names recognizedBy and an output schema; and VerifiableRecognitionCredential records the issuer, validity, and subject set. A verifier checks the signature, status, and time, then selects recognizers under a local trust policy, follows recognition chains, and validates the output schema. A holder-provided credential can avoid a lookup, but it cannot replace freshness checks for high-risk decisions. I would minimize personal data and audit revocation, key rotation, and conflict decisions.”
Step-by-step deep answer
1. Model entities, actions, and recognition
Use a globally unique URL for the entity and point recognizedTo to one or more RecognizedAction objects. An action includes a name, recognizer, and schema for validating outputs; do not encode “the institution is trusted” as an unscoped boolean. recognizedIn can reference an existing trust list or another recognition credential so verifiers can identify the ecosystem behind the assertion.
2. Wrap the assertion as a verifiable credential
The credential must conform to Verifiable Credentials Data Model v2.0 and include its type, issuer, validFrom, validUntil, and recognized entities in credentialSubject. A valid signature proves control of an issuer key, not that the verifier should trust that issuer; apply local trust roots, allowlists, and action scope as a separate decision.
credential = {
type: ["VerifiableCredential", "VerifiableRecognitionCredential"],
issuer: "did:web:accreditor.example",
validFrom: "2026-01-01T00:00:00Z",
credentialSubject: [{
id: "did:web:university.example",
recognizedTo: [{ action: "issue", outputValidation: [schema] }]
}]
}3. Design verification and recognition chains
Check syntax, signature, issuer, validity, revocation, and schema first, then determine whether the recognizer belongs to the local trust set. For multi-level recognizedBy or recognizedIn chains, set a maximum depth, detect cycles, and validate each level's period; a longer chain is not automatically more trusted. Cross-check ETSI Trust Service Lists, X.509 CA lists, or another controlled registry when the policy requires it.
4. Handle freshness and revocation
A holder can present the credential directly, reducing issuer lookups, but the verifier decides based on risk whether to check current status. Use short validity, status lists, revocation notifications, or registry versions; record verification time, trust root, and context hash. Revocation must beat a cache hit when a key rotates, an issuer is compromised, or the recognized action changes.
5. Protect privacy and prevent abuse
Publicly listing names, identifiers, organizational relationships, and actions can enable surveillance or guilt by association. Minimize fields per context and prefer holder-controlled selective disclosure; do not infer unrelated properties from one recognition. Prevent malicious holders from propagating false credentials by jointly validating signatures, status, source, and schema and restricting acceptable issuers.
6. Govern conflicts and rollback
Different registries may assign different actions, validity, or status to the same entity. Define precedence, scope, time, and evidence rules before storing a decision, and audit the reason selected. Version contexts, schemas, and verification algorithms when the Working Draft changes; shadow-read without changing business authorization. Impersonation, privacy leakage, or verification regressions should disable the new path and restore the old registry.
High-quality sample answer
I would model RecognizedEntity, RecognizedAction, the recognizer, and VerifiableRecognitionCredential separately. The entity has a global URL, the action names its scope, recognizer, and output schema, and the credential follows VC Data Model 2.0 with issuer, validity, and subjects. The verifier checks signature, time, revocation, and schema, then applies local trust roots and allowlists; recognition chains have depth and cycle limits and may be cross-checked against ETSI or X.509 lists. Holder-presented credentials reduce lookups but do not remove freshness checks for high-risk cases. Minimize personal fields to avoid surveillance or guilt by association. Resolve registry conflicts with scope, time, and governance rules and audit the result. Version contexts and verifiers during Working Draft updates, and roll back when impersonation, stale revocation, or privacy failures appear.
Common mistakes
- Treating a valid signature as business trust → it only proves key control → still check trust roots, status, and action scope.
- Encoding recognition as an unscoped trusted flag → the recognized action is lost → model
recognizedToand an output schema. - Always trusting the holder's newest credential → it may be revoked or expired → check status and validity according to risk.
- Publishing a complete personal registry → aggregation can enable surveillance → minimize disclosure and limit aggregation.
- Taking the first result when registries conflict → decisions become unauditable and manipulable → define precedence, scope, time, and evidence.
Follow-up questions and responses
Why does a recognition credential not grant business permission directly?
It asserts that a recognizer knows an entity to perform an action. Business permission also depends on resource, tenant, time, risk, and local policy.
How do you prevent infinite recognition chains?
Set a maximum depth, track visited identifiers, and enforce a total budget; fail and record the reason on cycles or limits.
When must a verifier fetch current status?
For high-value transactions, short revocation windows, key compromise, or registry-version changes. Lower-risk cases may use versioned, time-bounded caches.
How do you handle a person being recognized incorrectly?
Provide revocation, appeal, and correction paths; minimize public fields; preserve issuance and verification evidence; and stop accepting the old credential when the corrected state is effective.
How do you trial a Working Draft safely?
Shadow-verify in isolated tenants without changing business authorization, pin the specification and test vectors, keep a rollback switch, and expand after implementation and security reviews.