Provider-Neutral Authority, Provenance, Rights and Portable State
This working draft extracts interoperability semantics from ENTITY v3.4.2 for technical discussion. It is not yet an IETF Internet-Draft and carries no IETF, W3C, DIF or other standards-body endorsement.
Abstract
Modern systems commonly verify identity, signatures, credentials and provenance while leaving several questions implicit: who had authority to perform the governed action; what rights existed at that time; whether evidence is being mistaken for truth or authority; whether downstream state survives provider migration; and whether economic consequences are explicitly authorized rather than inferred from correlation. ENTITY separates these concerns into five protocol primitives—ENTITY, AUTHORITY, RIGHT, EVENT and VALUE—and defines signed, portable state around them.
1. Problem statement
A valid signature proves that a signer signed bytes. A valid credential can prove that an issuer made a claim. A provenance edge can prove that one recorded artifact references another. None of those facts alone establish that the actor possessed sovereign authority over the subject matter, that a legal or economic right existed, or that an external-world claim is objectively true.
The interoperability problem is therefore broader than authentication. A portable system needs explicit representations for identity, delegated authority, rights, evidence-bearing events, revocation/recovery and—where a deployment elects to model it—economic consequence.
2. Core primitives
| Primitive | Interoperability question |
|---|---|
| ENTITY | What persistent subject or actor is being referenced across providers and recoveries? |
| AUTHORITY | Who is permitted to perform, delegate, attest to or revoke a governed action? |
| RIGHT | What permission, entitlement, ownership/usage condition or governed right applies? |
| EVENT | What signed transition occurred, under what authority, with what evidence and prior state? |
| VALUE | What explicit economic consequence, if any, follows from authorized rules and evidence? |
3. Authority is not credential validity
An external credential, identity provider assertion or signed evidence object MAY be accepted as evidence according to a deployment profile. It MUST NOT silently acquire broader ENTITY authority merely because its cryptographic verification succeeds. Authority escalation requires an explicit mapping or delegation whose scope is itself verifiable.
4. Provenance is not ownership or truth
Provenance records relationships among artifacts, actors and events. A provenance edge does not automatically create ownership, a licence, an economic entitlement or objective truth. Those claims require their own authority, rights and evidence semantics.
5. Rights and governed actions
Rights decisions are evaluated separately from identity and provenance. Deployments SHOULD fail closed when no applicable authorization exists. A stronger right can imply explicitly defined prerequisites only where the governing ontology says so; rights MUST NOT be inferred merely from possession of data or knowledge of an identifier.
6. Events and evidence
Events bind actors, subjects, prior state, authority, evidence and resulting state. Multiple evidence objects MAY enrich one occurrence, but evidence multiplicity MUST NOT by itself manufacture additional causal events, rights or obligations. This boundary is currently under active public counterexample review in ENTITY issue #28.
7. Portability and recovery
A provider-neutral implementation SHOULD support export and recovery without replacing the sovereign identity root. Recovery evidence must distinguish restoration of the same identity from creation of a new identity that merely resembles the old state.
8. Canonicalization and conformance
Interoperable implementations require deterministic serialization and verification rules. ENTITY publishes sealed conformance vectors and controlled multi-language reproducibility evidence. BTG-controlled implementations demonstrate reproducibility but are explicitly distinguished from unrelated independent implementation and interoperability evidence.
9. External standards
External standards may serve as authentication, credential, identifier, evidence or transport surfaces. A mapping to an external standard does not imply that the standard grants ENTITY sovereign authority, nor does conceptual overlap imply conformance. Implementations should preserve those claim boundaries explicitly.
10. Security considerations
- Authority-scope escape through externally valid credentials.
- Replay or substitution of evidence to duplicate an event or obligation.
- Stale delegated authority after revocation or rotation.
- Provider capture that prevents portable recovery.
- Confusion between signer timestamps and independently anchored time.
- Provenance relationships being treated as ownership or economic causality.
11. Privacy considerations
Persistent identity and provenance can create correlation risk. Deployments should minimize unnecessary disclosure, avoid embedding sensitive material where hashes/references suffice, and separate public verification data from protected operational state.
12. IANA considerations
This pre-submission working draft requests no IANA actions.
13. Open questions for standards reviewers
- Which existing IETF/W3C work already covers portions of these semantics well enough to reuse rather than duplicate?
- Should the portable authority model be specified independently from credential formats?
- What minimum canonicalization and test-vector surface is required for unrelated implementations to converge?
- How should evidence enrichment be modeled without changing occurrence identity?
- Which recovery semantics can be made provider-neutral without constraining legitimate local key-custody choices?
Implementation evidence
The discussion target is the immutable ENTITY v3.4.2 release. Public source, conformance material, external challenges and qualification boundaries are linked from the documentation portal.