Using /whois for witness proofs

[brianorwhatever]

It feels like the witness approach we've landed on is very similar to the capabilities given by /whois. A witness proof credential of some sort could be the first layer of trust that is found by querying the /whois. A VC could look something like this

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": [
    "VerifiableCredential",
    "DIDWitnessCredential"
  ],
  "issuer": "did:example:issuer",
  "issuanceDate": "2025-01-10T10:08:35.854Z",
  "credentialSubject": {
    "id": "did:webvh:QmXieh6adQphszCoEefqQ3mdtZSeSKRD7t2jovZVeZo29c:example.com?versionId=1-QmS6kFXiSV5QBBTZgd1mU3iRxL5zn8J92pdjGaZRGrUZKA"
  },
  "proof": [
    {
      "type":"DataIntegrityProof",
      "cryptosuite":"eddsa-jcs-2022",
      "verificationMethod":"did:key:z6MkjDjA1N5GGuqD3VM3neWGhUKdNAPCvYo6bbgHqeuaLHRX#z6MkjDjA1N5GGuqD3VM3neWGhUKdNAPCvYo6bbgHqeuaLHRX",
      "created":"2025-01-10T09:03:58Z",
      "proofPurpose":"assertionMethod",
      "proofValue":"zQtw4z9M4vhcssb6jCQZzx9AgTHV4zdeLUpbpfAH1X95khy19N16jggNq4NXHNSWx2QmnRHp5QrfqjKNmkcNZi6w"
    }
  ]
}

[swcurran]

Interesting idea! Once I realized what you meant, I didn’t like it (clogs up the /whois file?) but the more I think about it and type things the more I like it.

I’ll noodle on it and I look forward to others commenting. Super clever idea. :-)

[andrewwhitehead]

I agree it is similar, and I considered this but I'm not comfortable with the extra dependencies.

At the moment, the resolver does not need to do anything with whois. It is strictly for the 'post-resolution' phase of verification, where business rules can be checked as to the trust level of an issuer for example. If we use it for witness verification as well, then the whois file is potentially being checked once by the resolver and then again in this additional verification phase.

In terms of dependencies, this also puts a hard dependence on the Linked-VP specification which is currently 'Pre-Draft' as well as the VC data model, and it makes it potentially very difficult to move away from those. It would require periodic updates to the DID method each time the data model is changed. At the moment we depend on Data Integrity to verify the proofs in the witness file, but it would still be possible to support (for example) JWS envelopes in that file instead. And while new DI proof formats may be added in future updates, I don't see this creating as much churn as supporting full-blown VCs (potentially in multiple mututally-incompatible versions).

[brianorwhatever]

Yeah, I understand your concerns with the extra dependencies but keep in mind it only adds that dependency to DIDs that use witnesses. Maybe that doesn't make a difference but something to keep in mind.

I don't think the "have to resolve /whois in resolution now, as well as post-resolution" point because it doesn't really matter - you have to either resolve /whois or the custom did-witness.json. 6 one way half a dozen the other imo.

I think Linked-VP is already a hard dependency as /whois is a mandatory feature? On a related note I realized the only thing this gives us is a mapping of /whois -> /whois.vp and the ability to move the file to the controllers desired location. If we remove the implicit #whois service they could still choose the location using the #files service. We would have to be ok with it being /whois.vp though which is probably undesirable..