decentralized-identity / ion

The Identity Overlay Network (ION) is a DID Method implementation using the Sidetree protocol atop Bitcoin
https://identity.foundation/ion
Apache License 2.0
1.23k stars 173 forks source link

ID format for verificationMethod keys inconsistent with other implementations #285

Closed lemoustachiste closed 2 years ago

lemoustachiste commented 2 years ago

I was trying to verify a document with a did ION and I have noticed something that feels like an inconsistency. I have looked empirically at the examples there and the norm seems to format the id of the key as [controller]#[key-id].

Furthermore, jsonld-signatures seems to also expect that format?

The did-core spec mentions here: https://www.w3.org/TR/did-core/#verification-method-properties for id: A string that conforms to the rules in 3.2 DID URL Syntax. From this it looks like it should conform to: https://www.w3.org/TR/did-core/#fragment, where examples seem to highlight the above point.

OR13 commented 2 years ago

Absolute DID URL: [controller]#[key-id]

Relative DID URL: #[key-id]

Both will work with Verifiable Credentials, but you will likely be "adding" components to make things resolvable... for example

jwt.header.kid = [controller]#[key-id] vc.proof.verificationMethod = [controller]#[key-id]

Given this ^, ION implementers are at risk of forgetting to do this, and then experience relative vs absolute bugs.

peacekeeper commented 2 years ago

[controller]#[key-id]

The base URI is the DID document's subject (the id), not the controller.

See also https://www.w3.org/TR/did-core/#relative-did-urls.

OR13 commented 2 years ago

@peacekeeper you are correct.... however when looking at the verificationMethod these will be the same in 99.9% of the use cases... for example:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "id": "did:key:zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv",
  "verificationMethod": [
    {
      "id": "did:key:zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv#zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv",
      "type": "JsonWebKey2020",
      "controller": "did:key:zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "J2_IqdXNxEeCLxb1qhTpSRdXHZzct72SRl4TnEJ-R_8",
        "y": "TtUKrbOpvK1kyp1OaePCG8dTBBrWXF8DbA8xfuf3wn4"
      }
    }
  ],
  "assertionMethod": [
    "did:key:zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv#zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv"
  ],
  "authentication": [
    "did:key:zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv#zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv"
  ],
  "capabilityInvocation": [
    "did:key:zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv#zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv"
  ],
  "capabilityDelegation": [
    "did:key:zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv#zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv"
  ],
  "keyAgreement": [
    "did:key:zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv#zDnaeT5uorMRdrixgbBjyFSd8YU1ToLV3EMwRQ7E4okgPsMSv"
  ]
}

notice that didDocument.id === didDocument.verificationMethod[0].controller...

But to emphasize again what @peacekeeper has said...

jwt.header.kid = [didDocument.id]#[key-id] vc.proof.verificationMethod = [didDocument.id]#[key-id]

lemoustachiste commented 2 years ago

Indeed the controller is not the same as the baseUrl, sorry the shortcut, but as @OR13 pointed they are often the same so that's where the confusion came from.

So I understand that we can have both absolute and relative path. I will prepare the code accordingly then. I had it for one case and realized we often had absolute paths so checking examples and spec it seemed to me we were always expecting absolute paths.