Removing HolderID from Presentations

[David-Chadwick]

In PR #313 @jandrieu said

Also, the only holder ID in a presentation should be implicit in the proof section. Otherwise we create a privacy leak which undermines the ability for a presentation's authenticity to be a matter of a zkp proof weight revealing a correlatable identifier.

I think there was consensus at TPAC to remove the ID altogether from presentations for this reason. (I had pushed for them earlier but was convinced it creates a privacy problem.)

I must have missed this at TPAC. This decision raises several issues for me

1. If ZKPs support selective disclosure then why must the holderID in a presentation be disclosed (if the SubjectID of a claim need not be disclosed)
2. If the verifier needs to know who the holder is and can determine this from the proof, then why does displaying it in the holderID property create a privacy problem
3. If the verifier does not need to know who the holder is, then how does the verifier know the difference between a holder who legitimately got the VC from the subject or the issuer, or stole it from the subject's wallet?

[brentzundel]

The problem, from the Sovrin/Indy anonymous credentials perspective, is that the value of the holderID property in a presentation should never be the same as the subjectID in the credential.
In our ecosystem, the holder has a different DID for each relationship. Let's call these DIDi for the DID the holder has with the issuer, and DIDv for the DID the holder has with the verifier. Putting DIDi in the subjectID and revealing it to the verifier as the HolderID would allow the verifier and issuer to collude.
Instead of relying on verification of knowledge of a DID private key to prove the holder is the one to whom the credential was issued, we rely on verification of knowledge of a private link secret, which only the holder should possess (just as in other scenarios only the holder should possess the DID private key).
I hope this clarifies things.

[jandrieu]

@David-Chadwick Brent hits on the nub of it. If the subject ID in a credential becomes the holder id in a presentation--presumable because that is the mechanism for authenticating that subject==holder, then you have created, as @nage likes to say, a super cookie, which directly enables correlation wherever that VC is used.

But where I think there was consensus was that some notion of "holder id" is superfluous in the light of the proof in the presentation. Even without the holder ID attribute, a non-ZKP method can always check the creator/signer attribute in the proof section with the subject id in the credential. In a simple signature scheme (no ZKP), this gives you everything you need without a holder ID. Because the public key value in the signature is in effect the holder id. By removing the redundant attribute, it allows for anti-correlation approaches like Sovrin's to work as well.

To your questions:

• If ZKPs support selective disclosure then why must the holderID in a presentation be disclosed (if the SubjectID of a claim need not be disclosed)

If it is in the presentation, it is disclosed. That's why there was agreement to remove it. The only way to ZKP it is if there isn't a required holder ID field.

• If the verifier needs to know who the holder is and can determine this from the proof, then why does displaying it in the holderID property create a privacy problem

Because there are proofs that use directed identifiers, pair-wise unique to the verifier, which are distinct from the subject ID in the credential. @brentzundel walked you through that.

• If the verifier does not need to know who the holder is, then how does the verifier know the difference between a holder who legitimately got the VC from the subject or the issuer, or stole it from the subject's wallet?

Using any of a number of factors. The preferred way for most in this community is to rely on the cryptographic proof. A ZKP proof can just as surely demonstrate that the holder has the cryptographic material to claim the credential as if you use straight public/private key cryptography with the public key as the subject ID and in the presentation signature (or redundantly as the holder ID).

Personally, I expect that for high value transactions like opening a bank account, buying a home, getting a passport, etc., "strong authentication" in the form of crypto challenges will only be one component. Others will need to be used, which will, in effect, limit the ZKP applicability in those cases. However, if we don't support ZKP and selective disclosure, then EVERY authentication is forced to use strongly correlatable identifiers, thus allowing a scope to surveillance that is simply untenable in a free society.

[David-Chadwick]

@brentzundel . I think ZKP is a special case and initially wont be the most common use of VCs, although this might change in the longer term. So lets deal with the non-ZKP case first. Ideally there should be different pairwise identifiers between the subject and the issuer and subject and verifier (cf FIDO) and neither should know the other one's pairwise ID. But this is impossible if the verifier needs to know that the subject is the holder and the holder has not stolen the subject's VC. So the verifier and issuer have to share some sort of common ID. The IETF token binding is one way of sharing a unique ID between them. This could be used for both the subject ID and holder ID in the VC and presentation. @jandrieu This is not a supercookie if different IDs are used for different verifiers. It is only a globally unique correlating handle if the subject uses the same ID with all verifiers (and I do not think anyone is suggesting that).

I do not believe you can stop correlation between the issuer and verifier in the non-ZKP case for other than bearer VCs. But this correlation would have to be initiated by the verifier since it knows who the issuer is, but not who the other way around. Please correct me if I am wrong as I would like a solution to this.

@jandrieu The proof does not contain a creator signer attribute but rather comprises

"proof": {
    "type": "RsaSignature2018",
    "created": "2018-06-18T21:19:10Z",
    "verificationMethod": "https://example.com/jdoe/keys/1",
    "nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
    "signatureValue": "BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+
      MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wps
      PRdW+gGsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed
      +W3JT24="
  }

So I do not see in general how the above can be linked to the subject ID (bearing in mind that subject IDs do not have to be DIDs, but only URLs). So how do you link some random URL to some random public key that the holder can prove is theirs?

@jandrieu To cut a long story short, the holder ID in the presentation seems to be essential in some non-ZKP implementations, so we should make the field optional so that it can be omitted in the ZKP case if they know they do not need it. But where other proof implementations do need it, they can use it.

[brentzundel]

I think you've hit on one of the primary reasons ZKP is so vital.

…

On Fri, Feb 8, 2019 at 9:43 AM David Chadwick ***@***.***> wrote: @brentzundel <https://github.com/brentzundel> . I think ZKP is a special case and initially wont be the most common use of VCs, although this might change in the longer term. So lets deal with the non-ZKP case first. Ideally there should be different pairwise identifiers between the subject and the issuer and subject and verifier (cf FIDO) and neither should know the other one's pairwise ID. But this is impossible if the verifier needs to know that the subject is the holder and the holder has not stolen the subject's VC. So the verifier and issuer have to share some sort of common ID. The IETF token binding is one way of sharing a unique ID between them. This could be used for both the subject ID and holder ID in the VC and presentation. @jandrieu <https://github.com/jandrieu> This is not a supercookie if different IDs are used for different verifiers. It is only a globally unique correlating handle if the subject uses the same ID with all verifiers (and I do not think anyone is suggesting that). I do not believe you can stop correlation between the issuer and verifier in the non-ZKP case for other than bearer VCs. But this correlation would have to be initiated by the verifier since it knows who the issuer is, but not who the other way around. Please correct me if I am wrong as I would like a solution to this. @jandrieu <https://github.com/jandrieu> The proof does not contain a creator signer attribute but rather comprises "proof": { "type": "RsaSignature2018", "created": "2018-06-18T21:19:10Z", "verificationMethod": "https://example.com/jdoe/keys/1", "nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e", "signatureValue": "BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+ MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wps PRdW+gGsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed +W3JT24=" } So I do not see in general how the above can be linked to the subject ID (bearing in mind that subject IDs do not have to be DIDs, but only URLs). So how do you link some random URL to some random public key that the holder can prove is theirs? @jandrieu <https://github.com/jandrieu> To cut a long story short, the holder ID in the presentation seems to be essential in some non-ZKP implementations, so we should make the field optional so that it can be omitted in the ZKP case if they know they do not need it. But where other proof implementations do need it, they can use it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#419 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ5VPzYqdOuB8lrs40y2D6seJRHeTJX3ks5vLaktgaJpZM4agQ9L> .

[jandrieu]

I'm actually surprised there isn't a creator value in the proof. How do we know who made the signature? Are we to assume the verificationMethod provides all the information needed?

[dlongley]

I'm actually surprised there isn't a creator value in the proof. How do we know who made the signature? Are we to assume the verificationMethod provides all the information needed?

Dereferencing the verificationMethod provides that information (the controller of the key is presumed to have created the signature). You have to do that anyway to confirm control over the key (or you have to have a local trusted copy of the verification method).

[David-Chadwick]

@dlongley "Dereferencing the verificationMethod" seems to be a fundamentally flawed design to me. Given that a verifier can expect to receive presentations from thousands (possibly millions) of holders it is unreasonable to expect that the verifier has to make an external call for each one before it can verify who the holder is. In the world of PKI a verifier, once it is configured with roots of trust, can receive certificates from millions of holders and can verify them all without needing to make any external calls (revocation aside). The way to avoid this is to include a means of identifying the holder in either the presentation or the proof, without requiring an external verification call to be made.

[David-Chadwick]

@dlongley P.S. verificationMethod would seem to be a misnomer, since to me a method implies something that is generic and can be used multiple times by multiple holders. If this is something specific to a single holder, wouldn't a name of signerIdentification or something similar be more appropriate?

[dlongley]

@David-Chadwick, I think there's too much to say here about how verificationMethod works and why it's named that way given that it is largely unrelated to this spec. It is related to the DID spec and the LD proofs specifications, so this is the wrong place to discuss it.

The only point here was to indicate that you can know who the controller of the key that created a signature was by derefencing the verification method (or by having the verification method be registered with the verifier or use a root of trust or so on).

[David-Chadwick]

@dlongley Respectfully I disagree with your assertion that this is "largely unrelated to this spec". It seems to me that is fundamental to this spec if we are proposing to use a proof scheme that requires the verifier to make an outgoing call before it can verify an incoming presentation.

[dlongley]

@David-Chadwick, it's not required.

[jandrieu]

Actually, at least one outgoing call is required for the revocation mechanisms I'm familiar with. Seems like that concern is a moot @David-Chadwick (unless you running on a machine with a full node of that particular DLT)

[David-Chadwick]

@jandrieu Revocation is a separate issue, and even then, verifiers do not have to make a call out each time they receive a presentation with VCs. For example, they might have a recent cached copy of a combined revocation list and this may be sufficient for their risk exposure. But the current spec demands the veriifer makes an outgoing call for each presentation from a previously unseen holder, and this is a signficant design flaw in my opinion.

[brentzundel]

It seems to me, that whether or not a call out by the verifier is necessary will depend on the verification method used. The data model does not prescribe a verification method.

…

On Wed, Feb 13, 2019, 16:48 David Chadwick ***@***.***> wrote: @jandrieu <https://github.com/jandrieu> Revocation is a separate issue, and even then, verifiers do not have to make a call out each time they receive a presentation with VCs. For example, they might have a recent cached copy of a combined revocation list and this may be sufficient for their risk exposure. But the current spec demands the veriifer makes an outgoing call for each presentation from a previously unseen holder, and this is a signficant design flaw in my opinion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#419 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ5VPzIoNCXo-I93acGx7uA-xuxtzKl0ks5vNKRYgaJpZM4agQ9L> .

[David-Chadwick]

@brentzundel Can you tell me which of the Proof fields tells the verifier which public key to use to verify the signature. Thanks.

[brentzundel]

The data model doesn't formally specify any proof fields (unless I missed something).
Sovrin was planning on having a proof section with the following values:

• Issuer data (revocation index, etc. that will be signed)
• attributes (credential properties that are to be signed, encoded as integers)
• credential definition (which would provide a URI for the verifier to look up the public keys, as well as the mapping the issuer used to encode the credential properties as integers)
• signature
• proof of signature correctness.
  There may also be a type and context for the proof section.

[David-Chadwick]

@brentzundel . You are correct. Only the Proof property itself is mandatory, and not the actual fields. But the current text is somewhat misleading as it provides an exemplar of a Proof property that I took to be the standard way of providing digital signature proofs, and to which all my comments above have been addressed. I therefore think we need to clarify the text to say something like

"No proof mechanism is currently standardised or recommended for verifiable credentials. In the example below we are using the proof mechanism specified in [ref]"

[David-Chadwick]

We should also add the following text "All Proofs MUST contain a type property"

It would then also be beneficial to have a register of Proof types, along with their specifications.

[brentzundel]

@David-Chadwick I've added a PR #423 that I believe addresses your concerns about the proof section.

[David-Chadwick]

Yes this issue has now been addressed in PR #423 so it can be closed

[brentzundel]

Decision from F2F Barcelona:

• @msporny will verify with @dlongley that this can be closed.

[msporny]

@msporny will verify with @dlongley that this can be closed.

I checked, he said we may still need it in the future, but we can always add it later. Digital Bazaar has no strong use cases that absolutely require the field. Based on this, and that there have been no other implementer that wanted the field, we're closing the issue.