generated from coulomb/repo-seed
Complete IDENTITY-WP-0003 corpus backfill and model refinement
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
This commit is contained in:
@@ -1,50 +1,109 @@
|
||||
# Did Core
|
||||
# W3C DID Core
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Standard. W3C Decentralized Identifiers (DIDs) v1.0 Core.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Decentralized identifiers, verifiable identity subjects, DID documents, and
|
||||
verification methods.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
W3C DID Core: decentralized identifiers, DID subjects, DID controllers, verification methods, and services.
|
||||
DIDs provide externally controlled identifiers with cryptographic verification
|
||||
methods, relevant to portable identity, issuer independence, and synonymity
|
||||
across systems.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **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
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| 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
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **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
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- **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
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **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
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| 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
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- 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
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- W3C DID Core v1.0 — https://www.w3.org/TR/did-core/
|
||||
- DID Specification Registries — https://www.w3.org/TR/did-spec-registries/
|
||||
@@ -1,50 +1,106 @@
|
||||
# Openid4Vc
|
||||
# OpenID for Verifiable Credentials (OpenID4VC)
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Standard suite. OpenID4VCI (issuance), OpenID4VP (presentation), and related
|
||||
OAuth 2.0 profiles for verifiable credentials.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
VC issuance and presentation protocols, wallet-holder flows, and federation of
|
||||
verifiable credential ecosystems.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
OpenID for Verifiable Credentials concepts and identity/federation implications.
|
||||
OpenID4VC bridges OAuth/OIDC infrastructure with W3C Verifiable Credentials,
|
||||
connecting federation protocols to portable claim semantics.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **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
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| 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
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **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
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- 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
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **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
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| 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
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- 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
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- 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
|
||||
@@ -1,50 +1,110 @@
|
||||
# Vc Data Model 2
|
||||
# W3C Verifiable Credentials Data Model 2.0
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Standard. W3C Verifiable Credentials Data Model 2.0 (WD/CR as applicable).
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Verifiable claims, issuers, holders, verifiers, credential lifecycle, and
|
||||
portable identity assertions.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
W3C Verifiable Credentials Data Model 2.0: issuer, holder, subject, verifier, claims, presentations.
|
||||
Verifiable Credentials formalize issuer-holder-verifier semantics for portable,
|
||||
cryptographically verifiable claims about subjects — central to evidence-based
|
||||
identity modeling.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **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
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| 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
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **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
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- **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
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **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
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| 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
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- 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
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- 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/
|
||||
Reference in New Issue
Block a user