Files
alknet/tasks/architecture/spec-update-auth.md
glm-5.1 84f16d66e7 tasks: decompose Phase 0b spec documents and Phase 0c review
Add 15 new tasks under tasks/architecture/ for Phase 0b (spec writing)
and Phase 0c (review):

Phase 0b — New specs (6):
  - spec-configuration: promote from research, cleanup, align with ADRs
  - spec-identity: carry from auth.md + services.md, canonical Identity
  - spec-secret-service: from research/services.md SecretProtocol
  - spec-storage: from research/storage.md, contract-level
  - spec-flowgraph: from research/flow.md, pure computation crate
  - spec-interface: new Layer 2 spec (highest risk new spec)
  - spec-services: irpc service layer + OperationEnv (broadest scope)

Phase 0b — Spec updates (6):
  - spec-update-overview: add crate structure, Layer 3, services
  - spec-update-auth: IdentityProvider vs AuthService relationship
  - spec-update-call-protocol: OperationEnv dispatch paths
  - spec-update-server: DynamicConfig, ForwardingPolicy, IdentityProvider
  - spec-update-napi: reload API, call protocol references
  - spec-update-open-questions: resolve OQs per ADR decisions

Phase 0b — Assembly (1):
  - spec-update-readme: add new docs and ADRs to tables

Phase 0c — Review (1):
  - review-spec-foundation: validate consistency checklist

Generation structure (6 total):
  Gen 1: 6 independent ADRs (parallel)
  Gen 2: adr-027, adr-028 (depend on adr-029)
  Gen 3: adr-033 + 6 spec docs + open-questions update (parallel)
  Gen 4: adr review + interface/services specs + 4 spec updates
  Gen 5: call-protocol update + readme update
  Gen 6: spec review
2026-06-07 09:01:01 +00:00

2.5 KiB

id, name, status, depends_on, scope, risk, impact, level
id name status depends_on scope risk impact level
architecture/spec-update-auth Update auth.md — add IdentityProvider vs AuthService relationship pending
architecture/spec-identity
architecture/adr-028-auth-irpc-service
narrow low component implementation

Description

Update docs/architecture/auth.md to add the IdentityProvider vs AuthService relationship and update for the AuthProtocol irpc service per ADR-028.

The current auth.md already defines IdentityProvider trait and Identity struct — which is good. After identity.md exists as the canonical home for those definitions, auth.md should reference identity.md instead of defining them inline.

Changes needed:

  1. Replace inline Identity and IdentityProvider definitions with references to identity.md
  2. Add section on AuthProtocol irpc service (VerifyPubkey, VerifyToken, ReloadKeys, CheckAccess) behind irpc feature flag
  3. Add section on ConfigIdentityProvider as the default impl (ArcSwap-backed)
  4. Clarify the relationship: IdentityProvider is the contract, irpc AuthProtocol is one way to implement it, ConfigIdentityProvider is another
  5. Remove inline decision rationale about IdentityProvider placement — reference ADR-029
  6. Reference ADR-028 for the irpc service decision

What stays the same: Token authentication design, AuthPolicy structure, browser-side token construction, WebTransport session request inspection, security considerations, all existing constraints.

Acceptance Criteria

  • Identity and IdentityProvider definitions reference identity.md (canonical) rather than defining inline
  • AuthProtocol irpc service documented with variants (VerifyPubkey, VerifyToken, ReloadKeys, CheckAccess) per ADR-028
  • ConfigIdentityProvider documented as default implementation (ArcSwap path)
  • Relationship between trait-based path and irpc path clearly stated
  • irpc feature flag mentioned for AuthProtocol
  • Inline decision rationale replaced with ADR references (028, 029)
  • last_updated in YAML frontmatter updated
  • No hub/spoke terminology
  • References section updated to include identity.md, ADR-028, ADR-029

References

  • docs/architecture/auth.md — current content to update
  • docs/research/integration-plan.md — auth.md update entry
  • docs/architecture/decisions/028-auth-irpc-service.md
  • docs/architecture/decisions/029-identity-core-type.md

Notes

To be filled by implementation agent

Summary

To be filled on completion