root@ngallo.it ~ $

Designing PIC-X: From Specification to Architecture to Code

PIC has reached the point where people are asking how they can use and test it. This article introduces PIC-X, the first open-source implementation component in a broader PIC software ecosystem, and begins Designing PIC-X: a practical series following the project from specification to architecture and code.

tags
#Pic #Pic-X #Security #Authorization #Ai #Software Engineering #Design
published
reading time
3 minutes
Designing PIC-X: From Specification to Architecture to Code.
Designing PIC-X. From Specification to Architecture to Code.

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.

From PIC to PIC-X

I am therefore starting PIC-X, the first open-source implementation component in what can become a broader PIC software ecosystem.

PIC-X will initially implement the exchange and Trust Plane capabilities needed to connect existing authority infrastructure with PIC. It is one component, not the complete PIC implementation landscape: other libraries, SDKs, enforcement components, integrations, and operational tools may follow as the ecosystem develops.

The first goal is to integrate PIC with existing OAuth infrastructure: exchange an OAuth token, evaluate the authority it represents, and create the PIC Context of Authority required to begin or continue a PIC execution.

OAuth token  →  PIC-X Trust Plane  →  PIC Context of Authority

OAuth will be the first integration target, not the limit of the project. The architecture should later support other authority sources and exchange profiles without making PIC dependent on OAuth.

PIC-X will provide the first concrete way to run, inspect, and test this part of PIC. It will be released as open source so that others can experiment with it, review the implementation, contribute, or use it as a foundation for their own work.

Designing PIC-X

This article also begins Designing PIC-X, a practical series dedicated specifically to the design and implementation of PIC-X.

The series is intended for software engineers and architects. It will develop in parallel with PIC-X, following the work from specification to architecture and code. Each article will use the Designing PIC-X: prefix and focus on a concrete design decision, architectural boundary, internal component, API, data flow, or implementation trade-off.

Many PIC concepts and requirements will necessarily appear throughout the series, but always through the practical question of how PIC-X should implement them. This is not the general implementation series for every future PIC component.

The articles will also form practical technical documentation for people who want to understand, run, integrate, or contribute to PIC-X.

Some early decisions will change. Implementation may reveal new constraints, security analysis may expose a better boundary, or a simpler design may replace the first approach. When that happens, later articles will preserve the earlier reasoning and explain what changed and why.

The latest implementation will show how PIC-X currently works. The complete series will show how its architecture arrived there. Other PIC components may receive their own dedicated series as they are designed and built.

References

The next article will examine the first PIC-X flow: exchanging an OAuth access token for $\mathsf{PCA}_0$, the origin PIC Context of Authority, and the design decisions required to make that conversion explicit and verifiable.