diff --git a/registry/README.md b/registry/README.md new file mode 100644 index 0000000..569abe9 --- /dev/null +++ b/registry/README.md @@ -0,0 +1,12 @@ +# Capability Registry + +Markdown-first capability index for federation and reuse planning. + +## Authoring + +1. Copy a capability entry template (see reuse-surface `templates/capability-entry.template.md`). +2. Add the row to `indexes/capabilities.yaml`. +3. Run `reuse-surface validate` from a checkout with the CLI installed. +4. Merge to `main` and verify publish with `reuse-surface establish --publish-check`. + +Federation contract: reuse-surface `docs/RegistryFederation.md`. diff --git a/registry/capabilities/capability.identity.subject-resolution.md b/registry/capabilities/capability.identity.subject-resolution.md new file mode 100644 index 0000000..c4afcad --- /dev/null +++ b/registry/capabilities/capability.identity.subject-resolution.md @@ -0,0 +1,115 @@ +--- +id: capability.identity.subject-resolution +name: Identity Subject Resolution +summary: Resolve who or what is acting in a context by mapping principals, accounts, actors, and identifiers to a stable subject model. +owner: identity-canon +status: draft +domain: helix_forge +tags: + - identity + - subject + - architecture + +maturity: + discovery: + current: D3 + target: D5 + confidence: medium + rationale: > + Subject/principal terminology is explored in identity-canon conflict maps + and conceptual model, but dedicated use-case grounding is incomplete. + availability: + current: A0 + target: A4 + confidence: low + rationale: > + Canon and research artifacts exist; no standalone resolver service or SDK + is registered yet. + +external_evidence: + completeness: + level: C1 + name: Fragmentary + confidence: low + basis: scope_vs_intent_and_consumer_expectations + satisfied_expectations: + - overloaded subject and principal terms are mapped as candidates + broken_expectations: + - no runtime resolver artifact + - canonical subject model not finalized across all actor types + out_of_scope_expectations: + - authentication protocol implementation + - credential storage + reliability: + level: R0 + confidence: low + basis: consumer_quality_signals + known_reliability_risks: + - draft terminology may change during source-note backfill + +discovery: + intent: > + Give planners and implementers a consistent subject concept for authorization, + feature control, tenancy, and agent workflows without collapsing product-specific + identity models. + includes: + - subject vs principal vs account distinctions + - actor type modeling + - identifier resolution concepts + excludes: + - authentication execution + - credential issuance + - directory provisioning + assumptions: + - vocabulary canonicalization supports but does not replace subject resolution + use_cases: + - UC-RS-004 + research_memos: + - identity-canon/terminology/TerminologyConflictMap.md + - identity-canon/model/ConceptualModel.md + +availability: + current_level: A0 + target_level: A4 + current_artifacts: + - identity-canon/model/ConceptualModel.md + - identity-canon/canon/CanonicalGlossary.md + target_artifacts: + - identity-canon/packages/subject-resolution-sdk + consumption_modes: + - informational + +relations: + depends_on: + - capability.identity.vocabulary-canonicalize + supports: + - capability.feature-control.evaluate + - capability.statehub.workstream-coordinate + related_to: [] + +evidence: + documentation: + - identity-canon/canon/CanonicalGlossary.md + - identity-canon/scenarios/ScenarioTests.md + tests: [] + consumer_feedback: [] + bug_reports: [] + incidents: [] + +consumer_guidance: + recommended_for: + - architecture planning where subject/principal/account terms overlap + not_recommended_for: + - runtime authentication or token validation + - treating draft canon as finalized resolver behavior + known_limitations: + - resolver artifacts are not yet available +--- + +# Identity Subject Resolution + +## Overview + +Subject resolution defines how actors and identifiers map to a stable subject +concept for downstream capabilities such as feature evaluation and coordination. +Today this capability is planning-heavy (D3/A0). \ No newline at end of file diff --git a/registry/capabilities/capability.identity.vocabulary-canonicalize.md b/registry/capabilities/capability.identity.vocabulary-canonicalize.md new file mode 100644 index 0000000..1ead200 --- /dev/null +++ b/registry/capabilities/capability.identity.vocabulary-canonicalize.md @@ -0,0 +1,136 @@ +--- +id: capability.identity.vocabulary-canonicalize +name: Identity Vocabulary Canonicalization +summary: Define and maintain an implementation-neutral vocabulary for identity-related concepts across overlapping domains. +owner: identity-canon +status: draft +domain: helix_forge +tags: + - identity + - terminology + - research + +maturity: + discovery: + current: D4 + target: D6 + confidence: medium + rationale: > + identity-canon has researched overlapping terminology across IAM, + directory, federation, and authorization domains, but use-case saturation + is not yet demonstrated. + availability: + current: A0 + target: A2 + confidence: medium + rationale: > + The capability is available as research and canon documentation only. + Future source modules or libraries could raise availability to A2. + +external_evidence: + completeness: + level: C2 + name: Partial + confidence: low + basis: scope_vs_intent_and_consumer_expectations + satisfied_expectations: + - draft canonical glossary exists + - terminology conflict map exists + - conceptual model and scenario tests exist + broken_expectations: + - individual source notes are not fully backfilled + - many mappings remain candidate rather than finalized + out_of_scope_expectations: + - operating identity providers + - provisioning or authorization engines + reliability: + level: R0 + confidence: low + basis: consumer_quality_signals + known_reliability_risks: + - draft canon terms may change as source evidence is backfilled + +discovery: + intent: > + Provide a reusable planning primitive for identity vocabulary so architects + and agents can compare overlapping terms consistently without collapsing + product-specific meanings into one ambiguous label. + includes: + - canonical glossary maintenance + - terminology conflict mapping + - conceptual model and scenario tests + - research corpus indexing + excludes: + - identity provider implementation + - account lifecycle services + - authorization policy enforcement + assumptions: + - external product mappings remain separate from canonical definitions + use_cases: + - UC-RS-004 + - UC-RS-006 + research_memos: + - identity-canon/ResearchProposal.md + - identity-canon/canon/CanonicalGlossary.md + +availability: + current_level: A0 + target_level: A2 + current_artifacts: + - identity-canon/canon/CanonicalGlossary.md + - identity-canon/terminology/TerminologyConflictMap.md + - identity-canon/model/ConceptualModel.md + target_artifacts: + - identity-canon/packages/identity-vocabulary + consumption_modes: + - informational + - markdown research artifacts + +relations: + depends_on: [] + supports: + - capability.feature-control.evaluate + - capability.registry.register + related_to: + - capability.identity.subject-resolution + +evidence: + documentation: + - identity-canon/INTENT.md + - identity-canon/canon/CanonicalGlossary.md + tests: [] + consumer_feedback: [] + bug_reports: [] + incidents: [] + +consumer_guidance: + recommended_for: + - architecture and planning conversations involving overloaded identity terms + - comparing IAM, directory, and authorization vocabulary without forcing one product model + not_recommended_for: + - runtime identity resolution + - assuming draft canon entries are finalized standards + known_limitations: + - source-note backfill is incomplete + - mappings may remain candidate until evidence review completes +--- + +# Identity Vocabulary Canonicalization + +## Overview + +This capability makes identity vocabulary reusable for planning across adjacent +domains. It is intentionally research-heavy and informational, illustrating a +D4/A0/C2/R0 vector that contrasts with implementation-ready entries. + +## Current reuse mode + +Consumers read canon, terminology, and model artifacts in the identity-canon +repository. The value is planning reuse through shared vocabulary, not runtime +integration. + +## Relation to adjacent capabilities + +Feature-control evaluation depends on consistent subject and tenant concepts. +This capability supports that planning layer without providing runtime identity +services itself. \ No newline at end of file diff --git a/registry/indexes/capabilities.yaml b/registry/indexes/capabilities.yaml new file mode 100644 index 0000000..d7f13d2 --- /dev/null +++ b/registry/indexes/capabilities.yaml @@ -0,0 +1,34 @@ +version: 1 +updated: '2026-06-16' +domain: helix_forge +capabilities: +- id: capability.identity.subject-resolution + name: Identity Subject Resolution + summary: Resolve who or what is acting by mapping principals, accounts, actors, + and identifiers to a stable subject model. + vector: D3 / A0 / C1 / R0 + domain: helix_forge + status: draft + owner: identity-canon + path: registry/capabilities/capability.identity.subject-resolution.md + tags: + - identity + - subject + - architecture + consumption_modes: + - informational +- id: capability.identity.vocabulary-canonicalize + name: Identity Vocabulary Canonicalization + summary: Define an implementation-neutral vocabulary for identity-related concepts + across overlapping domains. + vector: D4 / A0 / C2 / R0 + domain: helix_forge + status: draft + owner: identity-canon + path: registry/capabilities/capability.identity.vocabulary-canonicalize.md + tags: + - identity + - terminology + - research + consumption_modes: + - informational