Re: DIDs, proof purposes, and verification methods

I agree that ownership is not the right mental model.

I just wanted to offer a thoughtful post from a lawyer that expands on
Joe's reasoning, in case folks are interested:
https://medium.com/@hackylawyER/do-we-really-want-to-sell-ourselves-the-risks-of-a-property-law-paradigm-for-data-ownership-b217e42edffa

On Tue, Jan 15, 2019 at 11:28 AM Joe Andrieu <joe@legreq.com> wrote:

> On Tue, Jan 15, 2019, at 9:25 AM, Michael Herman (Parallelspace) wrote:
>
> Repeating what I just posted in
> https://github.com/w3c-ccg/did-spec/pull/102#issuecomment-454467222 ...
>
>
>
> When we consider Things (e.g. cars, pets, houses, business documents,
> products, assemblies, parts, etc.) in addition to Actors (e.g. Persons,
> Organizations, Software Agents), how does this influence the choice of
> Owner vs. Controller? ...Things and ownership is an important scenario that
> is not addressed well in the current draft DID spec and the current topic
> of Owners and Controllers is very relevant to rectifying this situation.
>
>
> As I mentioned in my last reply (I won't repeat the links or the arguments
> there), the spec should not talk about ownership at all, especially not
> about proof-of-ownership.
>
> Ownership is a matter of property and property is a matter of law, and as
> such completely out of scope for DIDs.
>
> I can steal your keys and control your DIDs, but that doesn't mean I own
> them. Proof-of-ownership isn't actually proof of ownership. It's a horrible
> misnomer.
>
> The shift to "control" is driven by this simple functional reality: we
> *can* demonstrate proof of control via cryptographic (and therefore
> computational) methods, but we cannot demonstrate proof of ownership
> without either a formal (and accepted) digital title and associated
> processes, or involvement of the courts, both of which are not
> computationally feasible.
>
> We accept that proof-of-control of the appropriate keys establishes
> control over the DID document. (With the minor caveat that we now use
> proofs rather than keys specifically because keys may or may not be
> involved, but it is the easiest way to discuss proof-of-control).
>
>
>
>
> Diagram reference:
> https://hyperonomy.com/2019/01/13/hyperledger-indy-sovrin-comprehensive-architecture-reference-model-arm/
>
>
>
> Best regards,
>
> Michael Herman (Toronto/Calgary/Seattle)
>
>
>
> -----Original Message-----
> From: Dave Longley <dlongley@digitalbazaar.com>
> Sent: December 30, 2018 7:02 PM
> To: W3C Credentials Community Group <public-credentials@w3.org>
> Subject: DIDs, proof purposes, and verification methods
>
>
>
> TL;DR: I think we should:
>
>
>
> 1. Rename "cryptographic suites" to "verification methods".
>
>
>
> 2. Consider a public key a "verification method" rather than needing to
> always wrap them in a "cryptographic suite".
>
>
>
> 3. In Linked Data Proofs, replace "creator" with "verificationMethod"
>
> but support "creator" for backwards compatibility.
>
>
>
> 4. Require a "proofPurpose" for every Linked Data Proof (and I recommend
> the same for other proof schemes). We should also use its value as a
> relation in a DID document to link a DID with an authorized verification
> method for a particular proof purpose.
>
>
>
> 5. Establish "assertionMethod" as a common proof purpose for proofs that
> are used as a method for making an assertion, whether that assertion be in
> a VC or via some social media post/message (where Linked Data Signatures
> are used in concert with ActivityPub/activity streams posts and messages).
>
>
>
> 6. Make the following terms in the DID JSON-LD @context map thusly:
>
>
>
> "authentication" => "<vocab>#authenticationMethod"
>
> "assertionMethod" => "<vocab>#assertionMethod"
>
> "capabilityInvocation" => "<vocab>#capabilityInvocationMethod"
>
> "capabilityDelegation" => "<vocab>#capabilityDelegationMethod"
>
> "contractAgreement" => "<vocab>#contractAgreementMethod"
>
>
>
> (Change "xSuite" => "xMethod").
>
>
>
> ---
>
>
>
> We've spoken in the community before about "cryptographic suites". This
> term, at least within the context of our conversation, was meant to refer
> to some collection of parameters used to verify a (cryptographic) proof.
>
>
>
> I think this terminology is problematic for a few reasons such as
> confusion with existing terms of art and a restriction to cryptographic
> proofs when we have also discussed supporting proofs that do not
> necessarily require the use of cryptography. Implementation experience both
> with DID documents and with digital signature and object capability
> libraries has also led me to believe that we should adopt slightly
> different terminology.
>
>
>
> However, rather than go over all the potential problems, I'd like to just
> introduce slightly different terminology that I believe is more accurate
> and see if there is buy-in from the community. I believe much of the
> narrative I provide below and the new terminology already fits in with
> Linked Data Proofs and the DID document model we have. This means that
> there would be very few changes needed (summarized above).
>
>
>
> So, to lay out the case for the terminology I think we should adopt, I
> will mention some of the basic ecosystem requirements we're trying to
> fulfill in a decentralized and interoperable manner. Then I'll talk through
> a concrete example using that terminology.
>
>
>
> We would like to enable entities to:
>
>
>
> 1. Make statements that can be shared without loss of trust because their
> authorship can be verified by a third party (e.g. VCs, social media posts,
> so on).
>
>
>
> 2. Authenticate as the controller of some DID to some domain.
>
>
>
> 3. Delegate capabilities to others that only they can invoke; delegation
> can be verified by another party.
>
>
>
> 4. Invoke capabilities where the invocation can be verified by another
> party.
>
>
>
> 5. Agree to contracts where the agreement can be verified by another party.
>
>
>
> There is a common generic thread for each of these requirements:
>
> Entities need a method by which they can demonstrate a specific intent
> that can be independently verified.
>
>
>
> I believe this description can be understood as a "proof". I think we can
> further unpack this to assign terminology to the attributes of a "proof"
> that are necessary to give them utility:
>
>
>
> 1. "type": The specific type of proof, for example, an
> "Ed25519Signature2018" type indicates that the proof includes a digital
> signature produced by an ed25519 cryptographic key (amongst other things).
>
>
>
> 2. "proof purpose": The reason why an entity created a proof, i.e. they
> were using the proof as a method for declaring what *specific* intent?
>
>
>
> 3. "verification method": A set of parameters required to independently
> verify the proof. This would include the type of verification method and,
> for example, public key material.
>
>
>
> 4. "proof value" or other proof-specific attributes: These would include
> any attributes that are specific to the type of proof, such as "jws", for a
> cryptographic proof that uses the JWS specification.
>
>
>
> The necessity of a proof type and value seem relatively straightforward.
>
>
>
> A proof that describes its purpose helps prevent it from being misused for
> some other purpose. This is something that has been missing from earlier
> revisions of Linked Data Signatures that we've started to support -- and I
> recommend every Linked Data Proof (and other proof
>
> methods) has one of these.
>
>
>
> A proof that links to its verification method enables discovery of that
> method (and its associated parameters) -- but a verifier must be able to
> determine that the entity authorized the use of that verification method
> for its used purpose.
>
>
>
> This last bit means that a verifier must not only confirm that the proof
> was created by someone who controls the verification method but that the
> verification method was authorized by that controller to be used for the
> proof's purpose. This approach has advantages, such as encouraging entities
> to separate their verification methods into categories for specific use,
> thereby reducing ambient authority.
>
>
>
> So, a verification method should indicate who its "controller" is, i.e.
>
> the entity that controls the method and uses it for some purpose. We
> already intend to use this terminology to replace "owner" via a PR here:
>
>
>
> https://github.com/w3c-ccg/did-spec/pull/102
>
>
>
> This isn't enough of course, as a verification method description can
> declare anything; we also need the description of the "controller"
>
> itself to declare that the verification method at hand has been authorized
> for the intended proof purpose. We have already structured our DID
> documents this way -- and that may be more obvious via a concrete example.
>
>
>
> Let's use "authentication" as the reason that an entity has created a
> proof, i.e. its "proof purpose". In other words:
>
>
>
> Suppose an entity "did:example:123" has created a proof for the purpose of
> "authentication" that can be verified via the method
>
> "did:example:123#some-key":
>
>
>
> ```
>
> {
>
>   /* some document the proof is attached to */
>
>   ...,
>
>   "proof": {
>
>     "type": "Ed25519Signature2018",
>
>     "verificationMethod": "did:example:123#some-key",
>
>     "proofPurpose": "authentication",
>
>     "jws": "3242343..234234234d3232"
>
>   }
>
> }
>
> ```
>
>
>
> Here this "proof" looks just like a typical Linked Data Signature proof,
> except that it has a specific "proofPurpose" of "authentication" and that
> the field "creator" is replaced with "verificationMethod". I think using
> this new terminology instead of "creator" would help alleviate some
> confusion. Wrt to Linked Data Signatures, I recommend we always include a
> "proofPurpose" and use the "verificationMethod" term going forward (but
> support "creator" for backwards compatibility). In any case, a verifier
> should dereference the verification method to get its
>
> description:
>
>
>
> ```
>
> {
>
>   "id": "did:example:123#some-key",
>
>   "type": "Ed25519VerificationKey2018",
>
>   "controller": "did:example:123",
>
>   "publicKeyBase58": "z2847623...423"
>
> }
>
> ```
>
>
>
> Note: We can see from this that an instance of a
> "Ed25519VerificationKey2018" (a public key description), is a "verification
> method". This eliminates the need for an additional encapsulating
> "cryptographic suite" as we have previously discussed. It also allows us to
> replace the "cryptographic suite" terminology with "verification method". I
> think this terminology is more generic and appropriate for its use. This
> approach supports other verification methods such as some sort of biometric
> template/parameters or a third party service that must be queried.
>
>
>
> From here, a verifier can make sure the verification method is appropriate
> for the type of proof and it can verify the digital signature in the proof.
> Then it can then dereference the "controller" to find a DID document.
> (Note: in the case of DID documents, the common case will be that keys will
> be stored in the DID documents themselves, so the "dereferencing" of the
> controller may actually be merely a check against the `id` of the DID
> document).
>
>
>
> Here is an example DID document for the DID "did:example:123":
>
>
>
> ```
>
> {
>
>   "@context": "https://w3id.org/did/v1",
>
>   "id": "did:example:123",
>
>   "authentication": [{
>
>     "id": "did:example:123#some-key",
>
>     "type": "Ed25519VerificationKey2018",
>
>     "controller": "did:example:123",
>
>     "publicKeyBase58": "z2847623...423"
>
>   }],
>
>   ...
>
> }
>
> ```
>
>
>
> Here we have a relationship between the entity identified by the DID and
> the verification method that can be represented as a triple:
>
>
>
> <did:example:123> <authentication> <did:example:123#some-key>
>
>
>
> This statement is a declaration that the entity uses the public key as an
> authentication method. Given that this statement comes from the entity's
> description itself, it is an authoritative statement authorizing the use of
> that key as a verification method for proofs for the purpose of
> authentication.
>
>
>
> This ties everything together -- and it works for all of the above more
> specific requirements:
>
>
>
> A proof created to prove that "entity E asserted something" has a proof
> purpose of "assertionMethod" and E's DID document has a relation of
> "assertionMethod" with the proof's verification method.
>
>
>
> A proof created to prove that "entity E authenticated" has a proof purpose
> of "authentication" and E's DID document has a relation of "authentication"
> with the proof's verification method.
>
>
>
> A proof created to prove that "entity E invoked a capability" has a proof
> purpose of "capabilityInvocation" and E's DID document has a relation of
> "capabilityInvocation" with the proof's verification method.
>
>
>
> A proof created to prove that "entity E delegated a capability" has a
> proof purpose of "capabilityDelegation" and E's DID document has a relation
> of "capabilityDelegation" with the proof's verification method.
>
>
>
> A proof created as a method to prove that "entity E agrees to a contract"
> has a proof purpose of "contractAgreement" and E's DID document has a
> relation of "contractAgreement" with the proof's verification method.
>
>
>
> The changes needed to adopt this new terminology are summarized at the top
> of this email. As an open question to the community, what do you think of
> this direction? If there are no objections to these changes I would move to
> have us make whatever spec and JSON-LD context changes are necessary sooner
> rather than later.
>
>
>
>
>
> --
>
> Dave Longley
>
> CTO
>
> Digital Bazaar, Inc.
>
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>