Verax Improvement Proposal [VIP-1] - Verax DID Method
Author: @simon.brown
Title: Create a Verax DID method
Type: Verax Improvement Proposal
Abstract
We propose establishing a DID method for Verax, which would allow attestation to be issued to a DID, instead of to a wallet address. This would give many benefits, including key rotation, mass revocation though revoking the DID instead of the attestation itself, chain agnostic attestation ids, and potential other benefits in the future.
Proposal Summary
Create a did:vrx DID method facilitated through a first-class schema, smart contract functions, and SDK helper functions.
Overview of Proposal
The key elements of this proposal are:
- create documentation for the
did:vrxmethod - create a
did:vrxschema and a portal that can issue, revoke and replace them - create a smart contract function that can resolve a did internally
- create a smart contract function that allows users to revoke an attestation issued to their DID.
- create an SDK convenience methods for creating and resolving
did:vrxidentifiers - create a Universal Resolver driver to resolve
did:vrxDIDs
While no clear timelines are proposed, the above scope should be achievable inside of one quarter between multiple contributors, each working on one part, though currently, who works on what is an open question.
Motivation
As users collect more and more attestations, many of them will be issued to a single address. If this address is compromised, it will very difficult for the user to revoke the various attestations. Some issuers also don’t allow revocation of the attestation itself.
An improvement to the way things are done currently would be to issue the attestations to a DID, which itself is an attestation. If querying the registry via an attestation id, and the subject is a DID of the did:vrx method, the registry can look up the attestation specified as the DID, and can return the address specified in the DID document.
This means that if a user ever loses their private key or if their key is compromised, they can update the address that the attestations were issued to, or simply revoke all attestations issued to that DID, by revoking the DID itself, and also by revoking the attestations as well if they want to.
Note: that part of this proposal is also to allow subjects to revoke any attestation that was issued to them. Though this may be a separate concern, it is one of the motivations behind the proposal, and should be discussed. This would involve allowing the revocation of any attestation who subject is a wallet address, by the owner of the wallet address.
Technical considerations
Compressed Attestation IDs
Ideally we would be able to refer to an attestation like so:
did:vrx:0x0001045699
Which would resolve to an attestation with an id of 0x0001000000000000000000000000000000000000000000000000000000045699... on a Verax instance on the correct chain, and would return an attestation, which when decoded against the DID schema would look like:
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/suites/secp256k1recovery-2020/v2"
]
"id": "did:vrx:0x010a5fe9",
"verificationMethod": [{
"id": "did:vrx:0x010a5fe9#key-0",
"type": "EcdsaSecp256k1RecoverySignature2020",
"blockchainAccountId": "eip155:1:0x89a932207c485f85226d86f7cd486a89a24fcc12"
}],
"assertionMethod": [{
"id": "did:vrx:0x01073ab2#key-0",
"type": "EcdsaSecp256k1RecoverySignature2020",
"blockchainAccountId": "eip155:1:0x20974C8722622d523438AA265F7188a96309A4bB"
}]
}
Attestation ID compressed format:
The attestation id 0x010a5fe9 is actually a compressed format of the actual attestation id, which is: 0x00010000000000000000000000000000000000000000000000000000000a5fe9
The compression simply truncates any contiguous leading zeros after the chain id prefix, (in this case 1, i.e. : 0x0001...). Furthermore, the leading zeros before the chain id can be reduced to one, as are the trailing zeros after the chain prefix. When reading the attestation id, the last zero in the id indicates that everything afterwards is the attestation id, which should be cast to bytes32 and the first zero in the attestation id indicate the digits following it, and up to the attestation id, is the chain id.
DID schema
This DID would require an on-chain schema string that looks like:
(string[] context, string id, (string id, string type, string blockchainAccountId)[] verificationMethod), (string id, string type, string blockchainAccountId)[] assertionMethod)
Note: this doesn’t allow for things like different key types, service endpoints etc. so there is scope for considering a slightly more flexible schema.
Expected Timeline
This is an open ended discussion for now, with no definitive voting date or deployment date set.
Design Considerations
When the getAttestation method of the attestation id is called, the specified attestation id should be tested to see if it starts with the substring did:vrx:0 - if it does, then the chain id should be matched against the network the registry is deployed on, and if there is a match, then the did suffix should be decompressed into an attestation id, and this should be retrieved.
It will be expected that the resulting attestation will have a schema id that is the DID schema. The registry should then checked if this attestation has been revoked or replaced. If it has been replaced, then the replacedBy attestation should be looked up, and then this should be checked to see if it has been replaced, and these steps should be repeated recursively until we have a current attestation or a revoked attestation.
When returning the attestation that was given initially, the revoked bit should be set according the status of the final DID attestation that was retrieved.
Deployment Considerations
- the documentation for the
did:vrxmethod can be created as a markdown document, and then added to GitBook - the
did:vrxschema and a portal should be created on a testnet first - the smart contract function that can resolve a did internally can be created as a standalone contract for testing, and then later ported into the attestation registry
- to create a smart contract function that allows users to revoke an attestation issued to their DID, will require an upgrade to the core Attestation Registry contract, and this should be carried out on a testnet
- creating an SDK convenience methods for creating and resolving
did:vrxidentifiers can simply be developed and tested on a feature branch - a Universal Resolver driver to resolve
did:vrxDIDs is created as a docker image, and once completed is submitted to the universal resolver website for inclusion
Next Steps
Next steps are for stakeholders to review and comment on this proposal, and suggest any changes or amendments as necessary. Following a period of discussion, then we will need to create user stories for of the deliverables described above. Critically, we will need to agree on when to vote on this proposal in order to proceed with the implementation, especially on the core contracts.
References and Links
Description of EcdsaSecp256k1RecoverySignature2020 Verification Key method