Security
Imagine a commercial greenhouse containing a crop worth EUR 500,000.
Temperature is one of the variables that determines whether that crop survives.
Too cold for too long and growth may be damaged.
Too hot and the crop itself may be at risk.
The greenhouse therefore has deterministic capabilities such as:
read_internal_temperature()
read_external_weather()
adjust_heating()
control_ventilation()
Its desired outcome is simple to express:
The current AI transition is often described as a revolution in software development.
Large language models generate code, tests, documentation and integrations. Natural language is increasingly becoming an interface to software construction, and development is becoming faster and cheaper.
But this is still, fundamentally, the traditional software model:
Requirement
↓
Developer + AI
↓
Code
↓
Application
↓
User
↓
Outcome
AI has accelerated the construction of the application.
PIC here means Provenance Identity Continuity.
Scope note. This article isolates one part of PIC: its temporal / execution-lineage dimension. PIC is broader than
Land includes additional rules and mechanisms around authority, continuity and verification. The goal here is only to make the temporal axis explicit.
A simple way to understand the temporal dimension of PIC is to start with how authority is created.
Economics has studied agency under asymmetric information for more than fifty years. Stephen Ross gave an early formal treatment of the principal-agent problem in 1973. Jensen and Meckling’s 1976 paper defined agency costs and integrated agency theory with property rights and finance to analyze ownership structure. Holmström, Grossman, Hart, Moore, Tirole and many others subsequently developed major parts of contract and organization theory. Work in this broader tradition later received Nobel recognition, including the 2016 prize to Oliver Hart and Bengt Holmström for contributions to contract theory.
PIC Profile 0.2 defines centralized PIC-X-mediated authority continuity.
This walkthrough follows one sensitive-document execution from OAuth authority into PIC Token JWT 0, then through two workload-produced candidate transitions.
OAuth authority
|
v
PCA 0
{ read document-42, save }
|
| Worker 1 reads document-42
| remove read authority
v
PCA 1
{ save }
|
| Worker 2 stores the result
| remove save authority
v
PCA 2
{ no execution invariants }
Cryptographic byte values, compact tokens, signatures, hashes, and COSE byte strings below are illustrative. The structure and field semantics follow Profile 0.2.
PIC Profile 0.2 defines centralized PIC-X-mediated authority continuity.
The active profile is:
https://pic-protocol.org/profiles/0.2
This article defines the external PIC Token JWT envelope and the native COSE artifacts used by that profile.
OAuth access token + Initial Continuity Proposal
|
v
PIC-X
|
v
realm-signed PIC PCA COSE 0
|
v
realm-signed settled PIC Continuity COSE 0
|
v
realm-signed PIC Token JWT 0
Non-initial advancement is candidate-based:
PIC-X exposes discovery at two levels: a server control-plane document and a per-realm PIC-X discovery document.
The server is not an issuer. A realm is an isolated trust domain and issuer boundary. Realm discovery publishes issuer-scoped endpoints, keys, token-exchange metadata, and PIC authority and continuity capabilities.
/.well-known/server-configuration
|
+--> realm: acme
|
v
/realms/acme/.well-known/pic-x-configuration
Discovery Model
The server-level document describes the PIC-X instance. The realm-level document describes the issuer clients use for PIC exchange and verification.
PIC-X receives an OAuth access token at the selected realm token endpoint, validates it, and derives the initial PIC Context of Authority, or PCA. A PCA is the logical Context of Authority. Its signed representation is a PIC PCA COSE. PIC-X then returns a realm-signed PIC Token JWT carrying a settled PIC Continuity COSE in pic.root.
PIC-X stands for Provenance Identity Continuity Exchange.
Verifiable Authority Continuity across execution boundaries.
PIC has reached a point where the questions are becoming practical:
How can we use it? How can we test it? What should a real implementation look like?
Answering those questions requires more than specifications. It requires building the components that enable software engineers and architects to experiment with PIC in real systems.
The question. This article examines one narrowly defined security property: whether authority propagated across time and multiple execution boundaries remains verifiably attributable to the concrete execution and request for which it was granted.
The change of question in authority propagation: from actor selection to execution continuity
One scope condition should be kept in mind throughout this article: the following discussion of who concerns only the propagation of authority after initial authentication and authority origination. It addresses what happens when already-established authority is handed off, exchanged, resumed, attenuated, or otherwise continued across a later execution boundary. It does not claim that identity is unnecessary for authentication, initial authorisation, eligibility, accountability, revocation, or other security properties.