Skip to main content

PTI and Authorization

Authorization determines what an authenticated actor may do: read a resource, invoke an API, or act on behalf of a subject. PTI extends authorization into the trust domain: which contexts a producer may emit, which contexts a consumer may lookup, and what subject data crosses tenant boundaries.

1. What authorization is​

Authorization systems enforce access control policies after authentication succeeds. Models include:

  • RBAC: role-based permissions (admin, analyst, teller)
  • ABAC: attribute-based rules (department, clearance, jurisdiction)
  • ReBAC: relationship-based access (owner, delegate, guardian)
  • OAuth scopes: coarse-grained API permissions on tokens
  • Policy engines. OPA, XACML, custom rule evaluation

Authorization answers: Given this authenticated actor, is this action on this resource permitted?

2. What problem authorization solves​

ProblemAuthorization response
Over-privileged API accessScope and role restrictions
Cross-tenant data leakageTenant isolation, row-level security
Regulatory purpose limitationPurpose-bound consent and policy tags
Audit accountabilityDecision logs, policy version trails

Authorization protects resources and operations. It does not define how trust signals are structured, scoped to life areas, or exchanged across institutions.

3. What PTI adds​

General authorization

  • API endpoint permissions
  • Resource-level CRUD control
  • Application feature flags

PTI adds

  • Context entitlements, producers emit only entitled context_id values
  • Lookup scopes, consumers request only contracted contexts
  • Trust envelope disclosure, minimum necessary intelligence export
  • Consent gates, cross-context resolution requires subject consent

PTI's Authorization Model is a trust-specific policy layer. Your existing IAM/OAuth scopes govern application access; PTI entitlements govern trust production and consumption.

4. How they compose together​

Integration pattern:

  1. Institution user authenticates and passes application-level authorization (e.g., "loan officer" role).
  2. Application calls PTI Trust Lookup API with consumer credentials scoped to lending and risk_compliance.
  3. PTI evaluates contract entitlements: rejecting lookup requests for contexts not in the institution's profile.
  4. Response returns a trust envelope: structured intelligence without raw partner PII beyond contract.

Institution policy engines may further restrict which staff roles see lookup results. PTI does not replace internal HR authorization.

5. When to use each​

ScenarioApplication authorizationPTI authorization
Teller can view customer accountRequiredN/A
Lender can run trust lookup for lending contextApp role checkRequired (context entitlement)
Partner emits merchant onboarding eventsPartner app authRequired (merchant context entitlement)
Cross-context score fusion without consentShould denyMUST deny per RFC-007
API gateway rate limitingEither layerEither layer

Use application authorization for UX and internal workflow; use PTI authorization for trust data boundaries.

See also​