Re: did:nostr v0.1.0 and BIP-340 Data Integrity

st 1. 7. 2026 v 14:24 odesílatel Will Abramson <will@legreq.com> napsal:

> This is great to hear, thanks Melvin.
>
> Would you be interested to present did:nostr on a CCG call sometime?
>
> On a quick scan, I found it interesting that you used the Controlled
> Identifier context - https://www.w3.org/ns/cid/v1  - rather than the DID
> context. I think this may make it a Controlled Identifier, not a
> Decentralized Identifier as stated.
>
> At least it seems in conflict with this normative MUST from the DID spec:
>
> > In addition to using the JSON representation
> <https://www.w3.org/TR/did-1.1/#dfn-representations> production
> <https://www.w3.org/TR/did-1.1/#dfn-production> rules, production *MUST* include
> the @context entry. The serialized value of @context *MUST* be the JSON
> String <https://www.rfc-editor.org/rfc/rfc8259#section-7>
> https://www.w3.org/ns/did/v1.1, or a JSON Array
> <https://www.rfc-editor.org/rfc/rfc8259#section-5> where the first item
> is the JSON String <https://www.rfc-editor.org/rfc/rfc8259#section-7>
> https://www.w3.org/ns/did/v1.1 and the subsequent items are serialized
> according to the JSON production
> <https://www.w3.org/TR/did-1.1/#dfn-production> rules.
>
> Was this intentional?
>

Thanks Will, this is a great catch! So we want to support both DID and CID
since they are RECs. And we also want to to support the upcoming LWS REC.

We started out with the did context, then moved to the cid context, as I
thought that is what we were supposed to do. This copy slipped through the
refactor.

So now I am wondering what is the best practice? Should we use the did
context or the did context, or do we need 2 specs?


>
> Great to see the work progressing,
> Thanks,
> Will
>
>
> On Wed, Jul 1, 2026 at 1:09 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>> Hi all,
>>
>> A brief heads-up that the W3C Nostr Community Group has published
>> did:nostr v0.1.0 as a Community Group Draft Report:
>>
>> https://nostrcg.github.io/did-nostr/
>>
>> did:nostr defines a DID method for Nostr identities, based on secp256k1 /
>> BIP-340. The method now has 30+ implementations, so this seemed worth
>> surfacing here given the overlap with CCG work.
>>
>> A few items that may be of interest:
>>
>> 1. did:nostr is registered in the DID Method Registry.
>>
>> 2. It includes a conformance test-vector suite covering key
>> transformation, parity decoding, error taxonomy, and document generation.
>>
>> 3. A DIF did-resolver driver is available, so it can be used through the
>> Universal Resolver.
>>
>> 4. Verification methods use Multikey with secp256k1 keys, which connects
>> directly with CCG work on Data Integrity and cryptosuites.
>>
>> If useful in making the case for that work, did:nostr provides a live DID
>> method and implementation ecosystem that wants to issue and verify VCs with
>> Nostr keys via Data Integrity.
>>
>> Status-wise, this is still an early Draft Report. The main open design
>> item on the path to a Final Report is key rotation / deactivation. Review
>> and critique are very welcome, especially around Multikey/parity handling,
>> the resolution model, and how this should fit with CCG Data Integrity work.
>>
>> See also:
>>
>> https://did-nostr.com/
>>
>> Thanks,
>> Melvin
>>
>