Re: DIDs, proof purposes, and verification methods

Yes, Michael, exactly right, so that's why we felt the term "Identity
Owner" was appropriate at the Sovrin Governance Framework level while not
being appropriate at the DID tech level. (BTW, I am the one responsible for
introducing it into the original DID spec, so mea culpa).

On Tue, Jan 15, 2019 at 9:11 PM Michael Herman (Parallelspace) <
mwherman@parallelspace.net> wrote:

> Hi Drummond, based on my reading of the Sovrin Glossary entry for Identity
> Owner, I believe it defines an Identity Owner to have a fairly high level
> of *legal* *accountability*?  I’ve *underlined* the relevant sentence and
> *bolded* the relevant phrase.
>
>
>
> *Identity Owner*
>
> A classification of a Sovrin Entity as either an Individual or an
> Organization. Mutually exclusive with Thing. *Identity Owners are the
> only type of Sovrin Entity that may be held legally accountable, however
> the actual legal accountability of an Identity Owner for any particular
> action depends on many contextual factors including the laws of the
> applicable Jurisdiction, Guardianship, and so forth*. An Identity Owner
> may play any of the Sovrin Infrastructure Roles.
>
>
>
>
>
> *From:* =Drummond Reed <drummond.reed@evernym.com>
> *Sent:* January 15, 2019 5:07 PM
> *To:* Michael Herman (Parallelspace) <mwherman@parallelspace.net>
> *Cc:* Joe Andrieu <joe@legreq.com>; public-credentials@w3.org
> *Subject:* Re: DIDs, proof purposes, and verification methods
>
>
>
> I am also +1 to only using "controller" rather than ownership in the DID
> spec as it operates at a purely technical level. I'll note the exception
> that proves the rule: in the Sovrin Glossary
> <https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit?usp=sharing>
> we do define the term "Identity Owner" but we do so precisely because
> the Sovrin Governance Framework extends the concept of self-sovereign
> identity to the legal rights of the individual to exert this control, and
> the closest legal analog to this form of control is ownership. Note that we
> do NOT say that the Identity Owner "owns" their credentials, only that they
> control the holding and presentation of their credentials.
>
>
>
> On Tue, Jan 15, 2019 at 12:24 PM Michael Herman (Parallelspace) <
> mwherman@parallelspace.net> wrote:
>
> Thank you Joe, Controller +1 …for all Somethings: Actors and Things.
>
>
>
> *From:* Joe Andrieu <joe@legreq.com>
> *Sent:* January 15, 2019 11:27 AM
> *To:* public-credentials@w3.org
> *Subject:* Re: DIDs, proof purposes, and verification methods
>
>
>
> 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>
>
>
>
>
>
>