How are IPFS links handled?

[ntn-x2]

I was trying to browse through the code but could not find an answer. If a context is linked with an IPFS link, in the form of ipfs://<CID>, is that supported by the app? Or would the link have to be an HTTP link via a browser, e.g., https://ipfs.io/ipfs/<CID>?

[fabianekc]

@ntn-x2 Thanks for trying DID Lint!
Can you provide an example DID Document and the expected behaviour? (note: DID Lint is not a resolver and currently only uses the public Uniresolver service for basic DID resolution)

[ntn-x2]

I just opened a Pull Request to update our driver. The latest version returns an additional context which defines exactly the properties that this tool was marking as missing or mistaken. The IPFS gateway address of the context is https://ipfs.io/ipfs/QmU7QkuTCPz7NmD5bD7Z7mQVz2UsSPaEK58B5sYnjnPRNW, but we only used ipfs://QmU7QkuTCPz7NmD5bD7Z7mQVz2UsSPaEK58B5sYnjnPRNW in the driver result as we want to leave to the resolver the possibility to use whatever gateway they want. So I was wondering if this would still result in an error from DIDLint when trying to resolve that link to fetch the additional context definition.

[ntn-x2]

I guess I got my answer. Our PR was merged, but the error has not gone away, despite the fact that the new terms have been defined in the IPFS-addressed context.
Example DID: did:kilt:light:014pqDzaWi3w7TzYzGnQDyrasK6UnyNnW6JQvWRrq6r8HzNNGy

[fabianekc]

Pasting the resulting DID Document from did:kilt:light:014pqDzaWi3w7TzYzGnQDyrasK6UnyNnW6JQvWRrq6r8HzNNGy into JSON-LD Playground also generates an error: link

However, using the following context, it can be parsed nicely:

"@context": [
    "https://www.w3.org/ns/did/v1",
    "https://ipfs.io/ipfs/QmU7QkuTCPz7NmD5bD7Z7mQVz2UsSPaEK58B5sYnjnPRNW"
  ]

So this should answer the question on the format in context. Agree?

[ntn-x2]

Indeed, if the IPFS link is replaced with https://ipfs.io/ipfs/QmU7QkuTCPz7NmD5bD7Z7mQVz2UsSPaEK58B5sYnjnPRNW, the expansion works. As far as I have seen, javascript libraries allow to inject a custom documentLoader which must contain a mapping from URI scheme to the logic to resolve it, so in this case consumers would probably inject their own resolution logic for IPFS links, which I assume the JSON-LD playground does not do.

[ntn-x2]

I would say that specifying the URL of the IPFS gateway is making an opinionated and less-decentralised choice. Probably not the right place to discuss about it here, but since more protocols are relying on decentralised storage infrastructure, forcing an HTTP URL in there is a stretch.

[fabianekc]

Do I interpret this correctly that ipfs://QmU7QkuTCPz7NmD5bD7Z7mQVz2UsSPaEK58B5sYnjnPRNW is expanded to a JSON that references again HTTP URLs?

{
  "@context": [
    "https://w3id.org/security/v2",
    {
      "@protected": true,
      "KiltPublishedCredentialCollectionV1": "https://github.com/KILTprotocol/spec-KiltPublishedCredentialCollectionV1",
      "Sr25519VerificationKey2020": "https://github.com/KILTprotocol/spec-kilt-did#sr25519"
    }
  ]
}

In my understanding of https://www.w3.org/TR/did-spec-registries/#verification-method-types the correct @context for did:kilt (under the assumption that "type": "Ed25519VerificationKey2018" is used in a verification relationship) would be

"@context": [
  "https://www.w3.org/ns/did/v1",
  "https://w3id.org/security/suites/ed25519-2018/v1"
]

or alternatively just omit the JSON-LD context all together and use the JSON representation to be compliant with the DID Core Specification.

[ntn-x2]

The point is that one of the main critics to JSON-LD is that it tries to mix data linking with digital signatures, which serve two different purposes. Hence, using only integrity-protected links somehow addresses some of the shortcomings of using HTTP links in a JSON-LD context. Yes, we do have some HTTPs links ourselves, for now, but following your suggestion, the Sr25519VerificationKey2020 would remain undefined.

[fabianekc]

Hi @ntn-x2 , I finally got to include JSON-LD validation based on https://www.npmjs.com/package/jsonld. For did:kilt this leads to a successful validation with the context

"@context": [
    "https://www.w3.org/ns/did/v1",
    "https://ipfs.io/ipfs/QmU7QkuTCPz7NmD5bD7Z7mQVz2UsSPaEK58B5sYnjnPRNW"
]

but ipfs:// is not yet supported as protocol by the jsonld npm package. As soon as it is supported there it will also validate here.