Bootstrapping Simple WoT Verifiable Claims

[ChristopherA]

I’m puzzling through some simple verifiable claims for bootstrapping some of the basic functions of the classic web of trust (both explicit what actually existed, as well what people falsely believed to be claimed.

The first kind of claim I’d like to build is that did::Alice knows did::Bob.

Knows is part of https://schema.org/Person

The simplest verified claim in Figure 8 of https://opencreds.github.io/vc-data-model/ (less the signature) is:

{
  "@context": [
    "https://w3id.org/identity/v1"
   ],
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "ProofOfAgeCredential"],
  "issuer": "https://dmv.example.gov",
  "issued": "2010-01-01",
  "claim": {
    "id": "did:ebfeb1f712ebc6f1c276e12ec21",
    "ageOver": 21
  }
}

Modifying this for did::Alice and did::Bob and modify this claim for knows:

{
  "@context": [
    "https://w3id.org/identity/v1"
   ],
  "id": "did::Alice#THISCLAIM",
  "type": "Person",
  "issuer": "did::Alice",
  "issued": "2017-01-01",
  "claim": {
    "id": "did::Alice",
    "knows": "did::Bob"
  }
}

QUESTION ONE: So my first question is “id”: “did::alice#THISCLAIM” correct? Or a URL where this claim is stored? If I put this claim anywhere in my DDO, is it just did::Alice? How I can I point to a specific spot in a JSON-LD based DDO where this claim is added?

Now at this point there is no cryptographic proof that Alice knows Bob (and in fact, Alice & Bob are not even human readable names, just DID number). It is just a signed claim:

{
  "@context": [
    "https://w3id.org/identity/v1",
    "https://comakery.github.io/json-ld.org/schemas/security-v1-patch.jsonld"
  ],
  "id": "did::Alice#THISCLAIM",
  "type": "Person",
  "issuer": "did::Alice",
  "issued": "2017-01-01",
  "claim": {
    "id": "did::Alice",
    "knows": "did::Bob"
  },
  "signature": {
    "type": "EcdsaKoblitzSignature2016",
    "created": "2016-12-13T19:24:12Z",
    "creator": "ecdsa-koblitz-pubkey:02c490e19e936efab022bd9fc12833db082706473fd96cec14c4a8dac058a0dbee",
    "signatureValue": "HwMjpgikyk6htrUATmj6r5XXxBFZ/gvaRD9Ti6LNC7YRdluYVX0Tz1fiXFQLtpNNl0umDkINUNf7l+ByH2SloKc="
  }
}

And in fact in the schema, “knows” requires that the relationship be reciprocal, so there needs to be a Bob knows Alice.

QUESTION TWO: How does Bob, having received this claim from Alice, make a new claim that incorporates BOTH claims, making the “knows” reciprocity valid.

QUESTION THREE: How does Alice, having received a double claim (her original, and Bob’s reciprocal claim) incorporate all of them into here DDO’s JSON-LD?

We still have no proofs. We have two claims, that are reciprocal, but we Alice can’t prove that she has validated any keying material from Bob such that she really prove anything — there isn’t even any proof that the Bob she knows had control of the keying material used to sign.

Presumably, Alice can encrypt to Bob’s public key a nonce, which bob decryptst, encrypts, add another nonce, and return (or if using Schnorr sig construction, some type of non-interactive key exchange using ECDH values.) At this point, the claim is more than knows, it is that it has been validated or assessed via some mechanism.

QUESTION FOUR: How is this cross-validation of control of the keys done? There is a nonce available in the signature format, but I’m not sure it makes cryptographic sense here to reveal it publicly in a verified claim. Is this a separate claim from knows, or a validation/assessment of the

Possibly relevant, there is also an AssessAction at http://1.schemaorgae.appspot.com/AssessAction which is part of http://1.schemaorgae.appspot.com/Action — is it is incompatible with Verifiable Claims?

Summary: The most basic web-of-trust function is that anonymous IDs 67889 knows 5679 and that each have validated each others keys securely in some store-and-forward fashion. Solve the above and we have a start to WoT.

Next items after this: A claim that Bob is a natural person. That my nickname for Bob is “Bob”. That my human trust level of Bob’s in a particular trust context has a rating (for instance “I believe that Bob is careful with his keys and careful with his claims). That I consent to accept/read introductions from people that “Bob” knows with one degrees of separation, without Bob’s active participation, or two degrees with. That Bob has ‘eyes on” 2 hours peer reviewing of file x of software build y, under review criteria of “academic” or “security” or “xxxx”.

Once we have a basic draft of some of these, I’d like to circulate this to the larger #RebootingWebOfTrust community that are considering adoption of Verifiable Claims, to the larger WoT community to validate the web-of-trust assumptions.

[msporny]

“did::alice#THISCLAIM”

This should probably be "did::alice#THISCREDENTIAL". Our terminology is effectively:

A Verifiable Claim is a cryptographically protected statement. (e.g. the name on your driver's license)

A Entity Credential is a set of verifiable claims. (e.g. your driver's license)

An Identity Profile is composed of a collection of Entity Credentials. (e.g. the contents of your wallet)

QUESTION ONE: So my first question is “id”: “did::alice#THISCLAIM” correct?

Depends on what "correct" means. The use of any URI is technically correct. The question is whether or not you want to publish additional information at the URI. For example (and ignoring the privacy implications of doing this), to state whether or not the verifiable claim has been revoked.

Or a URL where this claim is stored?

If it's a URL (and if we want to treat it as Linked Data), the expectation is that you should be able to go to that URL and get more information about the credential there. For example, you may have a very small set of Verifiable Claims for a student transcript where the "did::alice#THISCREDENTIAL" points to the complete transcript, but you can only access it if you have the proper login permissions. So, you can tell that the transcript is valid, but you can't get the complete contents of the transcript (all extra verifiable claims) unless you login.

To put it another way, all this information is a graph. The URL helps point to the root of the graph that may expose many more links and nodes in the graph.

If I put this claim anywhere in my DDO, is it just did::Alice?

No, the "credential", which is what you're identifying with "did::alice#THISCREDENTIAL" is the identifier for the credential, not the identifier for Alice.

How I can I point to a specific spot in a JSON-LD based DDO where this claim is added?

Remember that the data structure is a graph, so the question is "How do I point to a particular node in the graph". The easiest way to accomplish this is what you have already done, which is this: "did::alice#THISCREDENTIAL".

So, that means that this is your final markup wrt. DDO

{
  "id": "did::Alice",         // this is a DDO for alice
  ... // other DDO stuff goes here
  "credentials: [{           // these are all of Alice's credentials
    "@context": [ "https://w3id.org/identity/v1" ],
    "id": "did::Alice#CREDENTIAL1",  // this credential lives in the DDO (although, this is not necessary)
    "type": ["Credential", "WoTRelationshipCredential"],
    "claim": {
      "id": "did::Alice",  // Alice is claiming that she knows Bob
      "knows": "did::Bob"
    },
    "signature": {
      "type": "EcdsaKoblitzSignature2016",
      "created": "2016-12-13T19:24:12Z",
      // presumably this is Alice's public key. We may want to change this to did::Alice#key-1
      "creator": "ecdsa-koblitz-pubkey:02c490e19e936efab022bd9fc12833db082706473fd96cec14c4a8dac058a0dbee",
      "signatureValue": "HwMjpgikyk6htrUATmj6r5XXxBFZ/gvaRD9Ti6LNC7YRdluYVX0Tz1fiXFQLtpNNl0umDkINUNf7l+ByH2SloKc="
    }
  }]
}

[msporny]

QUESTION TWO: How does Bob, having received this claim from Alice, make a new claim that incorporates BOTH claims, making the “knows” reciprocity valid.

He can if he wants, or does not have to. It is Bob's choice. If he does want to issue a claim stating that he knows Alice, he does not need to include Alice's claim, he just creates a new claim stating that he knows Alice and publishes it in his DDO. He may also include Alice's claim in his DDO so that someone looking at each claim may see that the reciprocity exists without going to Alice's DDO. An inspector of both claims can see that the "knows" reciprocity is valid.

[msporny]

QUESTION THREE: How does Alice, having received a double claim (her original, and Bob’s reciprocal claim) incorporate all of them into here DDO’s JSON-LD?

She just appends Bob's claim to the end of her 'credentials' property in her DDO.

We still have no proofs. We have two claims, that are reciprocal, but we Alice can’t prove that she has validated any keying material from Bob such that she really prove anything — there isn’t even any proof that the Bob she knows had control of the keying material used to sign.

There are multiple levels of "proof" so, we're going to have to be careful with that word. There is at least one level of proof here - that a signature exists on Alice's claim that she signed that claim with a key that is listed in her DDO. If we want an additional layer of proof, where Alice can prove that she validated the keying material from Bob, that is a separate Verifiable Claim that needs to include the keying material for Alice, Bob, a timestamp, and potentially a signature-countersignature from both Alice and Bob to prove that both of them validated the keying material at the time the "knows" relationship was established. That's a bit of a heavyweight proof, and the group will have to decide how this process is accomplished. Digital Bazaar has played around with this scenario, but found it unnecessary for many of our use cases.

Presumably, Alice can encrypt to Bob’s public key a nonce, which bob decryptst, encrypts, add another nonce, and return (or if using Schnorr sig construction, some type of non-interactive key exchange using ECDH values.) At this point, the claim is more than knows, it is that it has been validated or assessed via some mechanism.

Yes, exactly, and this is why this second level of proof is yet another Verifiable Claim (which could be bundled with the knows relationship). What we may want to do instead is make this a part of a signature suite/protocol. Something like a 2017RsaValidatedSignature where "validated" means that the keying material was validated by both parties and the proof is included in the signature (but not the claim). This is an advanced use case and I suggest we skip it for now wrt. the standard and focus on building it out in the RWoT venue.

[msporny]

QUESTION FOUR: How is this cross-validation of control of the keys done? There is a nonce available in the signature format, but I’m not sure it makes cryptographic sense here to reveal it publicly in a verified claim. Is this a separate claim from knows, or a validation/assessment of the

The nonce is a red herring.

I think the only thing that's required is for Alice and Bob to list each other's keys in the claim and/or signature. That way you have proof that Alice knows Bob, and when Alice made this statement, that one of Bob's keys was X.

Possibly relevant, there is also an AssessAction at http://1.schemaorgae.appspot.com/AssessAction which is part of http://1.schemaorgae.appspot.com/Action — is it is incompatible with Verifiable Claims?

There are /many/ ways to express this information. We just have to pick one and use it. AssessAction may be a bit heavy handed as the only thing you really need for the proof is a single public key. So, this is what Alice's knows credential ends up looking like:

// This credential states that Alice knows Bob, and Bob has a public key X
{
"@context": [ "https://w3id.org/identity/v1" ],
"id": "did::Alice#CREDENTIAL1",  // this credential lives in the DDO (although, this is not necessary)
"type": ["Credential", "WoTRelationshipCredential"],
"claim": {
  "id": "did::Alice",  
  "knows": {
    "id": "did::Bob" // Alice is claiming that she knows Bob
    "publicKey": {
      "type": "EcdsaKoblitzPublicKey",
      // Alice is claiming that Bob's public key  SHA-256 fingerprint is this
      "sha256Fingerprint": "25FE3932D9...8B9316" 
    }
  }
},
"signature": {
  "type": "EcdsaKoblitzSignature2016",
  "created": "2016-12-13T19:24:12Z",
  // presumably this is Alice's public key. We may want to change this to did::Alice#key-1
  "creator": "ecdsa-koblitz-pubkey:02c490e19e936efab022bd9fc12833db082706473fd96cec14c4a8dac058a0dbee",
  "signatureValue": "HwMjpgikyk6htrUATmj6r5XXxBFZ/gvaRD9Ti6LNC7YRdluYVX0Tz1fiXFQLtpNNl0umDkINUNf7l+ByH2SloKc="
}

[burnburn]

Christopher,

Manu has left some excellent and detailed responses to your questions. The only high-level comment I have to add has to do with the general understanding of what Verifiable Claims actually provide. You made the following statement:

"Now at this point there is no cryptographic proof that Alice knows Bob (and in fact, Alice & Bob are not even human readable names, just DID number)."

Based on this statement and a few others by you in this issue, I think it's important to reiterate that VC provides no proof of actual real-world relationships. What it provides is verifiability that one entity has made a claim about a relationship. In your specific example here VC does not try to provide any proof that any human Alice actually knows another human named Bob. Rather, the VC framework allows for proof that some entity (identified by an arbitrary id) has made a claim that an entity Alice represented by a DID knows an entity Bob represented by another DID. It is only this claim that is verifiable, not the truth or falseness of the relationship stated by the claim. For the latter you need to trust that the claim issuer only issues the claim when the relationship is true.

This statement that only the claim is being verified (and not the claimed relationship) applies universally, hence Manu's reply to your Question 4. VC does not provide 'cross-validation of control of keys', with control being the important word here that VC can't prove. It only allows you to verify that a claim was made, but if you include keying information in the claim you are at least assured that that keying information was available at the same time that the claim was made, since verifiability of the claim does (or at least can) include a timestamp for issuance of the claim.

[dlongley]

@burnburn,

Another way to put what VC provides is that it provides cryptographic proof of the authorship of claims.

[dlongley]

The "issuer" property should also be included in the credential examples above, i.e.:

// This credential states that Alice knows Bob, and Bob has a public key X
{
"@context": [ "https://w3id.org/identity/v1" ],
"id": "did::Alice#CREDENTIAL1",  // this credential lives in the DDO (although, this is not necessary)
"type": ["Credential", "WoTRelationshipCredential"],
"issuer": "did::Alice",
"claim": {
  "id": "did::Alice",  
  "knows": {
    "id": "did::Bob" // Alice is claiming that she knows Bob
    "publicKey": {
      "type": "EcdsaKoblitzPublicKey",
      // Alice is claiming that Bob's public key  SHA-256 fingerprint is this
      "sha256Fingerprint": "25FE3932D9...8B9316" 
    }
  }
},
"signature": {
  "type": "EcdsaKoblitzSignature2016",
  "created": "2016-12-13T19:24:12Z",
  // presumably this is Alice's public key. We may want to change this to did::Alice#key-1
  "creator": "ecdsa-koblitz-pubkey:02c490e19e936efab022bd9fc12833db082706473fd96cec14c4a8dac058a0dbee",
  "signatureValue": "HwMjpgikyk6htrUATmj6r5XXxBFZ/gvaRD9Ti6LNC7YRdluYVX0Tz1fiXFQLtpNNl0umDkINUNf7l+ByH2SloKc="
}

[ChristopherA]

Thanks everyone, we are making progress!

[burnburn]

Discussed in 17 Jan 2017 teleconference. (minutes)

[ChristopherA]

So far, the big thing missing is for Bob to give Alice a cryptographic proof that he currently possesses knowledge of the private key that he has give her the public key for. Normally this is proven by Alice giving Bob a random nonce, which he signs.

A) This could be out-of-scope of Verifiable Claims as the proof could be part of a protocol — Alice & Bob could use the external protocol to confirm that Bob currently controls the public key, and Alice just makes her claim that she has done so. In this case, it would be two attributes, that she knows the public key, and has confirmed that bob controls that public key by privately holding the private.

B) It could be integrated into the signature field, which has availability of a nonce. Alice could provide the nonce to Bob as part of her request (again, in an out-of-scope protocol), but Bob puts that nonce into the signature. Advantage (and disadvantage?) of this form is that I'm not sure that anyone else needs to know that the nonce value — it is only valid to Alice from the moment it created as a random number until returned after being signed. As far as I know, having that nonce be pubic is not useful to any other party, and maybe could even be problematic (not sure).

C) The nonce could be part of the claim. Has the same problems with nonce in the signature, but has some slightly greater value in the case of multiple signatures.

Right now I'm thinking more solution A) unless we are throwing around verifiable claims in protocols around as partial objects that are aggregated.

[ChristopherA]

My final object is Alice claiming that she knows Bob's public key, Bob has proved possession of his private key, combined with Bob claiming that he knows Alice's public key and Alice has proved possession of her private key, all in a single object. Along possibly with one more claim that Alice and Bob will act as introducers to others, this become the core Web of Trust object.

[ChristopherA]

Once we have the core Web of Trust object, the next attribute is Alice says that Bob is a Natural person, and Bob says that Alice is a natural person. Separately, there could be another attribute that Alice & Bob are a Unique Natural Persons, i.e. to the best of their knowledge they have signed only one Unique Natural Person attribute to this person they know. This last allows for certain kinds of web of trust polling (be careful, this isn't exactly the same as current forms of voting), where you follow a web of trust 2-3 degrees of Unique Natural Persons around you, and provided everyone was careful, have some measure of confidence in evaluating a poll's results (which someone else in the web of trust will get a different value, which is OK.)

[ChristopherA]

Note again, there are no "True Names" here. All other correlations (Hi, my name is "Alice") can be out-of-band with end-to-end encryption technology, thus privacy correlation can be minimized. It is possible to follow social network meta data in the simplest form, but to a certain extent that correlation is a requirement of the use case, and other correlations should be minimized.

[jandrieu]

Where does terms-of-use meta-data end up? There are currently stated requirements about duration of information sharing, which is, I believe, none of the issuer's business, but rather an assertion by the holder when presenting the claim for inspection.

I don't believe I've seen anything in our draft documents explaining how the recipient/inspector of a claim could verify that the terms of use, such as duration, are somehow specified in a non-repudiable way.

This lack of non-repudiation around meta-data is a gap in addressing issues of data provenance and consent in the use of Verifiable Claims. Maybe that is out of scope, or maybe one way that verifiable claims are presented is by wrapping them in a signed profile that may include meta-data. However, in the current data-model identity profiles don't include meta-data and signatures are optional. (Unless out of scope, we should probably turn this into its own issue to flesh out how terms meta-data such as duration should be handled.)

[dlongley]

@jandrieu,

I don't believe I've seen anything in our draft documents explaining how the recipient/inspector of a claim could verify that the terms of use, such as duration, are somehow specified in a non-repudiable way.

This lack of non-repudiation around meta-data is a gap in addressing issues of data provenance and consent in the use of Verifiable Claims. Maybe that is out of scope...

It's in somewhat of a gray area with respect to scope, IMO. We have this concept but it's part of the experimental credential exchange protocol we've been working with -- which is out of scope.

Maybe that is out of scope, or maybe one way that verifiable claims are presented is by wrapping them in a signed profile that may include meta-data.

Yes, this is how it's done in our experimental protocol. When you share claims, you present an IdentityProfile that contains whatever credentials (and the claims they encapsulate) you want, and you provide your own digital signature on that profile, using a private key associated with the identifier used in the claims. Along with this profile, other meta data may be included, such as the domain where this profile is permitted to be used, for how long, what other conditions must be met, etc.

There has also been discussion around including terms of use in the consumer/inspector's original request for credentials. In other words, when a site/entity desires credentials from a holder, their request would include both the claims they require (or are interested in) and a set of machine readable terms about how they would be used. The holder may agree to these terms, place their signature on them, and send them back in an IdentityProfile to fulfill the request.

As you can see, this is very protocol related -- though, perhaps we can touch on how to model these things in the work without explicitly getting into protocol.