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

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
institution->person.

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).

>