feat: Add capability spec #6
Conversation
|
|
||
| More formally, given the issuer, a path a capability is published under, and a proposed receiver, it should not be possible for anyone else to know if that is the correct receiver. | ||
|
|
||
| For such cases instead of publishing these under the pubkey of the receiving entity, they are instead published under `encrypt(receiver, concat(receiver-pubkey, nonce))`. The receiver must attempt to decrypt all paths until they find their one. The issuer should save and use the same nonce in future so this only needs to happen once. |
There was a problem hiding this comment.
Counterproposal: publish under scalarmult(my_sk, their_pk). They can compute scalarmult(their_sk, mypk) (which yields the same value) to look up my capabilities for them.
There was a problem hiding this comment.
Ok, that's super neat, thanks :D
There was a problem hiding this comment.
Question - does this pose an issue if any other app tries to use the public/secret combination as a shared secret, e.g. for encryption?
Just been reading a bunch of random stuff like this
Perhaps this should be HKDF-Expand(scalarmult(my_sk, their_pk), "capability-publication", 32), so we never disclose the original shared secret?
There was a problem hiding this comment.
There are other issues as well: if you and I both write capabilities using the naive implementation, we both use the same curve point, so an observer actually sees that the two of us have exchanged capabilities. So there needs to be some further symmetry breaking. So see this "counterproposal" more as opening up some design space rather than as a serious suggestion.
There was a problem hiding this comment.
But a definite "yes" to "Does this pose an issue if any other app tries to use the public/secret combination as a shared secret, e.g. for encryption?"
It might suffice to hash the shared secret (using a hash function that isn't used anywhere else - in practice, the same function you'd use elsewhere, but salted by hashing concat("CapabilityBuddies!", <shared secret>)) to work around problems with using the shared secret directly elsewhere? Could also break the symmetry for mutual capability-giving by using different hash functions depending on whether it is the peer with the greater or the lesser publickey issuing the capability.
edit: I basically redescribed hkdf, didn't I. I mean, not exactly, but pretty close in intent...
Take all of this with a large I-am-not-a-cryptographer grain of salt.
|
|
||
| ## Capability document IDs | ||
|
|
||
| You may want one, or many, depending on the application, if you want to coordinate between multiple client devices etc. These are opaque to the receiver, who should decode all documents under the path prefix. |
There was a problem hiding this comment.
The document exposition needs some clarification on whether we assume peers to reuse keypairs on multiple devices, or whether there should be at most one device per keypair. Do we wish to support both?
|
|
||
| You may want one, or many, depending on the application, if you want to coordinate between multiple client devices etc. These are opaque to the receiver, who should decode all documents under the path prefix. | ||
|
|
||
| A suggested scheme for this would be using `/1`, `/2` etc. If you're merely extending the lifetime of an existing cap, then you can write to the same path. It doesn't matter if you have two clients that independently do this. If you want to change the contents, you should increment the number, and tombstone older entries. This behaviour doesn't handle the same user making changes to the same receiver's caps concurrently on two devices they own - only one will win. |
There was a problem hiding this comment.
Not quite getting either what exactly you describe here, nor which problem it solves =(
Which might very well be attributed to me being exhausted, but at the very least, it points to an opportunity to clarify the writing a bit.
There was a problem hiding this comment.
Fair, will try and elaborate and reword. This relates to our discussion on Discord on multiple client apps using the same keypair to run this extension process, and what happens if they conflict. I think some more explicit examples would likely help. (Hmm, maybe a diagram? Will give it a go)
|
|
||
| Then you can put the actual week by week capability in there. Each time you make an entry, or regularly on expiry (whichever makes sense for your app), overwrite the entry at that path with a new capability, extending the time. This prevents there being lots of documents, and the first thing they can do on sync is get the latest capability, and then use that to sync all entries in the past. This could likely be done by the same client you're using to make the entries - if you aren't making you entries, the existing caps are sufficient. If you make an entry outside of the current end time, you'll want to update them all. Any peer will get the updated caps in the same sync as the new entries, whether that's a direct peer or via some pub/relay. | ||
|
|
||
| To stop someone accessing future Entries, stop updating the capability (and optionally tombstone the old one). |
There was a problem hiding this comment.
This section needs a discussion of alternatives. Of the top of my head, you could also post a new capability to /stuff-they-care-about/next-capability at the end of the week.
Also: recommendations for posting overlapping capabilities (chances are you want to issue week-long capabilities every 3.5 days or so).
Also: How about immediately merging caps? I.e. not giving one for week 1 first and week 2 second, but one for week 1 first, and one for (week1and wek2) second, and so on.
There was a problem hiding this comment.
This section needs a discussion of alternatives. Of the top of my head, you could also post a new capability to /stuff-they-care-about/next-capability at the end of the week.
Also: recommendations for posting overlapping capabilities (chances are you want to issue week-long capabilities every 3.5 days or so).
🤔 I guess I was purely imagining this from a "giving out read-only caps" perspective. So, if you've not written anything new, no need for new caps, there'd be no entries anyway. But, for allowing writing - yeahh, you want overlap. I'll extend this section and cover some of these use-cases. Thanks :)
Also: How about immediately merging caps? I.e. not giving one for week 1 first and week 2 second, but one for week 1 first, and one for (week1and wek2) second, and so on.
This is what I was imagining. Will make this more explicit
|
|
||
| To stop someone accessing future Entries, stop updating the capability (and optionally tombstone the old one). | ||
|
|
||
| ### Granting public access |
There was a problem hiding this comment.
Can probably omit the details for this from the design process until everything else has settled.
Had a go at writing up some ideas on how capability distribution could be done