Provider-Neutral Authority, Provenance, Rights and Portable State

Problem Statement A valid signature proves attribution to a signing key. A valid credential can prove that an issuer made a claim. A provenance relationship can prove that one recorded artifact references another. None of these facts alone establishes sovereign authority over the subject matter, a legal or economic right, or objective truth. Interoperable systems therefore need explicit boundaries among identity, authority, rights, evidence-bearing events and any economic consequence.

Core Primitives

ENTITY:: Persistent subject or actor identity across providers, applications and recovery events.
AUTHORITY:: Permission to perform, delegate, attest to or revoke a governed action.
RIGHT:: Governed permission, entitlement, ownership condition or usage condition.
EVENT:: Signed state transition with actor, subject, prior state, authority and evidence.
VALUE:: Explicit economic consequence where a deployment elects to model one.

Authority and External Credentials An externally valid credential or identity-provider assertion MAY be accepted as evidence according to a deployment profile. Successful cryptographic verification MUST NOT silently expand that evidence into broader protocol authority. Any authority mapping or delegation requires an explicit, independently verifiable scope.

Provenance, Ownership and Truth Provenance describes recorded relationships among artifacts, actors and events. Provenance alone MUST NOT be interpreted as ownership, a licence, an economic entitlement or objective truth. Those claims require their own authority, rights and evidence semantics.

Rights and Governed Actions Rights evaluation is separate from identity and provenance. Implementations SHOULD fail closed when no applicable authorization exists. Rights MUST NOT be inferred solely from possession of data, knowledge of an identifier or the presence of a provenance edge.

Events and Evidence Events bind actors, subjects, prior state, authority, evidence and resulting state. Multiple evidence objects MAY enrich one occurrence. Evidence multiplicity MUST NOT by itself manufacture additional causal events, rights or obligations.

Portability and Recovery A provider-neutral implementation SHOULD support export and recovery without replacing the persistent identity root. Recovery evidence MUST distinguish restoration of the same identity from creation of a new identity with similar state.

Canonicalization and Conformance Independent implementations require deterministic serialization and verification rules plus public test vectors. Controlled multi-language reproductions can demonstrate implementation reproducibility but MUST be distinguished from unrelated independent interoperability evidence.

Relationship to Existing Standards External standards can provide authentication, credential, identifier, evidence or transport surfaces. Conceptual mapping does not itself establish conformance, and an external standard does not automatically confer protocol authority.

Security Considerations

Authority-scope escape through externally valid credentials.
Evidence replay or substitution that duplicates one event or obligation.
Stale delegated authority after revocation or key rotation.
Provider capture that prevents portable recovery.
Confusion between signer-provided time and independently anchored time.
Provenance being mistaken for ownership or economic causality.

Privacy Considerations Persistent identity and provenance can create correlation risk. Implementations SHOULD minimize unnecessary disclosure and separate public verification material from protected operational state.

Implementation and Discussion Status The source discussion target is ENTITY v3.4.2, released by Blackmore Technology Group Limited. This working source has not been submitted to or endorsed by the IETF or any other standards body.