Rewrite of 3ID #122
Rewrite of 3ID #122
Conversation
oed
requested review from
smrz2001,
stbrody,
stephhuynh18,
ukstv and
zachferland
I do like 3 DID - it seems more technically accurate even though it is harder to say. 3ID seems more like a product name than a type of DID. Does the "3" have mainly historical significance (presumably in relation to 3Box/Labs) or is there a deeper meaning behind it? |
Yes, mainly historical significance. Also nice to show up on top here |
|
how abt the "3id did". verbose but it saves the time to explain. So might be worth considering ser. |
|
it took me a long time to understand did's are not intended as my digital id(entity). They are identifiers for my 'limbs' in the digital realm (accounts,actors,agents,intermediaries). imo 3ID sounds a lot like a (centralized) ID system. |
|
@Joera given that any crypto keypair can be a did (using the did:key method) you can think of any keys you hold (in a wallet or even offline) as main or root identifiers. Other dids can then be created case-by-case and and granted revocable rights. 3ID DIDs can be one of those subsidiary DIDs (or "limbs" as you called them) that you can CRUD. I'm not sure why 3ID's DID method sounds is centralized. Its certainly coupled to IPLD/IPFS, Ceramic and Ceramic's Tile Document. However it's hard hard to call it centralized when you can use their open source software today to spin up your own ceramic node(s), hosting your own 3ID DIDs (and other documents) without any centralized body stopping you. Someone on core team can correct me but I think you're even free (in terms of rights) to make your own alternative ceramic network, anchoring to whatever blockchain you want. It wont interoperate but I believe it is doable. |
|
hi deadly icon, yes, you're technically correct. devs with specific knowledge will recognize that. but what about the rest of the world? 3ID sounds like it is offering digital identity and digital identity will be associated with centralized systems, companies, governments that will approach identity from the wrong perspective, namely their own. dids can help us do things on the web, while keeping identity private. and by private I don't necessarily mean secret/hidden/anonymous . I mean something fluid, multifaceted that is our own. not something to be given/granted/appointed to us. stepping off my soapbox, my idea is that ID has become a word that is widely associated with a centralized approach to identity ( passport!) and that those associations are only confusing when we want to bring in people to do it differently. |
|
@Joera I hear you but I think were more hung up on nomenclature than we are on the underlying concepts. My passport is not me just as my 3ID DID is not me. They're both identifying artifacts. We have many of those in the real world and we are going to have even more online. A did for every account you have is kind of the floor for how many DIDs were going to have to maintain and keep safe. Thankfully popular operating systems are building such stores. Apple and Microsoft are using Open ID Connect and FIDO. I presume we'll end up with a system where your OS stewards your massive collection of DIDs (keypairs) and sync's them across devices. Hardware keys that control all your susediary keys sounds like the security sweetspot. I doubt your average user is ever going to need to know what a DID is. |
|
@deadlyicon , I guess I am a bit more lunarpunkish on the future use of ID (singular) true, dids will be largely abstracted away in ux. so my "the rest of the world" matters a lot less. I guess the naming should fit for people in between super devs and regular users. people inquiring about decentralised technologies. people like me. I still think calling it what it is, will be best. |
CIPs/CIP-122.md
Outdated
| ## Specification | ||
|
|
||
| <!--The technical specification should describe the syntax and semantics of any new feature.--> | ||
| Specification goes here. |
There was a problem hiding this comment.
left over from template, intended to be removed?
CIPs/CIP-122.md
Outdated
|
|
||
| To read you must load a deterministic Ceramic stream to find any updates made to the 3ID. | ||
|
|
||
| 1. Load the revocation registry Ceramic stream |
There was a problem hiding this comment.
It feels weird to me to call this whole stream the revocation registry when it also contains all the valid added verification methods that have not been revoked.
There was a problem hiding this comment.
Should we just call it the "verification method registry"?
There was a problem hiding this comment.
It's not only used to revoke verification methods. Any CACAO can be revoked using this registry. The main reason you would register a CACAO but not revoke it is to be able to have chained revocations not be recursively revoked. So in my mind this is still mainly a revocation registry.
There was a problem hiding this comment.
but it can also be used not for revocation at all. It is also a registry of the valid verification methods. For 3ids that have never done a revocation this stream will contain no revocations at all, only additions of new valid VMs. Or am I misunderstanding?
There was a problem hiding this comment.
I think I don't understand what this means:
The main reason you would register a CACAO but not revoke it is to be able to have chained revocations not be recursively revoked
don't you add an entry for every new wallet/key you add to the 3id?
CIPs/CIP-122.md
Outdated
| ***To remove a verification method:*** | ||
| 1. Load the *Revocation Registry* stream | ||
| 2. Update (1) by removing the `cacao-mh` that is being revoked |
There was a problem hiding this comment.
do you remove it, or mark it as isRevoked = true?
There was a problem hiding this comment.
Step 2 in the "read" section suggests we use a isRevoked field in the stream
There was a problem hiding this comment.
so then can we clarify the text here?
CIPs/CIP-122.md
Outdated
| } | ||
| ``` | ||
|
|
||
| #### Ceramic Stream |
There was a problem hiding this comment.
is this just re-stating the normal spec for a Ceramic Stream? Do we need this here or could we reference the existing spec?
There was a problem hiding this comment.
It is not really restating the normal spec. For example, the Init Event is different from a normal stream. Also the verification logic is very different from a normal stream.
CIPs/CIP-122.md
Outdated
| 3ID is based on a self-certifying revocation registry represented as a special type of Ceramic stream. In it any verification method belonging to the 3ID can be registered and revoked. Every update to the registry is recorded as a *Data Event*. When a new event is created is needs to include a valid delegation chain back to previous version of the registry. | ||
| ```verilog | ||
| type Prinicipal Bytes // multidid |
There was a problem hiding this comment.
| type Prinicipal Bytes // multidid | |
| type Principal Bytes // multidid |
CIPs/CIP-122.md
Outdated
| 3. Update (2) by adding the `cacao-mh` from (1) | ||
| ***To remove a verification method:*** |
There was a problem hiding this comment.
can any verification method revoke any other verification method (including the original VM that the 3ID identifier is based off of?)? Should there be any hierarchy between VMs? Perhaps VMs should only be allowed to revoke VMs added after it, but not those added before it?
There was a problem hiding this comment.
I think this might be something to explore in future iterations of 3ID. The purpose of this CIP is to enable the basic functionality.
There was a problem hiding this comment.
I'm just thinking about the security considerations. It's weird if you authorize a key temporarily for some app, and that key gets compromised and then revokes the access of all your other keys, including the original key you used to even create the 3id in the first place.
There was a problem hiding this comment.
It's weird if you authorize a key temporarily for some app, and that key gets compromised and then revokes the access of all your other keys
You can still authorize session keys using did-session that only have write access to certain streams, not the 3ID stream.
CIPs/CIP-122.md
Outdated
|
|
||
| ### Object Capabilities | ||
|
|
||
| The 3 DID method relies heavily on object-capabilities as they way to add and remove verification methods, as well as delegating permissions. The root capability is `did/control`, any verification method with this capability has [independent control](https://www.w3.org/TR/did-core/#independent-control) over the DID. This means that they can take any action on behalf of this DID, `*/*` is thus a equivalent of `did/control`. The `did/vm-add` and `did/vm-remove` are actions that can be taken to update the 3ID stream and thus the DID document. In the future other more specific `did/...` capabilities my be specified to define more granular actions on the DID document. |
There was a problem hiding this comment.
| The 3 DID method relies heavily on object-capabilities as they way to add and remove verification methods, as well as delegating permissions. The root capability is `did/control`, any verification method with this capability has [independent control](https://www.w3.org/TR/did-core/#independent-control) over the DID. This means that they can take any action on behalf of this DID, `*/*` is thus a equivalent of `did/control`. The `did/vm-add` and `did/vm-remove` are actions that can be taken to update the 3ID stream and thus the DID document. In the future other more specific `did/...` capabilities my be specified to define more granular actions on the DID document. | |
| The 3 DID method relies heavily on object-capabilities as the way to add and remove verification methods, as well as delegating permissions. The root capability is `did/control`, any verification method with this capability has [independent control](https://www.w3.org/TR/did-core/#independent-control) over the DID. This means that they can take any action on behalf of this DID, `*/*` is thus a equivalent of `did/control`. The `did/vm-add` and `did/vm-remove` are actions that can be taken to update the 3ID stream and thus the DID document. In the future other more specific `did/...` capabilities my be specified to define more granular actions on the DID document. |
CIPs/CIP-122.md
Outdated
|
|
||
| <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> | ||
|
|
||
| While most DID methods include full public keys, or other DIDs as verification methods 3ID chooses to use hashes of object-capabilities as verification methods. One of the main use cases for 3ID is to connect multiple PKH DIDs into a single identifier on Ceramic. While doing so publically is fine for some use cases, the ability to do so privately is quite important for many. Using *capability hashes* enables more privacy since the DIDs that are delegated to doesn't strictly need to be revealed. It is worth noting that revealing the CACAO object when used is the simplest way to prove a capability chain. However, it is possible to create zero-knowledge proofs that only reveal the hash of the capability used and which session key was delegated to. |
There was a problem hiding this comment.
| While most DID methods include full public keys, or other DIDs as verification methods 3ID chooses to use hashes of object-capabilities as verification methods. One of the main use cases for 3ID is to connect multiple PKH DIDs into a single identifier on Ceramic. While doing so publically is fine for some use cases, the ability to do so privately is quite important for many. Using *capability hashes* enables more privacy since the DIDs that are delegated to doesn't strictly need to be revealed. It is worth noting that revealing the CACAO object when used is the simplest way to prove a capability chain. However, it is possible to create zero-knowledge proofs that only reveal the hash of the capability used and which session key was delegated to. | |
| While most DID methods include full public keys or other DIDs as verification methods, 3ID chooses to use hashes of object-capabilities as verification methods. One of the main use cases for 3ID is to connect multiple PKH DIDs into a single identifier on Ceramic. While doing so publically is fine for some use cases, the ability to do so privately is quite important for many. Using *capability hashes* enables more privacy since the DIDs that are delegated to don't strictly need to be revealed. It is worth noting that revealing the CACAO object when used is the simplest way to prove a capability chain. However, it is possible to create zero-knowledge proofs that only reveal the hash of the capability used and which session key was delegated to. |
| Once good post quantum cryptography becomes more widely available extending Ceramic to support that will also be fairly straight forward. | ||
|
|
||
|
|
||
| ## Backwards Compatibility |
There was a problem hiding this comment.
This talks about backwards compat for users of the old 3id, but what about backwards compat for existing users of did:pkh? Will they have a migration path to 3id that doesn't cause them to lose all their data/streams? I'm thinking about what Orbis brought up in our call with them today about being forced to start from scratch multiple times.
There was a problem hiding this comment.
This is out of scope for this specification. This would be added on top, e.g. using a mechanism similar to caip10-links. See Grafting DIDs paragraph of this article: https://blog.ceramic.network/accounts-evolution-of-3id/
There was a problem hiding this comment.
I don't really follow how that helps with backwards compatibility? Can you now use your 3id to update your streams that are controlled by your old did:pkh?
There was a problem hiding this comment.
Can you now use your 3id to update your streams that are controlled by your old did:pkh?
Haven't thought about this use case. Interesting, would need to think about how this could be done securely. Perhaps the did:pkh could delegate */* (or did/control) as a capability to the did:3.
|
|
||
| ## Privacy Requirements | ||
|
|
||
| The 3 DID method provides a unique privacy enhancement over most other DID methods in that subject only need to reveal hashes of object-capabilities in order to use it. While the simplest way of implementing usage of the system would imply pulicly revealing these object-capabilities, it is indeed possible to create zero-knowledge proofs of the valididty of an object-capability without revealing its content. |
There was a problem hiding this comment.
| The 3 DID method provides a unique privacy enhancement over most other DID methods in that subject only need to reveal hashes of object-capabilities in order to use it. While the simplest way of implementing usage of the system would imply pulicly revealing these object-capabilities, it is indeed possible to create zero-knowledge proofs of the valididty of an object-capability without revealing its content. | |
| The 3 DID method provides a unique privacy enhancement over most other DID methods in that subject only need to reveal hashes of object-capabilities in order to use it. While the simplest way of implementing usage of the system would imply publicly revealing these object-capabilities, it is indeed possible to create zero-knowledge proofs of the validity of an object-capability without revealing its content. |
|
3ID seems like easier to refer to shorthand, and it is the W3C DID method name |
CIPs/CIP-122.md
Outdated
|
|
||
| To read you must load a deterministic Ceramic stream to find any updates made to the 3ID. | ||
|
|
||
| 1. Load the revocation registry Ceramic stream |
There was a problem hiding this comment.
but it can also be used not for revocation at all. It is also a registry of the valid verification methods. For 3ids that have never done a revocation this stream will contain no revocations at all, only additions of new valid VMs. Or am I misunderstanding?
CIPs/CIP-122.md
Outdated
|
|
||
| To read you must load a deterministic Ceramic stream to find any updates made to the 3ID. | ||
|
|
||
| 1. Load the revocation registry Ceramic stream |
There was a problem hiding this comment.
I think I don't understand what this means:
The main reason you would register a CACAO but not revoke it is to be able to have chained revocations not be recursively revoked
don't you add an entry for every new wallet/key you add to the 3id?
CIPs/CIP-122.md
Outdated
| 3. Update (2) by adding the `cacao-mh` from (1) | ||
| ***To remove a verification method:*** |
There was a problem hiding this comment.
I'm just thinking about the security considerations. It's weird if you authorize a key temporarily for some app, and that key gets compromised and then revokes the access of all your other keys, including the original key you used to even create the 3id in the first place.
CIPs/CIP-122.md
Outdated
| ***To remove a verification method:*** | ||
| 1. Load the *Revocation Registry* stream | ||
| 2. Update (1) by removing the `cacao-mh` that is being revoked |
There was a problem hiding this comment.
so then can we clarify the text here?
CIPs/CIP-122.md
Outdated
| <multidid> := <varint multidid><cacao-mh><varint 0x00> | ||
| ``` | ||
|
|
||
| 2. Encode the multidid as an inline CID, |
There was a problem hiding this comment.
| 2. Encode the multidid as an inline CID, | |
| 2. Encode the multidid as an inline CID (using the "identity" multihash so the CID self-describes all its data), |
CIPs/CIP-122.md
Outdated
|
|
||
| #### Consensus | ||
|
|
||
| In case of two conflicting events (two events share the same `prv` value) the event with the earliest `TimestampEvent` should be processed first. Note that this might lead to the latter event being invalid due to its delegation chain being revoked. Also, a new event emitted after the conflict must reference both branches in its `prv` and resolve any conflict of the `Registry`. |
There was a problem hiding this comment.
should we add a section here describing that behavior/feature?
| Once good post quantum cryptography becomes more widely available extending Ceramic to support that will also be fairly straight forward. | ||
|
|
||
|
|
||
| ## Backwards Compatibility |
There was a problem hiding this comment.
I don't really follow how that helps with backwards compatibility? Can you now use your 3id to update your streams that are controlled by your old did:pkh?
|
|
CIPs/CIP-122.md
Outdated
| > did:3:<cacao-mh> | ||
| > ``` | ||
| The `<cacao-mh>` value is a `keccak-256` multihash over the CID of a CACAO object-capability, e.g. ReCap or UCAN. The value MUST be encoded as a multibase string, using `base58btc`. |
There was a problem hiding this comment.
|
After thinking more about how to approach 3ID and revocations I've realized that the revocation registry as defined in this CIP is relevant for all DIDs not just 3ID. I'm planning to rewrite this CIP to be focused on a pursely generative 3ID and create a separate CIP for the revocation registry. |
|
Just made a big update to make 3ID purely generative. I'll create a follow up CIP for CapReg. |
📚Preview
Naming question: Should we refer to it as 3ID or the 3 DID method?