Skip to content

did:nostr: align DID-document @context to cid/v1 per updated CG spec #581

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jjohare wants to merge 1 commit into
base: gh-pages
Choose a base branch
from
Open

did:nostr: align DID-document @context to cid/v1 per updated CG spec #581

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 12 additions & 6 deletions src/idp/well-known-did-nostr.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -450,18 +450,24 @@ export async function resolveDidNostrLocally(pubkeyHex) {
/**
* Build a CID-shaped DID document for a Nostr pubkey + account pair.
*
* Uses the spec example's vocabulary (Multikey + publicKeyMultibase)
* for max interop with our own resolver and the W3C VC track. The
* Multikey value is computed deterministically from the pubkey via
* the f-form recipe (multibase `f` + multicodec `e701` + parity byte
* `02` + 32-byte xonly hex) — the same shape the doctor's B.2 emits.
* Uses the vocabulary of the updated did:nostr CG spec example
* (https://nostrcg.github.io/did-nostr/): Multikey + publicKeyMultibase,
* @context [https://www.w3.org/ns/cid/v1, https://w3id.org/nostr/context]
* (cid/v1 is the Controlled Identifiers v1.0 context that defines the
* Multikey term). The Multikey value is computed deterministically from
* the pubkey via the f-form recipe (multibase `f` + multicodec `e701` +
* parity byte `02` + 32-byte xonly hex) — the same shape the doctor's B.2
* emits. Verification-relationship refs are kept ABSOLUTE
* (`did:nostr:<hex>#key1`); the spec example shows the relative `#key1`
* form, but DID Core permits both and this indexer deliberately
* absolutizes auth refs (see the profile-absolutization path below).
*/
function buildDidDocument({ pubkey, webId }) {
const did = `did:nostr:${pubkey.toLowerCase()}`;
const multikey = `f` + `e701` + `02` + pubkey.toLowerCase();
const vmId = `${did}#key1`;
return {
'@context': ['https://w3id.org/did', 'https://w3id.org/nostr/context'],
'@context': ['https://www.w3.org/ns/cid/v1', 'https://w3id.org/nostr/context'],
'id': did,
'type': 'DIDNostr',
'alsoKnownAs': [webId],
Expand Down
2 changes: 1 addition & 1 deletion test/well-known-did-nostr.test.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -129,7 +129,7 @@ describe('GET /.well-known/did/nostr/:pubkey (#407)', () => {
assert.ok(r.headers.get('last-modified'));

const doc = await r.json();
assert.deepStrictEqual(doc['@context'], ['https://w3id.org/did', 'https://w3id.org/nostr/context']);
assert.deepStrictEqual(doc['@context'], ['https://www.w3.org/ns/cid/v1', 'https://w3id.org/nostr/context']);
assert.strictEqual(doc.id, `did:nostr:${alicePk}`);
assert.strictEqual(doc.type, 'DIDNostr');
assert.ok(Array.isArray(doc.alsoKnownAs));
Expand Down