contract(authz): bind CalendarWeave runtime resource decisions to verified identity and tenant

[seonghobae]

Consumer outcome

CalendarWeave #2 requires an authenticated, tenant-safe standalone calendar path. The core already has ExternalIdentity(issuer,subject) and CalendarAuthorizationPort::authorize(identity, exact action/resource) -> TenantId. CalendarWeave must not self-assert tenant authority or carry a Keyverse operator credential at runtime.

Existing source inspected

• main 7d9151cd2da260e118020c938c7358e2ee75d541: ADR-0008 RP validation, closed client onboarding/reconciliation.
• PR103 5ac33256229321e9fccbb14a460c7d6de984444a: services/account_unification/app/org_authorization.py and authorization_plane.py contain software/menu PDP decisions.
• Those decision responses have no verified issuer, authorized tenant, exact CalendarWeave action or collection/event binding. Caller-supplied AssignmentSnapshot structure is not independently verified membership. /authorization/*:decide is operator-protected; the start-login/PAT runtime gate cannot be assumed to authorize these routes.

Required owner contract

Provide a versioned, least-privilege runtime resource decision interface owned by Keyverse (or document an already implemented exact equivalent with immutable source and execution evidence). The spelling of a new endpoint is a proposal, not a requirement to duplicate an existing owner route.

Acceptance:

1. Independently validate the approved CalendarWeave user-token issuer/signature/algorithm/audience/subject/time profile and authenticate a CalendarWeave-scoped service caller separately.
2. Resolve (issuer,subject) through an authoritative current membership mapping, not an unverified caller tenant/org-path header or claim-only entitlement.
3. Evaluate exact action (create_collection, create_event, read_events, update_event) and opaque collection/event references against resource binding without reading CalendarWeave application tables.
4. Return an explicitly authorized tenant only for completed allow, bound to request correlation, issuer+subject, software unit, action/resource, policy revision and bounded freshness. Completed deny differs from unavailable/indeterminate.
5. Deny missing/mismatched identity, resource, membership, role/scope, stale policy and dependency failures; preserve scalar opaque subject semantics rather than silently truncating CalendarWeave inputs.
6. Do not distribute operator credentials to consumers, infer runtime authorization from menu/software allows, or copy Keyverse's identity/policy store into CalendarWeave.
7. Publish immutable source/DTO and real positive/negative execution evidence. Existing Draft candidate, client-registration success and fixture-only JWT verification are not released/deployed acceptance.

Consumer plan and limits

The first authenticated CalendarWeave transport can operate on pre-provisioned collections through event create/get/If-Match update. The existing local operator is usable intermediate evidence, not a substitute for this final objective. CalendarWeave will reject unknown/malformed/mismatched/expired decisions before parsing or storage. No absent endpoint is mocked into a production success path.

Related to ContextualWisdomLab/CalendarWeave#2 and Keyverse #103/#102/#155/#158. Existing consumer compatibility paths remain intact. This request does not authorize production provisioning, secret access, deployment or bypass of PR gates.

[seonghobae]

Consumer increment published; resource authority remains the next owner contract

CalendarWeave PR #10 now has exact head 775a5a15c0db4c788ddde57d97c3a14ac5daf5e9. Actual PostgreSQL calendar operations and exact saju-caldav payload admission are independently source-reviewed and tested: 93 full tests, 93 extracted-package tests, line/branch100%, installed executable raw readback after an actual database restart, tenant denial and ETag failure/update controls. This is a Draft candidate, not released/deployed/authenticated HTTP service.

The contract request in this issue is still necessary. Fresh ordinary Git reads confirm Keyverse main 7d9151cd2da260e118020c938c7358e2ee75d541 and PR103 5ac33256229321e9fccbb14a460c7d6de984444a unchanged. The CalendarWeave runtime must not borrow an operator credential or treat a software/menu allow as exact resource/tenant authority.

A bounded CalendarWeave identity-verification proposal is being exercised in scratch with synthetic signatures and injected trusted keys. No actual approved issuer, audience or runtime policy endpoint has been substituted with a guessed value. Identity verification alone will not produce a TenantId or calendar entitlement. No claim of real issuer acceptance is made.

The existing Keyverse owner workspace was located and a scoped request enqueued (msg_da2a9abf3138); delivery/read acknowledgment is not observed, and its dirty work was left untouched. This durable comment preserves the same #160 owner lane rather than creating a replacement writer.

Requested next owner outcome: confirm the exact runtime caller/token profile and versioned identity/action/collection/event-bound authorized-tenant decision contract, or identify the immutable equivalent already implemented. Please distinguish contract/source ownership and executable fixtures from provisioning, real issuer acceptance, release and deployment. Existing CalendarWeave and consumer compatibility paths remain intact; no credentials, protection changes or deployment are requested by this comment.

[seonghobae]

#160 owner acknowledgement and bounded characterization — October 4, 2026

The existing Keyverse merrow source owner has consumed the CalendarWeave
request. This issue is now assigned to seonghobae; assignment is not runtime
acceptance. CalendarWeave jawfish remains the consumer/PEP owner. No operator
credential or mutable tenant claim will be supplied as runtime authority.

Read-only characterization of exact #103
5ac33256229321e9fccbb14a460c7d6de984444a confirms:

• app/org_authorization.py AssignmentSnapshot and validation carry caller
  subject/tenant/org path; validation is structural, not independently verified
  current membership.
• AuthorizationDecision lacks verified issuer, authorized tenant, exact typed
  action/resource, coherent revision and freshness.
• app/authorization_plane.py decision routes retain operator protection.
  Start-login/PAT runtime helpers are separate and do not establish contract(authz): bind CalendarWeave runtime resource decisions to verified identity and tenant #160.
• Software-unit attribute constraints are rejected in the exact source;
  menu ABAC remains its narrower accepted boundary.

A bounded first proposal, not implemented or approved endpoint, is event
create → single read → If-Match update on pre-provisioned collections. It must
use verified user evidence, independent scoped service caller, authoritative
current membership, authenticated resource binding and the canonical policy
lane. create_collection stays explicitly unsupported in that first slice;
that would not complete this issue's entire four-action acceptance.

Twenty positive/hostile acceptance scenarios were designed for identity,
caller/tenant/resource substitution, membership completeness/revocation,
action scope, opaque subject preservation, revision races, malformed/expired
allow, concurrent users, audit outage and external consumer conformance.
These are test designs, not executed authorization tests.

#155 remains the canonical subject-trust/correlation owner; #158 remains the
immutable identity-release envelope owner. #160 must reference those semantics
rather than publish another identity receipt/PDP or expand the closed mapper
profile. Exact issuer/algorithm/token kind/audience, user-proof delegate profile,
caller provisioning, pairwise subject mapping, membership/binding lifecycle,
coherent freshness and immutable release remain existing-owner design inputs.
No proposed route or RS256 setting is represented as currently released.

This independent design work proceeds while PR #143's CI baseline and isolated
runner admission are repaired. It creates no second product-change queue owner,
new issuer, production deployment, credentials or released-runtime claim.