Architecture
OCP can be implemented by one provider or composed across services, but the same trust boundaries and evidence obligations apply.
Actors
- Subject
- The person or entity the portable records describe.
- Authorizer
- The actor with authority to approve access for a defined scope.
- Context provider
- The system that stores or constructs OCP records and packages.
- Client
- The recipient application requesting and consuming a package.
- Processing recipient
- A model provider or other named service that receives data during processing.
Protocol boundary
OCP defines portable data objects, lifecycle semantics, profiles, discovery, HTTP operations, offline packages, and conformance assertions. Authentication, authorization protocols, identity proofing, key custody, policy engines, model behavior, and external actions remain outside the protocol boundary.
Deployment models
| Model | Shape | Key concern |
|---|---|---|
| Provider-native | One service provides storage, authorization integration, and packaging | Do not collapse authorization into package issuance |
| Independent vault | A dedicated continuity provider serves multiple clients | Recipient and processing-recipient bindings |
| Local-first | Records and decisions stay primarily on-device | Portable audit, revocation reach, and secure key handling |
| Federated | Multiple providers contribute scoped records | Conflicts, source authority, status freshness, and partial failure |
Core and profiles
Core objects establish the common envelope, request/grant/package lifecycle, accepted-context rules, and safety properties. Profiles add domain-specific semantics without weakening the core. Version 0.4 publishes Conversation, Artifact, and Provider Adapter profiles.
Was this page useful?
Feedback is stored in this browser only until a project feedback endpoint is adopted.