Conversation
Added info about did:plc registry integration
| ```mermaid | ||
| sequenceDiagram | ||
| participant User | ||
| participant Client as W3up Client | ||
| participant Server as Upload API | ||
| participant Storage as Delegation Storage | ||
|
|
||
| User->>Client: Authenticate with existing did:plc | ||
| Client->>User: Private key available locally | ||
| Client->>Server: access/fetch (with: did:plc) | ||
| Server->>Storage: Find delegations for did:plc | ||
| Storage->>Server: Return delegations | ||
| Server->>Client: Return delegations | ||
| Client->>Client: Combine local did:plc→agent delegation with fetched did:plc delegations | ||
| Client->>User: Authorization complete | ||
| ``` |
There was a problem hiding this comment.
suggestion: I'd like to see us track the specific keys a little more clearly in this diagram. I'm still confused about how this works. How does the user/client prove their identity as did:plc:[…]? In other words, how do they issue and sign a delegation/invocation as that identity?
| ```javascript | ||
| { | ||
| can: 'access/fetch', | ||
| with: 'did:plc:*' // Only did:plc method supported |
There was a problem hiding this comment.
suggestion: This won't work right; we'd need to have authority delegated from this DID. Instead, I think we want the DID we're looking for in the nb, while with should be the issuer of the invocation (the Agent). In other words, these should be self-signed.
Alternatively, we might avoid UCAN altogether for this. It's a little odd to me to use Ucanto as a way to do the equivalent of an unauthenticated GET request. Maybe it would make more sense to just expose an HTTP GET endpoint?
2 participants
Preview
This RFC is a proposal to integrate the
did:plcmethod into Storacha stack for decentralized identity and Lit PKP encryption key management.