Clarification of other verification methods in authentication section missing

[awoie]

The spec allows other verification methods than public keys:

The value of the authentication property SHOULD be an array of verification methods.

Furthermore ...

Each verification method MAY be embedded or referenced. An example of a verification method is a public key (see Section § 5.3 Public Keys ).

We should clarify the extension mechanism for other verification methods:

• will there be a registry?
• will there be a type?
• can you give an example of another verification method?
• ...

[dlongley]

Authentication is not a "verification method", but a purpose for which a proof may be created. A DID Document expresses authorized verification methods for specific proof purposes, such as authentication. So the DID Document contains properties that are proof purposes with values that are verification methods (e.g., specific public key instances). For example:

{
  "@context": "...",
  "id": "did:example:123",
  "authentication": [ /* list of public keys that are authorized by 'did:example:123' for creating proofs for the purpose of authentication */],
  "capabilityInvocation": [ /* list of public keys that are authorized by 'did:example:123' for creating proofs for the purpose of capability invocation */],
  "assertionMethod": [ /* list of public keys that are authorized by 'did:example:123' for creating proofs for the purpose as a method of assertion (think VCs) */],
  "..."
}

We should be able to crib from this email to create some text to better explain this in the spec:

https://lists.w3.org/Archives/Public/public-credentials/2018Dec/0108.html

[awoie]

@dlongley According to the current spec text, my assumption was that the authentication section could use other entries than public keys as well. Some of them might not even relate to keys in the publicKey section. Would you agree with that? If this is the case, we should define rules how these can be represented.

[dlongley]

@awoie,

According to the current spec text, my assumption was that the authentication section could use other entries than public keys as well. Some of them might not even relate to keys in the publicKey section. Would you agree with that?

Yes.

If this is the case, we should define rules how these can be represented.

At a minimum we should certainly give examples, discuss extensibility, and perhaps informally link to other specs.

[awoie]

@dlongley I thought that this might be a way to represent the ethereumAddress and other "things" that don't encode actual public keys. Then, we won't have to deal with that in the publicKey section. Do you think that this is a viable approach?

[awoie]

@dlongley @selfissued Currently, some of the features specified in the DID spec only apply to public keys, not to "verification methods". E.g., if we consider ethereumAddress as a "verification method", we have to find a way to represent revocation info for "verification methods" as well. This is because the underlying key of the ethereumAddress could get lost and the "verification method" has to be revoked.

Furthermore, I could imagine that people want to refer to "verification methods" from other parts of the DID Document as well in the same way as people refer to public keys in the authentication section .

IMO, we should have renamed the publicKey section in "verification-methods" but I understand that this cannot be done for backward compatibility reasons. Could a compromise be having a dedicated section for "verification-methods" that list entries that don't fit into the publicKey section? What would be a good compromise?

[dhh1128]

I am going to add several of my own questions about verification methods here. I considered putting these questions in a separate issue, but decided to start by including them in this existing issue where they seem approximately relevant. Let me know if you'd prefer to have me create separate issues for these.

1. In the example given above by @dlongley about the proof purpose named assertionMethod, it is not clear to me whether the purpose is to generate presentations from credentials where the DID subject is the holder, or to issue credentials where the DID subject is the issuer. Assuming the answer is not "both", what would be the name of the other proof purpose?

2. Verification methods appear to be imagined as concrete--that is, we define methods by providing specific key values that will be used. An alternative would be to make them abstract, and then do a mapping. An example of this approach, for a DID belonging to Acme Corp and controlled by its board of directors, would be:

verification method = 3 keys from members of the board keys for member of the board = A, B, C, D, E

The second statement doesn't have any representation in our current DID doc model. However, if we had it, its advantage would be that I can change which keys are members of the board without changing the general principle embodied by the verification method.

This advantage is not particularly compelling when all the examples that are given are of a single key, and when we only provide an expansion of 1 or 2 proof purposes. However, when we begin providing examples of multisig and threshold sigs, with a rich set of proof purposes, it may be much cleaner to be abstract. Repeating concrete key values (or even references to concrete keys) in multiple verification methods makes for bigger docs, filled with largely redundant info, and for bigger diffs across routine changes.

I bring this idea up here because it fits with @awole's suggestion about a dedicated section for verification methods.

3. It seems to me that having top-level sections of the doc dedicated to proof purposes is not as clean as having top-level sections of the doc dedicated to verification methods. Compare:

proof purpose 1:
    method A

proof purpose 2:
    method A again

proof purpose 3:
    method A again

versus

method A
    proof purpose 1
    proof purpose 2
    proof purpose 3

Of course, I am making an assumption here, which is that the same method will often be used for more than one purpose. To the extent that this is unlikely, the greater cleanliness of the second approach degrades. But I do think it is likely--especially in the common and degenerate case serviced by did:key, where a single key is used to do "all the things" that matter in that ephemeral interaction.

[dmitrizagidulin]

Partially addressed by PR https://github.com/w3c/did-core/pull/123 (which adds the definition of "verification method" and related terms).

Remaining action items (from @msporny's comment):

• Create a registry listing the initial set of verification methods that we intend to standardize
• Give at least one example of a verification method that is not a public key

Related or duplicate issues:

• https://github.com/w3c/did-core/issues/172
• https://github.com/w3c/did-core/issues/193
• https://github.com/w3c/did-core/issues/190

[msporny]

We still need to define some of this stuff in the DID Core Registry and someone needs to add an example for Ethereum Address as a verification method.

[kdenhartog]

I'm curious if we're trying to address any other verification method other than an ethereumAddress as well? I think our method of DID Core Registries could handle this once we get all of that work defined.

[peacekeeper]

Just as a thought experiment, could a hashed password be a verification method? E.g.:

{
  "@context": "https://www.w3.org/2019/did/v1",
  "id": "did:example:123",
  "authentication": [{
    "id": "did:example:123#authn-1",
    "type": "HashedPassword2020",
    "value": "08792a045d60e71f2696fcd32166da4fbad3b43fbc5ff6f8aee82fb0a9f7e477"
  }],
}

The proof that can be verified with this verification method is the plain-text password.

Yes I know, it's horrible. It can be brute-forced, it can be correlated, a verifier can impersonate me, etc.

But semantically, I think this example would be compliant with the concept of a "verification method"? And perhaps even useful in some very rare and narrow use cases?

[kdenhartog]

Just as a thought experiment, could a hashed password be a verification method? E.g.:

{
  "@context": "https://www.w3.org/2019/did/v1",
  "id": "did:example:123",
  "authentication": [{
    "id": "did:example:123#authn-1",
    "type": "HashedPassword2020",
    "value": "08792a045d60e71f2696fcd32166da4fbad3b43fbc5ff6f8aee82fb0a9f7e477"
  }],
}

The proof that can be verified with this verification method is the plain-text password.

Yes I know, it's horrible. It can be brute-forced, it can be correlated, a verifier can impersonate me, etc.

But semantically, I think this example would be compliant with the concept of a "verification method"? And perhaps even useful in some very rare and narrow use cases?

Oh dang... this is somewhat related to my content identifiers discussion too, but I think you're correct. There's actually a bit of a safe way to do this too I think. It still relies on the strength of the password unfortunately, but improves the longevity through the use of a ratchet scheme (as long as the password isn't bruteforced at some point which is made easier if the registry returns the previous state of DID Documents because you're not aiming at a moving target).

Imagine I did this:

 {
   "@context": "https://www.w3.org/2019/did/v1",
   "id": "did:example:123",
   "authentication": [{
     "id": "did:example:123#authn-1",
     "type": "HashedPassword2020",
     "previousValue": "08792a045d60e71f2696fcd32166da4fbad3b43fbc5ff6f8aee82fb0a9f7e477",
     "value": "2f8b91e1a5526821eb38472d406704f5833969d0ad8458e6df306cee718f7c08",
     "ratchet": 100,
   }],
 }

Then I could produce a password based verification method such that I produce a stacked hash scheme e.g. Hash(Hash(password||ratchet - 1)+Hash(previous value)) => current value

Then after revealing Hash(password||ratchet -1) to the verifier, I need to update the DID Document with the next iteration of the hash and previous value.

This means that I could reveal to the verifier the ability to produce Hash(password||ratchet) and they could verify the value without ever revealing the password. There's plenty of implementation details that would have to be built around to make this practical, but in theory I think the answer is yes, you could build a verification method just off passwords that could work.

[msporny]

Just as a thought experiment, could a hashed password be a verification method?

Yes, exactly @peacekeeper. To make your example a little less scary, you could include a salt as a parameter to avoid rainbow table attacks... but even then, we'd probably never suggest something like that in a DID Document (but might in some kind of encrypted channel between a small set of entities).

@kdenhartog -- it's not opening up a can of worms, this was always the design foundation of verification methods. Thinking only in terms of pubic/private keys is limiting, which is why we opened up the Linked Data Security stuff to other cryptographic mechanisms many, many years ago.

Another fun thought experiment... anyone that expends the energy to generate a correct proof of work can authenticate:

{
  "@context": "https://www.w3.org/2019/did/v1",
  "id": "did:example:123",
  "authentication": [{
    "id": "did:example:123#authn-1",
    "type": "ProofOfWork2020",
    "nonce": "z7fFj3kPq",
    "targetHash": "0000000000001f2696fcd32166da4fbad3b43fbc5ff6f8aee82fb0a9f7e477",
  }],
}

... but I admit, the above example is a neat technical feature in search of a use case.

That said, we did want to make sure we didn't just limit things to only public/private key crypto in the Linked Data Security stack.

[kdenhartog]

Good to know. I could actually see this (the ability to use non-pki cryptographic verification methods) being used as a practical mechanism on an IoT device with did:peer that's got storage capacity, but not necessarily the computation to manage PKI to securely interact with an IoT Hub.

[peacekeeper]

I could imagine that in the future we will see many more innovative "verification methods", even ones where the open-world data model of RDF, and permissionless extensibility of DID documents become really valuable. Something based on social graphs, where e.g. a proof of control of DID would be established through a set of trusted parties. For example the DID document could contain a verification method that says "my two neighbors can confirm that this is my DID" or something like that.

@ChristopherA 's work on Smarter Signatures is probably also relevant here and could be a basis for advanced verification methods in DID documents.

[rhiaro]

I'd like to suggest closing this issue as 'overtaken by events'. Work on the registries, text in PR #304 plus actions in #272 and #268 to define other verification method properties should cover the discussion here and original issue.

[brentzundel]

Marked pending close for more than a week with no comment, closing.