Dereferencing a URL did not result in a valid JSON-LD object

[cryptobenkei]

I've been trying to create my own context and, no matter what, I always get the same result:

jsonld.InvalidUrl: Dereferencing a URL did not result in a valid JSON-LD object. Possible causes are an inaccessible URL perhaps due to a same-origin policy (ensure the server uses CORS if you are using client-side JavaScript), too many redirects, a non-JSON response, or more than one HTTP Link Header was provided for a remote context.

From Apache with Cors enabled, from schema.org, from github...
This is the jsonld : https://raw.githubusercontent.com/Caelumlabs/credentials/master/src/v1.jsonld

In the jsonld online checker everything worked fine.

How can I use schema.org or define my own context?

[mattcollier]

Please see: https://github.com/digitalbazaar/vc-js#custom-documentloader

and: https://github.com/digitalbazaar/jsonld-signatures#introduction

[cryptobenkei]

Thanks Matt!

[marcvanandel]

This might also be an issue of the underlying jsonld.js library. The json-ld context of the ed25519-signature-2020 returns a HTTP 304 response with the content ... but the jsonld.js lib interpretes this into a redirect of some sort ... and does not acknowledge the content. Therefor I do get this same error using the ed25519-signature-2020 lib 😞

[davidlehn]

(See also digitalbazaar/jsonld.js#451 (comment))
@marcvanandel How are you getting a 304? The default jsonld.js node document loader does not send cache headers, so servers should not be sending back 304. The loader should better handle various return codes in any case.

[marcvanandel]

Hmm... this is strange. I did get back 304 whole day Wednesday and yesterday ... but today it returns a 200 🤔 Using the Brave browser and the network tab of the developer tools ... [edit] Ah... refresh page will return a 304 ...

Still, replacing the 2018 with the 2020 version in 10-verify.spec.js fails with the error of this issue...

If I add the following to the lib/contexts/index.js at least the issue is resolved for the test:

import ed25519Context2020 from 'ed25519-signature-2020-context';

// ...

contexts[ed25519Context2020.constants.CONTEXT_URL] =
  ed25519Context2020.contexts.get(ed25519Context2020.constants.CONTEXT_URL);

(but the test still fails on some part of the 2020 signature)

[Iskandar1211]

I have such a question, please tell me your library supports json-ld or json-schema validation itself
here is an example

const credential = {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://www.w3.org/2018/credentials/examples/v1",
        "https://www.w3.org/2018/credentials/mycontext",
      ],
      id: "https://example.com/credentials/1872",
      type: ["VerifiableCredential", "AlumniCredential"],
      issuer: "did:example:1234",
      issuanceDate: "2010-01-01T19:23:24Z",
      credentialSubject: {
        id: "did:example:ebfeb1f712ebc6f1c276e12ec21",
        alumniOf: "Apple",
        name: "Bob",
        gender: "Male",
        email: "[email protected]",
      },
    };

      "name": "schema:name",
      "gender": "schema:gender",
      "email": "schema:email",

and if I enter into these fields, for example, a number instead of a string, it will still pass and will not be validated for types, tell me how can I do this

[dmitrizagidulin]

@Iskandar1211 - ah, no, this library won't do schema validating (e.g. a number instead of a string). You'll want to use a separate JSON Schema validator library for that.