coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/infospace/assimilation/canon-federation/source/research/verifiable-claims/vc-data-model-2.md
tegwick 372f671eef
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Distribute frozen federation corpus by concept destination 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
2026-09-06 00:44:37 +02:00

4.5 KiB
Raw Blame History

W3C Verifiable Credentials Data Model 2.0

Source Type

Standard. W3C Verifiable Credentials Data Model 2.0 (WD/CR as applicable).

Domain

Verifiable claims, issuers, holders, verifiers, credential lifecycle, and portable identity assertions.

Why This Source Matters

Verifiable Credentials formalize issuer-holder-verifier semantics for portable, cryptographically verifiable claims about subjects — central to evidence-based identity modeling.

Key Concepts

  • Verifiable Credential (VC): tamper-evident credential making claims about a subject, signed by issuer.
  • Verifiable Presentation (VP): bundle of VCs (and proofs) presented by holder to verifier.
  • Issuer: entity that asserts claims and signs VC.
  • Holder: entity possessing VC (may or may not be subject).
  • Verifier: entity checking VC/VP validity.
  • Subject: entity claims are about (credentialSubject).
  • Claim: individual statement within credentialSubject.
  • Proof: cryptographic proof of integrity and issuer authenticity.
  • Credential schema: type and structure definition for VC.
  • Status: revocation/suspension via StatusList2021 or similar.
  • ValidFrom / ValidUntil: temporal validity window.
  • Evidence: supporting documents referenced in VC (DID, attachments).

Relevant Terminology

Term Source meaning
Verifiable Credential Signed claim set about subject.
Presentation Holder-submitted package for verification.
Issuer Signing authority for claims.
Holder Party storing/presenting VC.
Verifier Party validating VC/VP.
Subject Entity described by credentialSubject.
credentialSubject Claim object about subject.
Proof Cryptographic verification data.
StatusList Revocation/suspension mechanism.
type VC semantic type(s).
validFrom / validUntil Temporal bounds.

Modeling Assumptions

  • Claims are assertions, not ground truth until verified by verifier policy.
  • Issuer authority is explicit and cryptographically attributable.
  • Holder may differ from subject (custodial credentials).
  • Revocation is first-class via status mechanisms.
  • Temporal validity matters for employment, membership, age claims.
  • Selective disclosure may hide parts of credentialSubject (privacy).
  • Subject may be identified by DID, URI, or other identifier.

Identity-Canon Implications

  • VC maps to Credential containing Claim set.
  • credentialSubject claims map to individual Claim objects about Actor, Membership, or attributes.
  • Issuer maps to issuer Scope + Trust Relationship.
  • Holder maps to Actor or Account holding credential.
  • Verifier maps to relying party evaluating Trust + Evidence.
  • Subject maps to Actor or Identifier target.
  • Status/revocation maps to Lifecycle State on Credential/Claim.
  • validFrom/validUntil map to relationship/assertion temporal bounds.
  • Supports S13 (strong verified link), S03 (org membership claims), S06 (guardian credentials if issued).
  • Reinforces P7 and P8: claims are evidenced assertions.

Terminology Conflicts

  • Credential vs. Credential (auth): VC vs. password/OIDC token.
  • Subject: VC subject vs. OIDC sub.
  • Claim vs. Attribute: VC claim vs. directory/LDAP attribute.
  • Holder vs. Account: holder is possession role, not login account.
  • Verifier vs. RP: overlapping but VC adds cryptographic verification step.

Candidate Canonical Mappings

VC Data Model concept Candidate canonical concept
Verifiable Credential Credential
credentialSubject claim Claim
Issuer Issuer Scope + Trust Relationship
Holder Actor / Account (possession role)
Verifier Relying party / verifier Scope
Subject Actor or Identifier target
Proof Evidence Source (cryptographic)
StatusList entry Lifecycle State (revoked/suspended)
validFrom / validUntil Temporal bounds on Claim
Presentation Credential bundle (operational)

Open Questions

  • Should canon treat VC as Credential subtype or parallel Claim container?
  • How should membership VCs map to Membership Relationship vs. Claim only?
  • Does selective disclosure require Persona or Scoped Identifier linkage?
  • Should issuer DID vs. issuer URL be standardized Identifier forms?

References