W3C home > Mailing lists > Public > public-credentials@w3.org > March 2022

linking issuance and proving (was: Centralization dangers...)

From: Daniel Hardman <daniel.hardman@gmail.com>
Date: Wed, 23 Mar 2022 16:19:10 +0100
Message-ID: <CACU_chmBJLbnkQ=M65CbNkrwTT9_EpT60Hb+UC4Oc15+hLKfrQ@mail.gmail.com>
To: "John, Anil" <anil.john@hq.dhs.gov>
Cc: Credentials Community Group <public-credentials@w3.org>
Anil asked:

>    - Does it make sense to link the provisioning approach (Issuer – to –
>       Wallet) to the presentation approach (Wallet – to – Verifier / RP) or to
>       address them separately?
> I think the answer to this is NO.

It is true that issuance and proving can both be thought of as the transfer
of credentials; this seems to be the basis of the arguments I've heard in
favor of the idea. However:

1. The trust dynamics are exactly backwards. In issuance, an issuer (the
source of the credential) is trying to decide whether to trust the holder
(the recipient) to receive the cred. In proving, the verifier (the
recipient) is trying to decide whether to trust the holder (the source of
the credential) to do the thing the cred qualifies them for. This
difference has profound consequences. [It is true that there should be
proving during an issuance; the prospective holder should prove their bona
fides to the issuer, and vice versa. But these are preparatory to issuance,
not issuance itself.]

2. The threat models are (and should be) different. How you hack an
issuance is quite different from how you commit fraud with a credential as
a prover. And guarding against the threats takes different paths, too.

3. The consent models are (and should be) different.

4. The economic models are (and should be) different. Issuers can (and
often do) charge to issue creds. Verifiers might charge to verify creds
(e.g., in an application process), but holders rarely charge a verifier for
a presentation.

5. The organizational behavior implications are different. Issuance is
usually institution->person. Proving is usually person->institution. IMO
all verification should be peer->peer, but issuance should remain

6. Thinking of proving as a credential transfer omits the whole world of
ZKPs, where presentation is never the transfer of a credential, but rather
the just-in-time generation of a presentation (as opposed to issuance,
which truly *is* a transfer).

Received on Wednesday, 23 March 2022 15:20:34 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:29 UTC