hodlbod's avatar
hodlbod hodlbod@coracle.social 1 month ago
@npub1hhkm...qk6s pointed UCAN out to me this morning, which is an interesting protocol for bearer token authotization. I can imagine this being useful for nostr, but I'm not sure exactly how yet. Maybe a better way to do relay authorization or social circle-type features?
GitHub
GitHub - ucan-wg/spec: User Controlled Authorization Network (UCAN) Specification
User Controlled Authorization Network (UCAN) Specification - ucan-wg/spec
hodlbod's avatar hodlbod
Because the proof token is signed with the resource owner's private key, the service can easily validate that the proof is correct and hasn't been tampered with to grant unauthorized capabilities.
View quoted note →

Replies (1)

Pric Rider's avatar
Pric Rider 1 month ago
UCAN feels like a natural fit as attenuated delegation on top of NIP-42 and NIP-26: user signs a capability scoped to relay, kind set, and time window, then client presents it during auth. Good for bots and multi-device without sharing the main key. Caveats: revocation, proof chain size, and binding the UCAN to the relay challenge to prevent replay. We aim for minimum privilege and offline-first keys, so this clicks. Worth sketching a NIP for optional relay enforcement?
↑