Skip to content
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.

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

[proposal] Allow query of a key fragment as a document #141

Open
F-Node-Karlsruhe opened this issue Nov 7, 2022 · 3 comments
Open

[proposal] Allow query of a key fragment as a document #141

F-Node-Karlsruhe opened this issue Nov 7, 2022 · 3 comments
Labels
enhancement New feature or request pinned an issue that may take a while to fix and should not be closed automatically.

Comments

@F-Node-Karlsruhe
Copy link

F-Node-Karlsruhe commented Nov 7, 2022

Is your feature request related to a problem? Please describe.
I'm currently using the web-did-resolver in a custom document loader and it works very well, but i still have to query key fragments separately like so:

  const [did, keyFragment] = url.split('#')

  // fetch document
  const didDocument: any = (await getResolver().resolve(url)).didDocument

  // if a keyFragment of the DID document is queried
  if (keyFragment && didDocument) {
      
      // TODO allow query of other fields than verification method as well
      const keyFragmentDoc: any | undefined = didDocument.verificationMethod.filter(function(method: any) {
                                                                      return method.id === url || method.id === verificationMethod;
                                                                  })[0];

      if (!keyFragmentDoc)
          throw new jsonldSignatures.VerificationError(
                      new Error(`${verificationMethod} is an unknown key fragment for ${did}`)
                      );

      return {
          contextUrl: null,
          documentUrl: url,
          // deliver keyFragment with the DID doc context
          document: Object.assign(verificationMethodDoc, {'@context': didDocument['@context']}),
      };

  }

  return {
      contextUrl: null,
      documentUrl: url,
      document: didDocument,
  };

Describe the solution you'd like
If the key fragment is specified the resolver should not return the DID document, but the key fragment document. (See code above)

Describe alternatives you've considered
See code above

Moved here from decentralized-identity/web-did-resolver#121

@peacekeeper
Copy link
Member

I agree this would be a useful feature. This is part of a bigger concept called DID URL Dereferencing, which is partially explained in the DID Core spec (see here), and partially in the DID Resolution spec (see here). There are also some test cases in the DID Resolution test suite (see here).

There are some things to consider, e.g. the representation of the DID document (JSON-LD or JSON or CBOR etc.) and relative references. In general URI architecture, dereferencing a fragment depends not on the URI scheme (i.e. "did:"), but on the content type of the deferenced primary resource (i.e. the DID document).

Anyway, this is just some background information, and not all the details are "officially" specified yet. In general, +1 to supporting the dereferencing of fragments in DID resolution libraries like this one.

@stale
Copy link

stale bot commented Jan 16, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jan 16, 2023
@stale
Copy link

stale bot commented Jan 16, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@mirceanis mirceanis added the pinned an issue that may take a while to fix and should not be closed automatically. label Jan 16, 2023
@stale stale bot removed the stale label Jan 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pinned an issue that may take a while to fix and should not be closed automatically.
Projects
None yet
Development

No branches or pull requests

3 participants