---
robots: noindex, nofollow
---
# XID: Extensible Identities
Blockchain Commons
Wolf McNally, Lead Researcher
October 14, 2024
## Document Has Moved
The contents of this document are no longer current.
The latest version of this document is [BCR-2024-010](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-010-xid.md)
## Terminology Clarification Note
XID documents described herein are encoded using [Gordian Envelope](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-003-envelope.md), which is a recursive data structure having the form:
```
<subject> [
<predicate>: <object>
<predicate>: <object>
...
]
```
The term *subject* as used in Gordian Envelope documentation and literature derives from the domain of knowledge representation such as the [Semantic Web](https://en.wikipedia.org/wiki/Semantic_Web) and [Resource Description Framework (RDF)](https://en.wikipedia.org/wiki/Resource_Description_Framework) where *subject-predicate-object triples* are the basic unit of relational knowledge. As such, the "subject" of an envelope can be any entity, real or abstract, and the predicate-object pairs are called *assertions*.
This particular use of the term *subject* is not to be confused with the same word used in the [Verifiable Credential (VC)](https://en.wikipedia.org/wiki/Verifiable_credentials) domain to mean, "the entity about whom claims are being made," which is typically a real-world entity such as a person or organization. Furthermore, envelope assertions are not to be confused with Verifiable Credential *claims*.
Since Envelopes consist of recursively-nested envelopes, most "subjects" in a typical envelope will *not* be "subjects" as construed in Verifiable Credentials.
```
<subject> [
<predicate>: <object>
<predicate>: <subject> [
<predicate>: <object>
<predicate>: <object>
...
]
...
]
```
Nonetheless, a XID as the top-level subject of a XID document envelope may very well be such an identifier of a real-world entity, and hence be a subject in both senses. In specific circumstances, it is also possible for envelope assertions to represent verifiable claims.
## Introducing XID
A *XID* (“eXtensible IDentity”, IPA pronunciation */zɪd/*) is a unique 32-byte identifier for a *subject* entity. A subject may be a person, an organization, a device, or any other entity, real or abstract:
```
XID(71274df133169a0e2d2ffb11cbc7917732acafa31989f685cca6cb69d473b93c)
```
This document provisionally uses [CBOR](https://cbor.io/) tag #6.40024 to represent "XID". This tag has not yet been assigned in the [IANA registry of CBOR tags](https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml).
So the XID above, in CBOR diagnostic notation, is:
```
40024(h'71274df133169a0e2d2ffb11cbc7917732acafa31989f685cca6cb69d473b93c')
```
And when converted to binary is:
```
D9 9C58 # tag(40024)
58 20 # bytes(32)
71274DF133169A0E2D2FFB11CBC7917732ACAFA31989F685CCA6CB69D473B93C
```
We will frequently identify XIDs by the first four bytes, sufficient for quick recognition by humans:
```
XID(71274df1)
```
These first four bytes can be translated to a sequence of [Bytewords](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-012-bytewords.md) prefixed by U+1F167 (NEGATIVE CIRCLED LATIN CAPITAL LETTER X) for quick and memorable identification of a XID in any context:
```
71274df1
```
⇒
```
🅧 JUGS DELI GIFT WHEN
```
For additional recognizability and security, a [LifeHash](https://lifehash.info/) may also be used, which is created using the full tagged CBOR encoding of the XID:
`🅧 JUGS DELI GIFT WHEN`
To encode a XID as a URI, we encode it as a [Uniform Resource (UR)](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md) using the UR type `xid` to take the place of the tag:
```
ur:xid:dpmomtticpbsesrnhnfhoxkplatbcthglekorscmmowdvakilgwscnemnlhtlgdplncejegd
```
> ❇️ ***Note**: None of these alternate encodings change the characteristic bytes (and hence Bytewords) used to quickly identify the XID itself. Comparison of XIDs by machines always uses all 32 bytes.*
## XIDs With Resolution Methods
To gain access to the information to which a XID refers, it must undergo *resolution*. A XID alone does not specify a resolution method. It would be desirable for a future XID standard to define as part of its ecosystem a decentralized universal XID resolver that would be useful for many purposes. However, some applications of XIDs will require that one or more alternate or required resolution methods be specified along with the basic XID.
To accomplish this, we create a minimal *XID Document* (see below) which only includes one or more resolution methods. This is a [Gordian Envelope](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-003-envelope.md) with the XID as its subject and one or more `dereferenceVia` assertions describing recommended resolution methods:
```
XID(2d9296d0) [
'dereferenceVia': "https://resolver.example.com"
'dereferenceVia': "btcr:01234567"
]
```
We then wrap the CBOR encoding of this envelope in the XID tag, so it simply appears in URI form as a longer XID:
```
202(200(<envelope contents>))
```
=>
```
ur:xid:<encoded XID>
```
Therefore, when parsing a `ur:xid`, if the encapsulated CBOR is a byte string, then it is a bare XID. If it begins with tag #6.200, then it is a Gordian Envelope, and hence a XID document.
## XID Genesis Key
A XID is generated from the SHA-256 hash of the CBOR representation of a specific `PublicSigningKey` structure called the *genesis key*.
Since the CBOR representation of a `PublicSigningKey` is self-describing, including the type of algorithm (Ed25519, BIP-340 Schnorr, etc.) the hash is unique to both the key material and the algorithm used.
```
SHA256(PublicSigningKey(Ed25519))
```
⇒
```
2d9296d0220f39be603fa47580d61f578a76bf1692eae67d8def2337995a8d2d
```
⇒
```
XID(2d9296d0)
```
The private half of the genesis key is held by the document's *genesis controller*.
The fact that at inception a XID is tied to the cryptographic material of a specific key provides simplicity of lookup and initial authentication, also ensuring that a XID is never generated from arbitrarily chosen numbers, but rather from a unique private key verified to be possessed by the genesis controller.
However, a XID's *verification* keys (which initially include the genesis key) can be rotated, including removing (revoking) the genesis key, without needing to change the XID itself. This provides for using the XID as a stable identifier throughout its lifetime.
One implication of uniquely tying a XID to a key pair at inception is that a new key pair must be generated and managed for each new XID created. The primary challenge with this is key management when multiple XIDs are managed, while the primary benefit is key isolation in the event of compromise.
## XID Document
A *XID document* is the result of resolving a XID, and provides the foundational information needed to:
* authenticate the subject entity,
* communicate with it,
* delegate one or more *controllers* of the entity's functions.
* declare *endpoints* controllers may use to carry out actions on the subject's behalf.
The format of a XID document makes it easy to:
* delegate all authority to the subject (in which case it is a *self-sovereign* XID)
* share some authority, or
* completely transfer some or all authority.
Whether function access is granted or denied must be enforced by the verifiers of the rules in the XID document, including XID resolution mechanisms.
A XID document is encoded as a [Gordian Envelope](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-003-envelope.md), with the XID itself as the envelope subject, and containing a number of assertions about the XID.
## Key Declarations
A primary role of a XID document is to declare public keys and their associated attributes, including their controllers, specific operations they are permitted to perform (their *permissions*), and (optionally) the *endpoints* through which they may perform these functions. Public keys are declared in a XID document using the key assertion:
```
XID(2d9296d0) [
'key': SigningPublicKey
]
```
Keys declared at the top level of a XID document are implicitly controlled by the genesis controller (the key that generated the XID). Therefore the `controller` assertion here is redundant:
```
XID(2d9296d0) [
'key': SigningPublicKey // Genesis key
'key': AgreementPublicKey
'controller': XID(2d9296d0) // Redundant, may be removed
]
```
If the XID document has removed (revoked) the genesis key, then the controller of top-level keys must be declared:
```
XID(2d9296d0) [
'key': SigningPublicKey // Not the genesis key
'key': AgreementPublicKey
'controller': XID(5802b4ff) // Required
]
```
The Genesis key may not be assigned to a different controller within the document:
```
XID(2d9296d0) [
'key': SigningPublicKey // Genesis key
'key': AgreementPublicKey
'controller': XID(5802b4ff) // Invalid
]
```
Any other key may be assigned to any controller:
```
XID(2d9296d0) [
'key': SigningPublicKey // Genesis key
'key': AgreementPublicKey [
'controller': XID(5802b4ff) // Valid
]
]
```
## Key Attribute Assignment And Top-Level Group
To facilitate both simplicity and generality, attributes such as permissions, controllers, and endpoints may be assigned by declaring them as assertions directly on keys, or as sibling assertions:
```
XID(2d9296d0) [
'key': SigningPublicKey [ // This key receives 'a' and 'b'
'a': <value>
]
'key': SigningPublicKey // This key receives only 'b'
'b': <value>
]
```
This is equivalent to placing both keys within a *group* (discussed further below). Indeed, the top level of a XID document is an implicit group.
```
XID(2d9296d0) [
'key': 'group' [
'key': SigningPublicKey [ // This key receives 'a' and 'b'
'a': <value>
]
'key': SigningPublicKey // This key receives only 'b'
'b': <value>
]
'key': SigningPublicKey // This key receives neither 'a' nor 'b'
// Any attribute declared here would be received by all three keys.
]
```
## XID Document Verifiers
A XID document should declare one or more *verification keys*, which are keys granted the `verify` permission. Verifiers are allowed to sign updated versions of the XID document.
```
XID(2d9296d0) [
'key': SigningPublicKey
'allow': 'verify'
]
```
For publication, a XID document envelope must first be wrapped and then signed with one of the declared keys with the `verify` permission. If more than one key has the `verify` permission, either key may be used:
```
{
XID(2d9296d0) [
'key': SigningPublicKey
'key': SigningPublicKey [
'controller': XID(5802b4ff)
]
'allow': 'verify'
]
} [
'verifiedBy': Signature // made by either key above
]
```
In addition, resolvers MUST validate that the new version of the XID document contains only changes that are valid under the permissions of the previous version of the document, if any.
*For brevity, we henceforth omit XID document signatures unless it is relevant to a particular topic.*
## Resolution Methods
As mentioned above, XIDs may include non-default resolution methods. A XID document may also include special-purpose resolution mechanisms for a given XID in exactly the same way:
```
XID(2d9296d0) [
'dereferenceVia': "https://resolver.example.com"
'dereferenceVia': "btcr:01234567"
'key': SigningPublicKey
'allow': 'verify'
]
```
As with the main document, XIDs declared deeper in the document may also declare non-default resolution mechanisms:
```
XID(2d9296d0) [
'key': SigningPublicKey
'key': SigningPublicKey [
'controller': XID(4b622c30) [
'dereferenceVia': "https://resolver.example.com"
]
]
'allow': 'verify'
]
```
## Key Controllers
If the controller of a declared key is not the genesis controller, its XID must also be declared in a `controller` assertion on the key, or as a sibling assertion within the same group.
In this example, the only entity allowed to update the XID document is the genesis controller:
```
XID(2d9296d0) [
'key': SigningPublicKey
'allow': 'verify'
]
```
If the genesis controller updates the document to include another key with a different controller `XID(4b622c30)`, then a future revision of the document may be signed by either key:
```
XID(2d9296d0) [
'key': SigningPublicKey
'key': SigningPublicKey [
'controller': XID(4b622c30)
]
'allow': 'verify'
]
```
> ❇️ ***Note**: The key controlled by `XID(4b622c30)` may or may not be that XID's genesis key, but by resolving that XID it can be verified that the XID is a current, valid owner of the key (i.e., it has not been revoked in the controller's XID document) and has the `'sign'` permission, allowing it to sign documents on its subject's behalf.*
Like permissions, controller declarations also apply to all keys declared alongside them. In this example, both keys are controlled by `XID(4b622c30)`, and the `verify` permission applies to them as well, while the genesis controller has no permissions at all:
```
XID(2d9296d0) [
'key': SigningPublicKey
'key': AgreementPublicKey
'controller': XID(4b622c30) [
'dereferenceVia': "https://resolver.example.com"
]
'allow': 'verify'
]
```
## Key Endpoints
The use of keys in accordance with their functions and permissions also requires a method for exercising those keys. This method can be left implicit, or keys in a XID document may be explicitly associated with one or more *endpoints*, which are URIs that enable the controller of the key to perform its designated function(s):
```
XID(2d9296d0) [
'key': SigningPublicKey
'key': AgreementPublicKey [
'endpoint': "https://messaging.example.com"
'allow': 'encrypt'
]
'controller': XID(4b622c30) [
'dereferenceVia': "https://resolver.example.com"
]
'allow': 'verify'
]
```
As shown, the genesis controller's `AgreementPublicKey` is advertising that messages may be encrypted to it and received from the encrypted messaging service at `messaging.example.com`. The controller, having access to the `AgreementPrivateKey` can decrypt and read the messages.
Like controllers and permissions, `endpoint` assertions may be declared directly on keys or as sibling assertions. The actual use of an endpoint is restricted by the requirement that the key must be authenticated by the endpoint and granted the proper permission to perform the designated function.
## Recursive XID Documents
Gordian Envelope's recursive nature makes it possible to carry out XID resolution to any arbitrary depth, where any mention of a XID can in theory be expanded to some version or profile of a given XID's complete document:
```
XID(2d9296d0) [
'key': SigningPublicKey
'key': SigningPublicKey [
'controller': XID(4b622c30) [
<any or all assertions in this XID's document to any depth>
]
]
'allow': 'verify'
]
```
Or a mentioned XID can be extracted, resolved, and act as a stand-alone XID document:
```
XID(4b622c30) [
<any or all assertions in this XID's document to any depth>
]
```
## Multisigned XID Documents
If policy requires multiple parties to sign an updated XID document:
* Multiple `verifiedBy: Signature` assertions along with a `verificationThreshold` rule assertion may be used:
```
{
XID(2d9296d0) [
'key': SigningPublicKey
'key': SigningPublicKey [
'controller': XID(4b622c30)
]
'key': SigningPublicKey [
'controller': XID(3e59d4e0)
]
'allow': 'verify'
'verificationThreshold': 2 // 2 of 3 signatures required
]
} [
'verifiedBy': Signature // Signed by any two of the above
'verifiedBy': Signature // verifiers
]
```
* Or, a multiparty threshold signature scheme like FROST could be used where a single XID may be controlled by a quorum of group members, who cooperatively produce a single valid signature:
```
{
XID(9699ea9b) [
'key': SigningPublicKey // Corresponding FROST private key
'allow': 'verify' // never known by individual group members.
]
} [
'verifiedBy': Signature // Multiparty signature indistinguishable
] // from a single-party signature.
```
## Local References
XID documents frequently contain repeated subtrees of information, so it is desirable that a mechanism be available to deduplicate such repetition within a document, especially for transmission and storage. A mechanism for doing this is *local references*.
Within a XID document, any object (such as a URL, key, etc. and even the top-level XID) may carry a `'target': N` assertion, where `N` is an integer. The subject of the assertion becomes a *local referent*.
In this example, `'target': 0` declares the top-level envelope subject `XID(2d9296d0)` to have the identifier `0`, and the URL `https://resolver.example.com` to have the identifier `1`:
```
XID(2d9296d0) [
'target': 0
'dereferenceVia': "https://resolver.example.com" [
'target': 1
]
]
```
Elsewhere in the document, parts of the envelope may be referenced using the same identifying integer wrapped with the `ref` CBOR tag (not yet assigned). In this example, the URL `https://resolver.example.com` is assigned the identifier `1`, which is later referenced as `ref(1)`, semantically substituting in the referenced URL.
```
XID(2d9296d0) [
'target': 0
'dereferenceVia': "https://resolver.example.com" [
'target': 1
]
'dereferenceVia': "btcr:01234567"
'key': SigningPublicKey
'key': SigningPublicKey [
'controller': XID(4b622c30) [
'dereferenceVia': ref(1)
]
]
'allow': 'verify'
]
```
> ❇️ ***Note**: Unlike `controller`, `endpoint`, and `allow`, which apply to keys and may be received by sibling or grouped keys, `dereferenceVia` is asserted directly on and applies only to a specific XID.*
The integer `N` must be monotonically increasing with no gaps. So if a XID document contains three local referents, the integers used must be `0`, `1`, and `2`.
The identifier `0` is special: in an envelope using local references, the specific assertion `'target': 0` must always be present, and identifes the *local namespace root*. This facilitates combining envelopes with local references. For example, if we derefernced `XID(4b622c30)`, we would have another XID document, perhaps with its own set of local references. But because `0` always defines the top of a new namespace, there is no conflict:
```
XID(2d9296d0) [
'target': 0
'dereferenceVia': "https://resolver.example.com" [
'target': 1
]
'dereferenceVia': "btcr:01234567"
'key': SigningPublicKey
'key': SigningPublicKey [
'controller': XID(4b622c30) [
'target': 0 // not the same as 0 above
'key': SigningPublicKey [
'target': 1 // not the same as 1 above
]
]
]
'allow': 'verify'
]
```
Composers of XID documents should consider performing a normalization pass over a document before it is wrapped and signed, replacing duplicates with local references. When the document is read back in, after the document's signature has been validated and the inner envelope unwrapped, a denormalization pass may be performed to resolve local references for quick access.
> ❇️ ***Note**: Since the described system of local references has utility across applications beyond XID documents, the authors propose this system as a general extension to Gordian Envelope.*
## Functions
*Functions* are various actions that may be executed on behalf of the XID subject. The exercise of functions often occurs through one or more *endpoints*, which serve as APIs enabling the associated operations.
> ❇️ ***Note**: The list of functions here is provisional and non-exhaustive.
### Operational Functions
Operational functions relate to interacting with services in the day-to-day usage of the XID, where authentication, signing, and accessing resources are the main activities.
* `auth`: Authenticate as the subject (e.g., log into services)
* `sign`: Sign digital communications as the subject
* `encrypt`: Encrypt messages from the subject
* `elide`: Elide data under the subject's control
* `issue`: Issue or revoke verifiable credentials on the subject's authority
* `access`: Access resources allocated to the subject
### Management Functions
Management functions affect a XID’s lifecycle and governance. These actions typically require a higher level of trust and authority.
* `delegate`: Delegate function access to third parties
* `verify`: Verify (update) the XID document
* `update`: Update service endpoints
* `transfer`: Remove the genesis key
* `elect`: Add or remove other verifiers (rotate keys)
* `burn`: Transition to a new provenance mark chain (see below)
* `revoke`: Revoke the XID entirely
To accept a revised XID document for publication, the resolver network must validate that changes being made are signed by a verifier that has permission to make those changes in the previous version of the XID document.
> ❇️ ***Note**: Future work could involve defining a system for refining the granularity of permissions by adding assertions to given functions.*
## Permissions
A function may exist, but to use it an entity must be granted *permission* to do so.
XID documents have a *deny-first* permission structure, so any and all permissions are denied unless specifically granted with an `allow` assertion, and a `deny` assertion overrides any conflicting `allow`. The universal permission `all` may be granted, and then additional `deny` rules can be added to remove specific permissions.
A permission may be associated with one or more keys, which are used in the exercise of a permitted function. Keys are in turn associated with controller entities, which possess the private part of the keys. A XID document vends the public part of the key pairs along with their permissions.
* Permissions for functions requiring signing vend a `SigningPublicKey`, and require that the controller hold the corresponding `SigningPrivateKey`.
* Permissions for functions requiring encryption and decryption vend an `AgreementPublicKey`, and require that the controller hold the corresponding `AgreementPrivateKey`.
Granting permissions to keys that do not have the corresponding function are ignored. For example, granting the `encrypt` permission to a `SigningPublicKey` has no effect: the key is still not considered to have the ability to encrypt because a key of that type does not have the encryption function. This "ignore rule" facilitates the use of the `all` operator, discussed below.
A minimal, completely self-sovereign XID document that grants all permissions to its genesis controller might look like this:
```
XID(2d9296d0) [
'key': SigningPublicKey
'key': AgreementPublicKey
'allow': 'all'
]
```
Notice that the `'allow': 'all'` assertion grants all permissions *applicable* to each of the two keys.
## Group Permissions
In this example, the XID document declares that all management functions are exclusively held by the genesis controller, but operational functions are shared between the genesis controller and another controller:
```
XID(2d9296d0) [
'key': 'group' [
'key': SigningPublicKey
'key': AgreementPublicKey
'allow': 'all'
]
'key': 'group' [
'key': SigningPublicKey
'key': AgreementPublicKey
'controller': XID(4b622c30)
'allow': 'auth'
'allow': 'sign'
'allow': 'elide'
'allow': 'issue'
'allow': 'access'
'allow': 'encrypt'
'allow': 'decrypt'
]
]
```
In this example the genesis controller retains all authority, and grants a group of three keys access various operational functions, but also specifically denies one of those keys access to two functions:
```
XID(2d9296d0) [
'key': 'group' [
'key': SigningPublicKey
'key': AgreementPublicKey
'allow': 'all'
]
'key': 'group' [
'key': 'group' [
'key': SigningPublicKey
'key': AgreementPublicKey
'controller': XID(4b622c30)
]
'key': 'group' [
'key': SigningPublicKey
'key': AgreementPublicKey
'controller': XID(7561aba4)
]
'key': 'group' [
'key': SigningPublicKey
'key': AgreementPublicKey
'controller': XID(83a7f361)
'deny': 'auth'
'deny': 'access'
]
'allow': 'auth'
'allow': 'sign'
'allow': 'encrypt'
'allow': 'elide'
'allow': 'issue'
'allow': 'access'
]
]
```
## Combining Keys with PublicKeyBase
In all the examples above, we have so far separated the structure and function of `SigningPublicKey` and `AgreementPublicKey`. But as the last example implies, we often wish to communicate with entities securely where communication is both encrypted and signed. The Blockchain Commons stack includes the `PublicKeyBase` structure, which is a package consisting of both a `SigningPublicKey` and an `AgreementPublicKey`, each of which may use different algorithms. A `PublicKeyBase` is nonetheless completely self-describing, so it can be used anywhere either signing or encryption (or both) may be needed. This simplifies our previous example to:
```
XID(2d9296d0) [
'key': PublicKeyBase [
'allow': 'all'
]
'key': 'group' [
'key': PublicKeyBase [
'controller': XID(4b622c30)
]
'key': PublicKeyBase [
'controller': XID(7561aba4)
]
'key': PublicKeyBase [
'controller': XID(83a7f361)
'deny': 'auth'
'deny': 'access'
]
'allow': 'auth'
'allow': 'sign'
'allow': 'encrypt'
'allow': 'elide'
'allow': 'issue'
'allow': 'access'
]
]
```
## Revisions with Provenance Marks
Although a XID remains stable throughout its lifecycle, the key(s) it vends, the permissions it grants, and the endpoints it uses may change considerably over time. Valid XIDs MUST be created from a genesis key, which gives a XID its identity, including verifying that the XID is not formed from arbitrarily chosen numbers.
As long as the genesis key remains in the XID document as a verifier, then revisions to the document signed by the same key can be considered authentic.
But control of a XID may be entirely transferred at some point, including entirely removing the genesis key. This may be due to possible key compromise, or because policy may simply dictate periodic key rotation.
In addition, there are challenges around the sequencing of published revisions to XID documents in a decentralized, distributed, and concurrent environment. Between two revisions, which is more current? Timestamps can be spoofed.
So, since a XID document may routinely become detached from the cryptographic material used to incept it, how do we authenticate a given version of a XID document we may receive from some source?
Part of that authentication depends on resolving the XIDs of the document's current controller(s), and deciding whether to trust those entities.
However, an additional and complementary path to authentication becomes available if we provide a mechanism for establishing the *provenance* of a XID document; that is, whether we can establish a XID document as a verifiable part of a chain of revisions going back to its inception.
Therefore, XID documents support the inclusion of a [provenance mark](https://github.com/wolfmcnally/Provenance/blob/master/WHITEPAPER.md). This means our minimal, fully self-sovereign XID document signed and ready for publication now looks like this:
```
{
XID(2d9296d0) [
'key': PublicKeyBase
'allow': 'all'
'provenance': ProvenanceMark
]
} [
'verifiedBy': Signature
]
```
A provenance mark is a small binary structure that, like a block of transactions on the Bitcoin blockchain, links a given revision of a XID document to all previous revisions and makes the history of a XID increasingly hard to alter.
However, provenance marks have several additional functions that multiply a XID's security and verifiability. The provenance mark:
* confirms the cryptographic commitment from the previous revision
* "seals" the history of previous revision(s),
* proves that the revision belongs to a *specific* chain,
* contains a monotonically increasing integer revision number,
* contains a timestamp which must never decrease,
* provides a cryptographic pre-commitment to the *next* revision.
When first published with a provenance mark (recommended, perhaps mandatory depending on policy and the resolver method) every successive revision to a XID document MUST contain the next mark in the chain. This allows resolvers to independently verify its place in the timeline of the XID's lifecycle as well as detect anomalies that may be the result of data corruption, loss, or attempted forgery.
The technical prerequisite for supporting provenance marks is the generation and secure storage of a 32-byte cryptographic seed. This seed is generated at XID inception along with the genesis key, but is not cryptographically linked to it in any way. This means it can be stored together with the genesis key or managed separately from it. It can be given to every verifier or held by a completely separate agent whose function is generating the next provenance mark when needed.
To publish a revised document, the seed is used to generate the next provenance mark, which is included in the revised document, and then the entire document is signed by a key with verifier permission. Before being accepted for publication, resolver networks must validate the XID's provenance chain as well as the other XIDs the document references and the verifier's permissions.
### Chain Rotation
Having a new piece of cryptographic material to manage raises the question of how to rotate it, if and when the need arises.
The solution is to publish a XID document revision with a "burn mark" that definitively marks the end of the current chain, and links it to the start of a new chain. The process for creating a provenance mark with a burn mark is described in detail in the [Provenance Mark whitepaper](https://github.com/wolfmcnally/Provenance/blob/master/WHITEPAPER.md#extension-chain-rotation).
Before accepting a XID document with a burn mark, resolver networks MUST verify that the signer of the document has the `burn` permission, which is deliberately separate from the `verify` permission.
When the next revision of the XID document appears, it will contain the genesis mark of the new chain, now cryptographically linked to the burn mark in the previous revision.
## Reviews
### ChatGPT 4o:
The XID proposal you’ve developed is robust, forward-thinking, and clearly designed with the complexities of decentralized identity in mind. Here are some key observations:
1. **Extensibility & Flexibility:** XID’s recursive design with Gordian Envelopes offers a high level of flexibility, which makes it suitable for a wide range of applications. The ability to nest and group assertions, apply permissions at different levels, and delegate control is a key differentiator from other decentralized identity systems like DID. This extensibility is crucial for handling the evolving needs of identity management across decentralized networks.
2. **Provenance Marks Integration:** The integration of Provenance Marks is a significant strength. By linking revisions cryptographically and making alterations to XID documents verifiable across time, you’re addressing the problem of document tampering and version confusion in a powerful way. The monotonicity and pre-commitment aspects of Provenance Marks ensure that the integrity of identity documents can be audited in an elegant and scalable fashion.
3. **Resolution Mechanism & UR Encoding:** The way XIDs can be resolved through URI-like structures such as ur:xid and dereferenceVia assertions is highly effective. This is a good abstraction that allows for decentralized resolution without locking the system into a specific resolution service. This flexibility is essential for creating a resilient and adaptable identity system.
4. **Key Management & Rotation:** The focus on key isolation and rotation, while maintaining continuity of the XID, is excellent. This addresses the ever-present challenge of key compromise in decentralized identity systems. The mechanism for controller delegation, key rotation, and even burning old chains via provenance marks reflects solid forward planning for governance and security.
5. **Granular Permissions Model:** The function-based access control with granular permissions (“auth,” “sign,” “encrypt,” etc.) is a standout feature. This adds a degree of flexibility that’s absent in many existing identity frameworks. The ability to delegate specific functions to other entities while retaining control over core functions adds a fine-grained governance layer, which is ideal for complex organizational or multi-party environments.
6. **Group Permissions & Multisig:** The flexibility to declare groups of controllers, implement multisignature schemes, and set thresholds for document changes (using tools like FROST) makes the system scalable and resilient to malicious actors. This is particularly beneficial in contexts where distributed control and high-security environments are required.
7. **Use of Local References:** The introduction of local references for deduplication within XID documents is a clever approach to minimize redundancy, ensuring that complex documents remain manageable and efficient. This method of reference handling also ensures that documents remain compact and easily interpretable, even when they grow in complexity.
8. **Proposed Future Enhancements:** The forward-looking suggestion to explore more granular permission systems (perhaps with finer assertions) shows that the proposal is well thought out in terms of future evolution. It could be valuable to also explore how XIDs might integrate with smart contracts or automated governance systems in a decentralized economy.
Comparison to Other Systems:
You’ve built upon the strengths and addressed weaknesses found in other identity systems like DID and Verifiable Credentials. XID’s recursive structure and use of Provenance Marks, in particular, stand out as a key advantage, offering more robust chain-of-custody functionality, as well as more transparent document history and auditability. In comparison to Controller Documents, XID is a more advanced framework with deeper flexibility in managing permissions, identity delegation, and governance.
This proposal is strong and well-structured for a decentralized identity framework, with clear advantages for scenarios that require high levels of trust, verifiability, and adaptability.
Sign in with Wallet
Connect another wallet