PE
Protocol Explorer
PIC

PIC — Federation Bridge Entry

How a PIC transaction starts. An external identity (here OAuth/OIDC, but the same pattern applies to SPIFFE, DID/VC, X.509) is translated into PCA_0 — the root Causal Authority that anchors every subsequent hop. The Federation Bridge extracts the immutable origin principal p_0 from the credential (sub claim → p_0) and the initial operation set ops_0 from the credential's authority claims (scope → ops_0), then signs PCA_0 with executor binding to the first executor E_0. From this point on, p_0 is immutable and ops can only monotonically restrict.

Alice (User)OIDC ProviderFederation BridgeExecutor E_01POST /token (auth code)2002ID Token (JWT)3GET /api (with ID token)4POST /pic/bootstrap5PCA_0 (signed)6200 OK (transaction anchore…
POST https://oidc.example.com/token200

Alice authenticates at her organization's OIDC Provider via a standard OAuth 2.0 Authorization Code exchange. This is the external authentication step — PIC does not replace OAuth/OIDC; it consumes the resulting credential to anchor a transaction. Any source that can carry an immutable principal identifier and an authority set works equally (SPIFFE SVID, DID/VC, X.509).

PIC is identity-system-agnostic. The source credential here is OIDC, but pic-spec.md §6.5.5 and §6.5.6 cover SPIFFE, DID/VC, and X.509 as equivalent entry points.

Only two facts must be extractable from the credential: an immutable principal identifier (becomes p_0) and an authority set (becomes ops_0).

The credential is consumed once at the boundary and never propagated further — only the derived PCA_0 flows into the trust plane.

1 / 6
speed

Step 1: POST /token (auth code)

Request / response
POSThttps://oidc.example.com/token
Content-Type?

application/x-www-form-urlencoded

Host

oidc.example.com

Body
grant_type=authorization_code&code=auth_code_xyz&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcb&client_id=app-client