Need a way to specify multi-factor key/proof relationships

[msporny]

@csuwilcat wrote:

I would like to see DID Documents support the notion of keys/proofs being reliant on a combination of keys/proofs to be valid. Some attestations and auth requirements are what I would call 'mission critical', for example:

Say a government adopts decentralized identity systems, and integrates it into their court system. There may be many things that take just one signature from one key linked to the court entity to be authoritative, but some attestations may be so sensitive, with such a severe impact, that the court entity would want to put extra measures in place to up the ante on what it takes to be a valid attestation.

One such case: criminal conviction proofs.

In this case, a court entity may want to exclude any chance that a criminal conviction data object is ever created/signed with just a single key. They may want to specify that a set of three keys are reliant factors that must all sign something for it to be valid.

To do this, we could add a property on key descriptors that allowed the specification of another key in the owning entity's DID Document (or an external key ref, e.g. another DID's keys) that must be included for the key's use to be valid.

Pseudo code:

  {
    "id": "did:example:fooCountyCourt#keys-1",
    "type": "RsaCryptographicKey",
    "owner": "did:example:fooCountyCourt",
    "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n",
    "factors": [{
         "id": "did:example:fooCountyCourt#keys-2",
         "requirement": "sig"
       },
       {
         "id": "did:example:courtClerkOne#keys-3",
         "requirement": "sig"
       },
       {
         "id": "did:example:courtClerkTwo#keys-1",
         "requirement": "sig"
       }
     ]
  }

[ChristopherA]

Another application specific factor approach could be a smart signature script rather than defining the multisig in JSON. This allows for more kinds of factors, such as non-accountable threshold secrets, timelocks, AND OR operands, etc.

Please see my comment elsewhere (I’ll look for it and append later) to not limit yourself to only accountable multisig like the above. A threshold signature allows the multisig to be confirmed as valid but not reveal (or correlate) which signers did the signing, which in addition to supporting privacy also is needed in multisig scenarios where coercion or threats to signers are possible.

— Christopher Allen

[msporny]

This exists now, and is probably a better place to discuss this issue than this repo: https://docs.google.com/presentation/d/13jaeireCRFoI1jFPFkbwBhTMQgUG7zEHRjmq0PWz-CI/edit#slide=id.p

That is, this feature has to do with a specific cryptosuite, not the more generalized VC Data Integrity specification.

I'm closing this issue so that it can be pursued in more specific specs and cryptosuites (as the one described above).

Please re-open if you disagree.