CIP: CapReg - object-capability registry #127
Conversation
|
|
||
| <!--Motivation is critical for CIPs that want to change the Ceramic protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the CIP solves. CIP submissions without sufficient motivation may be rejected outright.--> | ||
|
|
||
| Currently in Ceramic the main accounts types are PKH DID. These are great because they enable existing wallets to be used directly with Ceramic. Once a PKH DID is used to delegate permissions to a session key. That delegation will remain valid until the capability expires. This could be a problem in the case of a stolen session key or a malicious application. By introducing a capability registry these capabilities can be revoked at any time by the main DID (PKH DID in the case above, but this would work for any DID method). A system that uses these object capabilities could refer to the registry to verify that the capability has not been revoked before it was used. |
There was a problem hiding this comment.
| Currently in Ceramic the main accounts types are PKH DID. These are great because they enable existing wallets to be used directly with Ceramic. Once a PKH DID is used to delegate permissions to a session key. That delegation will remain valid until the capability expires. This could be a problem in the case of a stolen session key or a malicious application. By introducing a capability registry these capabilities can be revoked at any time by the main DID (PKH DID in the case above, but this would work for any DID method). A system that uses these object capabilities could refer to the registry to verify that the capability has not been revoked before it was used. | |
| Currently in Ceramic the main accounts types are PKH DID. These are great because they enable existing wallets to be used directly with Ceramic. Once a PKH DID is used to delegate permissions to a session key, that delegation will remain valid until the capability expires. This could be a problem in the case of a stolen session key or a malicious application. By introducing a capability registry these capabilities can be revoked at any time by the main DID (PKH DID in the case above, but this would work for any DID method). A system that uses these object capabilities could refer to the registry to verify that the capability has not been revoked before it was used. |
|
|
||
| 1. Generate the multidid representation of the DID (see [Multidid specification]()). | ||
|
|
||
| 2. Encode the multidid as an inline CID, |
There was a problem hiding this comment.
this is interesting as it breaks some assumptions in the Ceramic code as it exists today. Currently we always assume the genesis CID can be loaded and used to create an initial StreamState object for the stream
|
|
||
| 2. Encode the multidid as an inline CID, | ||
|
|
||
| ```solidity |
There was a problem hiding this comment.
why is this marked as solidity code?
|
|
||
| ### Object Capabilities | ||
|
|
||
| CapReg relies heavily on object-capabilities as they way to add and remove CACAO hashes in the registry. Write access to CapReg can be delegated in the same way as delegting access to any other stream in Ceramic. Example using ReCap: |
There was a problem hiding this comment.
| CapReg relies heavily on object-capabilities as they way to add and remove CACAO hashes in the registry. Write access to CapReg can be delegated in the same way as delegting access to any other stream in Ceramic. Example using ReCap: | |
| CapReg relies heavily on object-capabilities as the way to add and remove CACAO hashes in the registry. Write access to CapReg can be delegated in the same way as delegting access to any other stream in Ceramic. Example using ReCap: |
|
|
||
| <!--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.--> | ||
|
|
||
| CapReg enables any DID to delegate full or partial permission to any other DID without having to worry about the capability getting lost since capabilities can now be revoked. The design requires some special logic for the state transition of the event stream to ensure that the capability is valid when the stream was updated. While Ceramic generally strives towards not including state transtion logic in event streams, for this particular case it seems difficult to avoid. |
There was a problem hiding this comment.
While Ceramic generally strives towards not including state transtion logic in event streams
What does this mean?
There was a problem hiding this comment.
don't all of our streams have state transition logic?
|
|
||
| type Entry struct { | ||
| key CACAOHash | ||
| revoked Boolean // true if the capability has been revoked |
There was a problem hiding this comment.
it might be nice to make this more than a boolean, but rather a state string. For instance at some point I think it could be very valuable to have a distinction between revoking a capability and invalidating it only after the time it is revoked, vs doing a revocation that also retroactively invalidates all writes that were ever done with the capability - decreeing the capability to never have been valid in the first place. The latter could be useful if a user is tricked into signing a capability to a malicious app that then immediately starts publishing junk as the user.
Even if we only support "going forward" revocation in the first version, it would be nice to leave the door open to adding "retroactive" revocation as well in the future.
📜 Preview