PTI and Authentication
Authentication verifies that a presented credential belongs to the claimed subject in this session. PTI does not replace login flows, MFA, or token issuance, it consumes authenticated sessions as the trust boundary for signal ingestion and lookup authorization.
1. What authentication is
Authentication is the process of validating credentials: passwords, passkeys, OTPs, hardware tokens, client certificates, or federated assertions (SAML, OIDC), to establish a session or token with a defined lifetime and assurance level.
Common patterns:
- OIDC / OAuth 2.0: delegated authentication with ID and access tokens
- FIDO2 / WebAuthn: phishing-resistant possession factors
- mTLS: machine-to-machine authentication for API clients
- API keys and HMAC signatures: service authentication for batch ingest
Authentication answers: Is this request genuinely from this actor right now?
2. What problem authentication solves
| Problem | Authentication response |
|---|---|
| Impersonation | Credential verification, MFA step-up |
| Session hijacking | Short-lived tokens, binding, rotation |
| Service spoofing | mTLS, signed webhooks, API key scopes |
| Federated login | Trust transfer via IdP assertion |
Authentication protects channels and sessions. It does not aggregate repayment history, rental reliability, or employment verification into portable trust intelligence.
3. What PTI adds
Authentication
- Session and token validity
- Actor identity at request time
- Assurance level (AAL, eIDAS LoA)
PTI adds
- Post-auth trust events, verified activity becomes durable evidence
- Producer authentication profile, entitled ingest per trust context
- Consumer authentication profile, scoped trust lookup permissions
- Provenance binding, events attributed to authenticated producer tenant
PTI's Authentication Model defines how trust producers and consumers authenticate to PTI APIs, distinct from end-user login. End-user authentication remains in the partner or institution application; PTI trusts the producer's authenticated assertion that an event occurred.
4. How they compose together
Typical flow:
- End user authenticates to partner application (existing OIDC/MFA stack).
- Partner system authenticates to PTI (mTLS, OAuth client credentials, or signed webhook).
- Partner emits trust events on behalf of the authenticated subject, tagged with
context_id. - Institution authenticates to PTI as a trust consumer and requests lookup for a permitted context.
Authentication establishes who may emit or read; PTI establishes what trust evidence exists once emission is authorized.
5. When to use each
| Scenario | Authentication | PTI |
|---|---|---|
| User login to mobile app | Required | Not involved |
| Partner webhook ingest of repayment event | Service auth Required | Required for trust fabric |
| Institution API trust lookup | Consumer auth Required | Required |
| Password reset flow | Required | Not involved |
| Cross-MFI portable repayment proof | Auth per app | Required |
Never substitute PTI API authentication for end-user login, or vice versa. They operate at different trust boundaries.