Safe-mode breaks DID-Core spec

[lemoustachiste]

I'm trying to update JSONLD to the latest version in https://github.com/hellobloom/ssi-sdk/tree/main/packages/ecdsa-secp256k1-signature-2019.

However this test: https://github.com/hellobloom/ssi-sdk/blob/main/packages/ecdsa-secp256k1-signature-2019/src/__tests__/index.test.ts#L319 fails with version 8.2.0 and the following error:

"error": {
        "name": "VerificationError",
        "errors": [
          {
            "name": "jsonld.ValidationError",
            "details": {
              "event": {
                "type": [
                  "JsonLdEvent"
                ],
                "code": "relative @id reference",
                "level": "warning",
                "message": "Relative @id reference found.",
                "details": {
                  "id": "#relative-path",
                  "expandedId": "#relative-path"
                }
              }
            },
            "message": "Safe mode validation error.",
            "stack": "jsonld.ValidationError: Safe mode validation error.\n    at safeEventHandler (/Users/julien/work/ssi-sdk/packages/ecdsa-secp256k1-signature-2019/node_modules/jsonld/lib/events.js:133:11)\n    at _handle (/Users/julien/work/ssi-sdk/packages/ecdsa-secp256k1-signature-2019/node_modules/jsonld/lib/events.js:82:7)\n    at Object.<anonymous>.api.handleEvent (/Users/julien/work/ssi-sdk/packages/ecdsa-secp256k1-signature-2019/node_modules/jsonld/lib/events.js:71:3)\n    at /Users/julien/work/ssi-sdk/packages/ecdsa-secp256k1-signature-2019/node_modules/jsonld/lib/expand.js:593:17\n    at Array.map (<anonymous>)\n    at _expandObject (/Users/julien/work/ssi-sdk/packages/ecdsa-secp256k1-signature-2019/node_modules/jsonld/lib/expand.js:557:25)\n    at processTicksAndRejections (node:internal/process/task_queues:96:5)\n    at Object.<anonymous>.api.expand (/Users/julien/work/ssi-sdk/packages/ecdsa-secp256k1-signature-2019/node_modules/jsonld/lib/expand.js:254:3)\n    at Object.<anonymous>.api.expand (/Users/julien/work/ssi-sdk/packages/ecdsa-secp256k1-signature-2019/node_modules/jsonld/lib/expand.js:128:15)\n    at _expandObject (/Users/julien/work/ssi-sdk/packages/ecdsa-secp256k1-signature-2019/node_modules/jsonld/lib/expand.js:926:25)"

This is the fixture DID document: https://github.com/hellobloom/ssi-sdk/blob/main/packages/ecdsa-secp256k1-signature-2019/src/__tests__/__fixtures__/didDocument.json

As per the DID spec: https://www.w3.org/TR/did-core/#relative-did-urls, relative ids are valid references in a DID document.

Also see this conversation from last year: decentralized-identity/ion#285 (comment)

[lemoustachiste]

Maybe leaving the choice in jsonld-signatures to use or not safe mode when using the API?

[dlongley]

So safe mode should not be disabled, and it's helpful here as it has pointed out that some values in that document would not be signed in the generated proof.

Instead, if you want those values signed, they should ideally be absolute URLs. Short of that, the base URI option passed to the JSON-LD processor could be set to the DID (the value of id in the DID document) in order to use relative URLs. This will ensure that they are expanded to absolute URLs when the canonicalized value to be signed is generated.

To maximize interoperability, the base URI should generally be set to null when signing documents (and this will be specified as the default behavior for data integrity / LD proofs), but an implementation could allow it to be set to some other value. The verifier will need to know to set this value as well in order to verify the proof. This might not be too hard a thing to specify for DID documents of a particular DID method, but it may not generalize well.

Note: Relative URLs have a habit of creating trouble (read: vulnerabilities) for people and their use is sometimes discouraged on this basis. That doesn't mean relative URLs aren't legal in DID documents (as you noted), it just means some trouble can be avoided by not using that particular feature.

[lemoustachiste]

Hi @dlongley,

I'm back at it and I'm not sure I do understand entirely this:

To maximize interoperability, the base URI should generally be set to null

When I set to null for verification, then I've got the same error as first described. If I do use a URI then no issue.

Does that mean that if I sign the document with the @base: null value, then the verifier will be able to understand the relative value? My hunch at this point (I didn't confirm it) is that by having @base as null, it ignores it the same way as if it were undefined (falsy value basically).

[dlongley]

@lemoustachiste,

I'm back at it and I'm not sure I do understand entirely this:

To maximize interoperability, the base URI should generally be set to null

When I set to null for verification, then I've got the same error as first described. If I do use a URI then no issue.

My point was that a verifier will not know what base URL to use -- and should always be using null. That means that if your VC doesn't verify with null, then it's not going to be interoperable. Make sure it verifies with null.

Does that mean that if I sign the document with the @base: null value, then the verifier will be able to understand the relative value? My hunch at this point (I didn't confirm it) is that by having @base as null, it ignores it the same way as if it were undefined (falsy value basically).

You don't have to put @base: null into the context, you should be able to pass that into your signature library / JSON-LD processor as a flag. That's the default flag in some implementations, IIRC. But, no, it does not mean that the verifier will be able to understand the relative value -- they never will understand it. Again, this is my point -- the verifier won't know what the URL is meant to be relative to, so don't use a relative URL. You would have to communicate the base URL out of band to the verifier -- it's not an easily interoperable solution, certainly not for open world interop anyway.