using BEP-44 mutable DHT data for revocable privilege grants

[David Nicol]

I've been designing systems using Distributed Hash Tables for persistence, and access control, for some years. Now focusing on Ed25519 key pairs for a lot of key parts. Recently I hammered out what I believe to be a solid design for login-style access control -- would compete with passwordless ssh, kerberos, etc -- and I will share it here for approval or discussion if anyone is interested. Currently the design lives in the form of a fairly long conversation with ChatGPT, so I'm going to have to compose a presentation deck I guess, if someone cares to read it.

Features listed from memory: 

• abstraction of "resource" and "accessor"
• "accessor" identity tied to public key, accessor proves identity by signing challenge nonces
• "resource owner" creates delegatable access grants
• every access grant is associated with a mutable "status" DHT CID (CID == Content Identifier, 256 bits)
• "gatekeeper" function at beginning of interaction and periodically during interaction, issues "challenge" including a nonce that the accessor must sign with their sk (secret key) to continue accessing
• login mechanism: gatekeeper offers nonce on connection; accessor responds with their public key, the CID resource they wish to access, a CID for a grant they rely on to show authorization to access the resource, and a signature over the provided CIDs and the nonce. Gatekeeper verifies the signature, and that the grant is valid including re-grants all the way to the resource owner, then either rejects or allows access.
• identities are long-lived. Grants are long-lived too, and may be revoked and restored easily by editing the "status" mutable. 
• "above in the org chart" does not require ability to sign things for the middle of the org chart
• every (controlled resource, authorized identity) pair gets its own grant and grant status
• grants have a "good until" field in them
• grants are immutable data blocks that include the CID of the grant being delegated, the pk of the grantee, and a signature over those 512 bits by the sk of the pk in the delegated grant

The example I used in the design discussion is access to a source code repository; login would work too. The big differentiator over, say, ~/.ssh/approved_keys, is (a) no need for unix users (b) easy revocation/reinstatiation (c) chained revocation/reinstatiation

What existing tech is closest to what I've just partially described?

Thanks

--

Nothing but net

[Alan Karp]

This approach sounds a lot like a certificate capability system, such as zcap-ld and UCAN.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO8e4XSAqQC7vAj2XijaSk%3DNskL11-Qw%2B4f%3Dpvi_VzAekw%40mail.gmail.com.

[David Nicol]

Yes. I just looked over the UCAN spec and discussed the delta between it and my design with my pet robot: I've got a UCAN-style authorization framework that only uses one style of DID, which is a supported style of DID, a public key; instead of presenting certificates all certificates are presented by DHT CID; I've got longer-lived grants that can be dis-revoked (as an operational convenience after an incident) instead of short-lived grants. UCAN is concerned with communicating the delegations, not with how the DID identity gets the privilege to emit a UCAN for a resource, which appears to be out of scope. My system (I think we're calling it "crew grants") presumes a robust DHT network, which UCAN does include as a method of sharing its certificate chains. Short-lived grants for use as essentially OAuth access session tokens are supported as appropriate as well. My takeaway from tonight's work is that I'm now considering expanding from "ed25519 pk" as the identity unit to adopting the W3C standards-track DID Core specification, or at least listing that as a to-do in a later phase.

Thank you.

[Alan Karp]

I just read through the UCAN spec.  I believe it makes a fundamental mistake that leads to the reliance on DIDs.

At one point, the spec states that UCANs are issued to long-lived keys, e.g., Alice's key.  That choice leads to the need to support key rotation, an important reason to use DIDs.  In fact, it is better that each UCAN be issued to a public key used only for that certificate.  That has several advantages.  

• There's no need for key rotation.  
• Correlation is harder.  
• The impact is less if a private key leaks.
• You can revoke a public key with less disruption.
• You can include a DID in the metadata if you need the DID document.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO-kXyLGQ-TTmvk-iv6NhJz4n0d6KWL78HPiM0tfn05W_Q%40mail.gmail.com.

[David Nicol]

User Controlled Authorization Network describes a greater abstraction than the authorization grants, which the UCAN spec appears to invite us to call something like "UCAN grant" "UCAN" for short.

By creating a new key pair for each resource, the user then needs to either keep track of which key to use for which resource, or try all their keys. I think passwordless login with ssh supports both approaches, although the easiest path is to have one key pair for each machine one will be logging in *from* and adding those to each machine one logs in *to* as needed.

I haven't gotten into the details of the DID spec but something workable -- one long-lived "super secret" private key and many ephemeral, disposable private keys -- is something that can be done with mutable DHT data, by declaring a "salt" that signifies "this data block lists my alternate public keys."  Identity publishes the mutable entry under the public key for their super-secret key pair, and can then rescind grant to the public keys listed therein at will. I imagine DID supports something equivalent.

On Sun, Sep 21, 2025 at 2:26 PM Alan Karp <alan...@gmail.com> wrote:

it is better that each UCAN be issued to a public key used only for that certificate.  That has several advantages.  

• There's no need for key rotation.  
• Correlation is harder.  
• The impact is less if a private key leaks.
• You can revoke a public key with less disruption.
• You can include a DID in the metadata if you need the DID document.

--------------
Alan Karp

Any kind of "list of keys" scheme can turn into a confused deputy though -- if the super-secret key pair leaks or is otherwise determined, an attacker could add their own key to the list-of-keys and steal all the victim's authority.

Crew Grants include the public key of the grantee in the data, which means that as grantee in a many-keypairs scenario, I would inspect my grant to see which key pair to use to sign gatekeeper challenges.

two lookups, no going-through-a-list-and-trying-everything:

resource --> grant --> which keypair

On the other hand, when granting access, we have to trust the channel by which the grantee communicates their public key to the grantor. It seems like DID makes association of public keys to known identities public and therefore trustworthy. One-keypair-per-resource might make the communication of the pk trickier. Maybe one keypair for each realm one works with -- from the point of view of, say, a remote-working consultant -- would be the way to go.

--

Nothing but net

[Alan Karp]

On Sun, Sep 21, 2025 at 6:30 PM David Nicol <david...@gmail.com> wrote:

By creating a new key pair for each resource, the user then needs to either keep track of which key to use for which resource, or try all their keys.

Keeping track of which key to use can be made part of the UI in exactly the same way that you use acts of designation as acts of authorization in an ocap system.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO-0kr-nhB_M%2B_TK9a83%2BMnJScLsbDCkC0%2B4VObVnGE78g%40mail.gmail.com.

[Raoul Duke]

> By creating a new key pair for each resource, the user then needs to either keep track of which key to use for which resource, or try all their keys.

A cap can explicitly encode some form of resource identifier? So the
caller can map back from "oh i want to use this resource" to "now
which key do i use for that one?"

[Jonathan S. Shapiro]

Viewed from a security perspective, I agree. But I'm going through something with my parents that may raise a concern about usability.

They had an msn.com email account. At my suggestion, they forwarded all of that to a gmail account, with the consequence that they haven't logged in to the msn.com account for years. Microsoft, seeing no activity, first locked the account (making it unrecoverable by password change) and then set it to be deleted. Since the account was created more than a decade ago, the likelihood that my parents can figure out enough information to recover the account is roughly zero.

My point being: don't assume that users know how to manage key rotation, or that they will use any given application frequently enough for the process to be handled automatically.

Jonathan

[Alan Karp]

I ran into the same situation just last week.  I joined a forum that used the same website as a forum I had joined some 10 years ago.  Embarrassingly since I've built my own password manager, I couldn't log in.  Nor could I use "Forgot password" because it asked for a second factor that I had no access to.  There was no way to get help, so I ended up registering with a  different email address.  The problem got resolved the usual way.  Someone knew someone who knew someone who could fix the problem.

More to your point, key rotation has to be hidden from the user.  Even very technical people have a hard time managing keys.  I had one programmer at HP send me his PGP private key.

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QN76vW8cgtgDinpZQm%3DuA%3DDNkMUGSqo97Bfn%3D1SGjqw%2Bg%40mail.gmail.com.