Repository navigation
contract(authz): bind CalendarWeave runtime resource decisions to verified identity and tenant #160
Description
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.pyandauthorization_plane.pycontain 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/*:decideis 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:
- Independently validate the approved CalendarWeave user-token issuer/signature/algorithm/audience/subject/time profile and authenticate a CalendarWeave-scoped service caller separately.
- Resolve
(issuer,subject)through an authoritative current membership mapping, not an unverified caller tenant/org-path header or claim-only entitlement. - Evaluate exact action (
create_collection,create_event,read_events,update_event) and opaque collection/event references against resource binding without reading CalendarWeave application tables. - 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.
- Deny missing/mismatched identity, resource, membership, role/scope, stale policy and dependency failures; preserve scalar opaque subject semantics rather than silently truncating CalendarWeave inputs.
- Do not distribute operator credentials to consumers, infer runtime authorization from menu/software allows, or copy Keyverse's identity/policy store into CalendarWeave.
- 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.
Activity
seonghobae commentedon Oct 3, 2026
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
7d9151cd2da260e118020c938c7358e2ee75d541and PR1035ac33256229321e9fccbb14a460c7d6de984444aunchanged. 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 commentedon Oct 4, 2026
#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
5ac33256229321e9fccbb14a460c7d6de984444aconfirms:app/org_authorization.pyAssignmentSnapshot and validation carry callersubject/tenant/org path; validation is structural, not independently verified
current membership.
action/resource, coherent revision and freshness.
app/authorization_plane.pydecision 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.
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_collectionstays 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.