> On Oct 14, 2022, at 9:50 AM, Richard Barnes <[email protected]> wrote:
> The verifier of a VC needs to know that the entity presenting the credential
> is the same as the subject that the issuer issued the credential to. Can you
> provide an example of how the verifier is assured of that without revealing a
> public key or a DID or some constant, correlatable identifier? Specifically:
>
> 1. What is in the VC payload that is presented to the verifier?
> 2. How does the verifier process that payload to verify the above property?
For a single-use unlinkable SD-JWT or JWP (using traditional cryptography), you
could identify the user by proof of possession of the private key associated
with an ephemeral key embedded into the message. In JWT terms with an OAuth
issuance endpoint, this would be a “cnf” claim holding a JWK, based on an
ephemeral public key provided by the client when they hit the issuance
protected resource. The single-use property is something enforced by the
holder’s agent as part of their own knowledge control - they can use a
credential multiple times without impact on security, but that could lead to
potential correlation between parties or in multiple interactions with the same
party.
For a multi-use unlinkable JWP, one way in CL02 signatures would be to provide
proof of knowledge of any non-disclosed values. This could include a shared
secret with the issuer, but also can be sent as a blinded value (sometimes
referred to as a link secret) such that even the issuer does not know the value
of that particular attribute. This second form is sometimes used to have a
common secret across all credentials held by the holder software, which allows
for some additional proofs of linking across credentials from different
issuers. Hopefully Brent doesn’t mind me linking to a document he wrote on this
technique for a different container format, AnonCreds, at
https://www.evernym.com/blog/how-does-a-verifier-know-the-credential-is-yours/
A concrete VC payload showing such does not exist yet, as it is expected to be
created under the Verifiable Credentials working group. I should be able to
give an example of what the presented data could look like to a verifier for
JWP for the first case based on one of the current proposals, if desired.
> For example, in the case where the subject is identified by a concrete key,
> (1) is a "did:key" or some other concrete representation of the subject
> public key, and (2) is verifying that the presentation demonstrates
> possession of the corresponding private key.
One could use a did:key as the mechanism to release the ephemeral key above
hypothetically.
You would be correct in that the ongoing "distributed public key
infrastructure” aspects aspired to by the decentralized identifier
specification are not commonly combined with these techniques. This is because
having presentations rely on the release of a persistent identifier for an
entity will provide not just a correlation of that entity, but a
cryptographically verifiable one.
Instead, I imagine a DID would more typically be an attribute within the
credential itself; something that could be released conditionally, and where
control of the DID could be cryptographically proven separately.
> As an aside: It's not clear to me why a verifier would want to know that a
> signature exists if they can't tell something about the signer. Rather than
> "some unspecified person made a signature over this payload", it seems like
> would at least want to know "an entity with X properties made a
> signature...". Where X would be something like "corresponding to a DID" or
> "authorized within some system". Otherwise the signature has no meaning!
For a traditional verifiable credential, having the subject identified with a
DID serves two purposes - it provides a correlation handle for information
about that subject (which is not always desired) and provides a reference to
how to cryptographically prove someone is that subject.
However, the issuer can supply other ways to do that cryptographic proof, such
as via a link secret above. That would show that it was an entity that the
issuing authority verified as their intended subject.
You see similar divisions in privacypass-based systems – the origin determining
access to some service does not know concrete identities, but rather that the
issuer asserted access was appropriate.
I would say that is a personal goal of mine with multi-use-unlinkable JWPs as
credentials - that if you ratchet information disclosure all the way down to
nothing, it only is a presented proof asserting of a relationship with the
issuer at some point. Everything the verifier requires beyond that is knowledge
that can be released by user consent, including the further information the
verifier would want to know about the party who provided the proof.
-DW
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
