Re: Digital Press Passes and Decentralized Public Key Infrastructures

Hi David,

My points about biometrics were not rare cases. They refer to broad uses in
the analog past and likely to continue in the digital future. This is not a
problem for our data models because the VC and DID data models do not
specify the nature of the attributes. It is a potential problem for
protocols.

Your second point about the Issuer’s rights to protect themselves and their
business are being discussed in a parallel thread where I provide examples
from US Federal regulatory practice (HIPAA) and the related work in UMA 2
informally called the “Adrian Clause”.
https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0216.html

- Adrian

On Tue, Jul 27, 2021 at 5:14 AM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

> Good points Adrian.
>
> However I have read at least one research paper describing how onion
> routing can be broken and senders can be linked to recipients. So I suggest
> that eliminating all risks from surveillance may be out of our scope (or
> even impossible to attain).
>
> Furthermore if issuers provide warranties on the VCs they issue, they will
> need to know all the verifiers that might wish to make a claim from them.
> So whilst issuers should not be able to prevent holders from presenting
> their VCs to any verifier, issuers will wish to exert some control over
> which verifiers they are liable to, and in some cases "to protect the users
> from themselves" issuers may wish to control who the holders may present
> their VCs to. I am not advocating this, but I know that it has been
> suggested in some use cases.
>
> Kind regards
>
> David
> On 26/07/2021 16:59, Adrian Gropper wrote:
>
> The "problem", such as it is, has more to do with biometrics than DLTs.
> Legacy (analog) credentials are a combination of biometric subject
> attributes and forgery prevention. That enables a majority of use-cases to
> avoid "calling home". The validity and linked attributes of a legacy
> credential are only verified in a small fraction of their uses (police
> stops, larger bank transactions).
>
> DLTs (and related revocation dead-drops) are just a means of verification
> without calling home in a manner that allows surveillance. They are part of
> the forgery prevention and revocation solution. But without a biometric in
> the VC, directly or indirectly through the assumption that a biometric was
> involved "out-of-band", the misuse of valid credentials is a huge problem.
>
> Avoiding biometrics in the VC through "chain-of-custody" protocols
> requires jurisdiction over the holder, lest the holder transfer a valid VC
> to another subject. Chain of custody methods effectively treat every
> subject as a potential criminal - pre-crime style - and will not be
> acceptable in most use-cases.
>
> - Adrian
>
> On Mon, Jul 26, 2021 at 10:51 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
>> Hi Manu
>>
>> as a footnote can you provide me with a single use case that does not use
>> any centralised registry?
>>
>> Kind regards
>>
>> David
>> On 25/07/2021 15:45, Manu Sporny wrote:
>>
>> On 7/24/21 5:36 PM, David Chadwick wrote:
>>
>> Our SSI implementation does not use any blockchain, so maybe this is your
>> problem. Blockchain is a ball and chain around SSI.
>>
>> A controversial statement if there ever was one. :)
>>
>> Have you considered that you might not have hit a use case that benefits from
>> the use of a DLT... but others have?
>>
>> That's not to say that there aren't use cases that don't require a DLT --
>> because there absolutely are -- and we all recognized that when creating the
>> Verifiable Credentials standard (which is why it doesn't mandate the use of
>> DIDs). However, the argument that there aren't use cases that benefit from a
>> DLT and that people that think that is a problem is... dubious.
>>
>> I'll just leave you with some hard data:
>>
>> There are now 103 registered DID Methods[1].
>>
>> There are 47 implementations that were submitted to the DID Test Suite for
>> conformance testing[2].
>>
>> The vast majority of those implementations are DLT-based[2].
>>
>> It could be that most of the 47 DID Method implementations we have are
>> horribly misguided and wrong... but I certainly wouldn't bet against all of
>> those people. :)
>>
>> -- manu
>>
>> [1]https://lists.w3.org/Archives/Public/public-did-wg/2021Jul/0025.html
>> [2]https://w3c.github.io/did-spec-registries/#did-methods
>>
>>