- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Tue, 5 Aug 2025 11:23:40 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Will Abramson <wip.abramson@gmail.com>, Credentials Community Group <public-credentials@w3.org>
On Mon, Aug 4, 2025 at 7:26 AM Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > > po 4. 8. 2025 v 11:39 odesÃlatel Will Abramson <wip.abramson@gmail.com> napsal: >> >> Thanks Melvin. I fully expect this to work. Although this: >> >> > So long as we can keep our canonical URIs in nostr, prepending a short prefix in the VC proofs does not strike me as a great hardship >> >> Threw me off a bit. What I believe Dave is proposing is about the encoding of the key in the verification method of the DID document. The proof (the signature bytes) are encoded using base58-btc. >> >> I agree with Dave that this should not effect did:nostr’s method specific identifier. Which is the hex encoding of the Schnorr key. > > > I think there is enough wiggle room to make it all work. Thanks for showing a willingness to compromise. We'll use the hex form in nostr in the verification method, and also we have schnorr signatures built into the nostr protocol already. I dont think we'll go multibase for nostr identifiers in the document, as it would take up too much space (we have millions of DIDs), but we could compromise if we are using VC proofs. I think it will all work out, maybe even with some inferencing. Looking forward to seeing how the spec progresses. Just a quick note that there's a way to add some multikey/multibase support at the DID resolution layer without needing any additional storage or other changes to the underlying storage implementation. This might be of interest to the Nostr community if it would allow more applications to more easily consume Nostr DIDs. For example, you can make the Nostr DID method spec say resolvers will translate the verification methods found during an intermediate resolution step before returning the resolved DID document. If you've got signed DID documents where the signature needs to be preserved in the resolution response, you can do this translation in a number of optional ways (or allow resolvers to be configured to default to certain behavior based on application needs). In short, a DID method spec can define any number of intermediate steps to be performed during DID resolution -- which can sometimes allow for interesting improvements or adjustments in various directions. -- Dave Longley CTO Digital Bazaar, Inc.
Received on Tuesday, 5 August 2025 15:24:01 UTC