W3C home > Mailing lists > Public > public-credentials@w3.org > July 2021

Re: Digital Press Passes and Decentralized Public Key Infrastructures

From: Adrian Gropper <agropper@healthurl.com>
Date: Tue, 27 Jul 2021 07:09:40 -0400
Message-ID: <CANYRo8i+pRpPk1XvcOOqL8ckYnS3q+S8UdayLD=Tij0x27NDMQ@mail.gmail.com>
To: David Chadwick <d.w.chadwick@verifiablecredentials.info>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
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
>>
>>
Received on Tuesday, 27 July 2021 11:10:04 UTC

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