Distribute frozen federation corpus by concept destination
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
parent
3e3191549a
commit
372f671eef
81 changed files with 14146 additions and 99 deletions
|
|
@ -0,0 +1,109 @@
|
|||
# W3C DID Core
|
||||
|
||||
## Source Type
|
||||
|
||||
Standard. W3C Decentralized Identifiers (DIDs) v1.0 Core.
|
||||
|
||||
## Domain
|
||||
|
||||
Decentralized identifiers, verifiable identity subjects, DID documents, and
|
||||
verification methods.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
DIDs provide externally controlled identifiers with cryptographic verification
|
||||
methods, relevant to portable identity, issuer independence, and synonymity
|
||||
across systems.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **DID**: globally unique URI following `did:method:identifier` syntax.
|
||||
- **DID subject**: entity identified by a DID; may be person, org, or thing.
|
||||
- **DID controller**: entity authorized to change DID document (may differ from
|
||||
subject).
|
||||
- **DID document**: JSON-LD document resolved from DID; contains verification
|
||||
methods, services, and controllers.
|
||||
- **Verification method**: cryptographic key or proof mechanism for authentication
|
||||
or signing.
|
||||
- **Service endpoint**: machine-readable service URL in DID document.
|
||||
- **DID method**: specific ledger or resolution rules (`did:web`, `did:key`,
|
||||
`did:ion`, etc.).
|
||||
- **Resolution**: process of retrieving DID document from DID URL.
|
||||
- **Also-known-as / equivalentId**: related identifier properties (method-specific).
|
||||
- **Delegation**: controller grants another party control via verification
|
||||
relationship.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| DID | Decentralized identifier string. |
|
||||
| DID subject | Entity the DID names. |
|
||||
| DID controller | Party that can update DID document. |
|
||||
| DID document | Resolved metadata about DID. |
|
||||
| Verification method | Key/material for prove/control. |
|
||||
| Service | Endpoint declaration in document. |
|
||||
| DID method | Resolution and registry rules. |
|
||||
| Resolve | Fetch DID document. |
|
||||
| Controller | Authority over DID lifecycle. |
|
||||
| Subject (DID) | Identified party; not necessarily controller. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Identifier is primary**; subject is named by DID, not stored in central directory.
|
||||
- **Control is cryptographic** via verification methods and controllers.
|
||||
- **Subject and controller may diverge** (custodial wallets, organizational DIDs).
|
||||
- **DID document is mutable** under controller authority.
|
||||
- **Methods vary in persistence, privacy, and registry model.**
|
||||
- **No built-in person/account distinction**; semantics are method and usage dependent.
|
||||
- **Relationships to other DIDs** may appear as services or custom properties.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- **DID** maps to **Identifier** (decentralized, resolvable).
|
||||
- **DID subject** maps to **Actor** or target of **Claim** depending on usage.
|
||||
- **DID controller** maps to **Representation** or **Ownership** relationship
|
||||
over identifier control.
|
||||
- **Verification method** maps to **Credential** (cryptographic).
|
||||
- **DID document** maps to **Profile** / metadata record for Identifier.
|
||||
- **Service endpoint** maps to operational binding (downstream).
|
||||
- DID-based strong binding supports S13 (verified link), S14 (pseudonymous
|
||||
scoped identity when using pairwise/privacy-preserving methods).
|
||||
- Reinforces **P8** (evidence via cryptographic verification).
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Subject**: DID subject vs. OIDC sub vs. authorization subject.
|
||||
- **Controller vs. Owner**: controller is key/document authority; owner is
|
||||
broader relationship.
|
||||
- **Identity vs. DID**: DID is identifier, not identity record.
|
||||
- **Credential vs. Verification method**: verification method is key material;
|
||||
VC is claim artifact.
|
||||
- **Resolve vs. Lookup**: resolution is method-specific; not uniform directory.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| DID Core concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| DID | Identifier |
|
||||
| DID subject | Actor (context-dependent) |
|
||||
| DID controller | Representation or Ownership Relationship |
|
||||
| DID document | Profile / Identifier metadata record |
|
||||
| Verification method | Credential |
|
||||
| Service endpoint | Operational binding (downstream) |
|
||||
| DID method namespace | Scope (method-specific) |
|
||||
| Resolution result | Evidence Source |
|
||||
| equivalentId / alsoKnownAs | Synonymity Assertion (method-dependent) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should DID be a distinct Identifier subtype with method and resolution metadata?
|
||||
- How should subject/controller split map for organizational vs. personal DIDs?
|
||||
- Does equivalentId warrant weak or strong Synonymity by default?
|
||||
- How do DID methods with pairwise features (e.g., did:ion pairwise) map to
|
||||
Scoped Identifier?
|
||||
|
||||
## References
|
||||
|
||||
- W3C DID Core v1.0 — https://www.w3.org/TR/did-core/
|
||||
- DID Specification Registries — https://www.w3.org/TR/did-spec-registries/
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
# OpenID for Verifiable Credentials (OpenID4VC)
|
||||
|
||||
## Source Type
|
||||
|
||||
Standard suite. OpenID4VCI (issuance), OpenID4VP (presentation), and related
|
||||
OAuth 2.0 profiles for verifiable credentials.
|
||||
|
||||
## Domain
|
||||
|
||||
VC issuance and presentation protocols, wallet-holder flows, and federation of
|
||||
verifiable credential ecosystems.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
OpenID4VC bridges OAuth/OIDC infrastructure with W3C Verifiable Credentials,
|
||||
connecting federation protocols to portable claim semantics.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **OpenID4VCI**: issuer-to-holder credential issuance using OAuth 2.0 access
|
||||
tokens and credential offers.
|
||||
- **OpenID4VP**: holder-to-verifier presentation using authorization requests
|
||||
and VP tokens.
|
||||
- **Credential Issuer**: OIDC/OAuth entity issuing VCs.
|
||||
- **Wallet / Holder**: stores credentials and responds to presentation requests.
|
||||
- **Verifier**: requests and validates presentations.
|
||||
- **Credential Offer**: deeplink/URI initiating issuance to wallet.
|
||||
- **Proof of possession**: holder proves control of key bound to credential.
|
||||
- **Authorization Request (VP)**: verifier specifies required credential types.
|
||||
- **SD-JWT VC**: selective disclosure JWT credential format (parallel track).
|
||||
- **mDL / ISO 18013-5**: mobile document format integrated in some profiles.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Credential Issuer | OAuth/OIDC party issuing VCs. |
|
||||
| Wallet | Holder software storing VCs. |
|
||||
| Verifier | Party requesting VP from wallet. |
|
||||
| Credential offer | Issuance initiation artifact. |
|
||||
| Authorization request | Presentation request to wallet. |
|
||||
| VP token | Presentation response token. |
|
||||
| c_nonce | Issuance proof challenge. |
|
||||
| format | VC encoding (jwt_vc, ldp_vc, sd-jwt). |
|
||||
| credential_definition | Type/filter for requested credential. |
|
||||
| presentation_definition | Verifier's input requirements. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Issuance is OAuth-mediated** between issuer, wallet, and optional broker.
|
||||
- **Presentation is verifier-driven** with explicit requested claim types.
|
||||
- **Holder wallet is trust boundary** for credential storage and selective disclosure.
|
||||
- **OIDC identity may bootstrap wallet** or issuer trust.
|
||||
- **Multiple credential formats** coexist (JWT, JSON-LD, SD-JWT).
|
||||
- **Revocation/status checked at verification** time.
|
||||
- **Pairwise issuance** possible for privacy-preserving credentials.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- OpenID4VCI issuance flow maps to **Credential** creation with **Claim**,
|
||||
**Issuer** Scope, and **Evidence Source** (issuance event).
|
||||
- OpenID4VP presentation maps to verifier **Trust Relationship** evaluating
|
||||
**Credential** + **Claim** subset.
|
||||
- **Wallet** maps to holder **Actor** + storage **Scope** (custody boundary).
|
||||
- OIDC authentication preceding issuance maps to **Authenticated Subject** →
|
||||
**Account** → VC **Subject** binding via **Identifier Binding**.
|
||||
- Selective disclosure supports S14 (privacy-limited claims).
|
||||
- Bridges federation (OIDC) and VC layers for S13 strong links.
|
||||
- Reinforces projection pattern: OIDC for auth, VC for claims.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Issuer**: OIDC issuer vs. VC issuer — often same entity, different roles.
|
||||
- **Subject**: OIDC sub in token vs. VC credentialSubject.
|
||||
- **Credential**: OAuth credential vs. Verifiable Credential.
|
||||
- **Verifier vs. RP**: overlapping roles with added VP verification.
|
||||
- **Wallet vs. Account**: wallet is credential store, not always login account.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| OpenID4VC concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Credential Issuer | Issuer Scope + Trust Relationship |
|
||||
| Wallet / Holder | Actor (custody) + Scope |
|
||||
| Verifier | Verifier / RP Scope |
|
||||
| Issued VC | Credential + Claim |
|
||||
| Credential offer | Evidence Source (issuance initiation) |
|
||||
| Presentation | Credential presentation (operational) |
|
||||
| OIDC auth prior to issuance | Authenticated Subject → Identifier Binding |
|
||||
| presentation_definition | Verifier policy (downstream) |
|
||||
| SD-JWT selective disclosure | Privacy-limited Claim exposure |
|
||||
| Status check | Lifecycle State verification |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should wallet custody be a canonical Scope specialization (Holder Scope)?
|
||||
- How should OIDC sub to VC subject binding strength be classified (weak vs.
|
||||
strong Synonymity)?
|
||||
- Does OpenID4VP verifier policy belong in canon or strictly downstream?
|
||||
- Should SD-JWT credentials map to Credential subtype with disclosure metadata?
|
||||
|
||||
## References
|
||||
|
||||
- OpenID4VCI — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
|
||||
- OpenID4VP — https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
|
||||
- OpenID4VCI SD-JWT profile — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-sd-jwt-vc
|
||||
|
|
@ -0,0 +1,110 @@
|
|||
# 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
|
||||
|
||||
- W3C VC Data Model 2.0 — https://www.w3.org/TR/vc-data-model-2.0/
|
||||
- VC Data Model 1.1 (widely deployed) — https://www.w3.org/TR/vc-data-model/
|
||||
- Status List 2021 — https://www.w3.org/TR/vc-status-list-2021/
|
||||
Loading…
Add table
Add a link
Reference in a new issue