How do we know if the subject of the claim is the one making the claim

[TomCJones]

in issue #148 it seems to be that prevention of replay, or determining that the subject is the one making the claim is out of scope. That seems to be in conflict with the introduction which states that the point is to claim our status. Which is the case for the spec?

Driver's licenses are used to claim that we are capable of operating a motor vehicle, university degrees can be used to claim our education status, and government-issued passports enable holders to travel between countries. This specification provides a standard way to express these sorts of claims on the Web in a way that is cryptographically secure, privacy respecting, and automatically verifiable.

[David-Chadwick]

The current specification does support determining that the subject is the one making the claim, and it is within scope. Section 6.7.1 states

The most common case is when the subject is the holder. For example, the verifier can easily deduce that the subject is the holder if the verifiable presentation is digitally signed by the holder and all contained verifiable credentials are about a subject that can be identified to be the same as the holder.

Note that this is independent of the protocol that is used to transfer the verifiable presentation to the verifier, thus it is not a protocol issue (it does not matter what protocol was used to transfer the VP and VCs). It is a data model issue and the data model itself has a way of proving cryptographically that the holder/presenter is the subject. Note also that this is independent of a MITM attack, unless the MITM has access to the subject's private keys.

[jandrieu]

That section of the spec is simply wrong.

The verifier cannot "easily deduce that the subject is the holder". They can establish with one degree of assurance that the creator of the presentation controls the keys associated with the identifier used in both the presentation and the credential.

That is entirely different than "easily deducing that the subject is the holder".

Verifiers will use VCs as input to identity assurance. And the proof-of-control mechanism is a legitimate single factor for authentication. But it does not meet all identity assurance use cases and does not definitively prove the current presenter of a presentation is the subject.

The root problem is that VCs can contribute to identity assurance, but if "verification" depends on identity assurance, then you have a tautological catch-22 where one needs assurance to verify the VCs you are using for assurance. Clearly, this leads to an unresolvable loop.

The first stage is to verify the VC, which is cryptographic and procedural (for revocation). The next step is to evaluate the claims in the context of the issuer, the actual claims asserted, and the consequences of relying on such a VC. [Add other steps based on the context.] Then, the verifier can decide whether or not to "accept" or "reject" a VC for their particular use.

If we aren't rigorous in the first step of verification, the rest of the steps are compromised.

This specification is only dealing with the first step, verification.

[TomCJones]

who gets to decide which interpretation is correct?

[jandrieu]

There's a bunch of discussion over at #298 on essentially the same topic. Hopefully some sort of consensus will emerge.

To my view, the spec for VCs should stop at verification: cryptographic proofs and procedural checks (for revocation).

David is right to point out that users / implementers of VC systems will be using them for identity assurance. Although we're on different sides of the debate, he's not the only one who is going to want to use VCs this way.

My case is that while we can discuss those downstream use cases and potential approaches, conformant implementations should only deal with verification of the credential, independent of the holder and the verifier. Identity assurance is a different level in the stack, which, IMO, will ultimately be better served by clear and rigorous constraints and guarantees of what "verification" means.

[David-Chadwick]

I suggest this issue should be temporarily suspended, since the outcome of the discussion on #298 should resolve this issue.

[TomCJones]

I tried to make sense of that thread before - I must say that it is very hard for me to interpret where this doc is headed, or what use I could make of a VC. It is unclear what statement a VC actually makes and to who. I hope that can be made clear before it is published again.

[msporny]

PR #298 has been merged and we have consensus and closure on at least part of this thread (discussion above).

To be clear, the question was: "How do we know if the subject of the claim is the one making the claim"

The answer to this question is: "If the digital signature of the issuer for the verifiable credential has the same subject identifier as the subject of the credential, you know that the subject of the claim is the one making the claim."

To discover the identifier for the issuer, you look at the digital signature, dereference the creator of the signature (typically a public key), and then see who controls that public key (it will most likely be the issuer). You must also make sure that the issuer claims that the public key in the signature is theirs (to prevent key spoofing attacks). You then check the issuer identifier against the credential subject identifier and if they match, the subject of the claim is the one making the claim.

I'm closing this issue because I believe it is resolved for the specification in question. We still need to do a much better job at elaborating on how this happens, but it's typically only library implementers implementing something other than this specification that need to worry about these details. In other words, maybe we can put something in the implementation guidance, but honestly, even that's a stretch. We do need to put this somewhere, and currently the text resides in the Linked Data Signatures spec (which is horribly out of date and needs a refresh/update): https://w3c-dvcg.github.io/ld-signatures/#signature-verification-algorithm

Closing, re-open if you disagree that this is resolved (for this specification).