W3C home > Mailing lists > Public > public-credentials@w3.org > May 2019

Re: Trust in Issuers (was: Materials from 2019-04-11 combined DID Spec and DID Resolution Spec meeting)

From: Carlos Bruguera <carlos@selfkey.org>
Date: Mon, 6 May 2019 09:33:49 +0700
Message-ID: <CAJrRL-GLiGzjzR7+JSGfdcvxa7q_sjCZ_fdt2jvcHDq54TfqOQ@mail.gmail.com>
To: Daniel Hardman <daniel.hardman@evernym.com>
Cc: David Chadwick <D.W.Chadwick@kent.ac.uk>, "=Drummond Reed" <drummond.reed@evernym.com>, Credentials Community Group <public-credentials@w3.org>
Why is it a problem that credential issuers establish business models such
as the one described? In what manner does it threat self sovereign
identity? In the end, trusting the issuers is *always* required as far as I
know, and DIDs still allow for other types of credentials not requiring to
rely on these issures... Perhaps I don't fully understand the example. In
what manner do revocation schemes (such as Sovrin's) disallow such use
cases? Also, shouldn't the credential issuers always be able to set
arbitrarily long (or perhaps even null) expiration times?

Regards,
Carlos

On Wed, Apr 17, 2019 at 4:43 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> Agreed.
>
> On Wed, Apr 17, 2019 at 1:58 AM David Chadwick <D.W.Chadwick@kent.ac.uk>
> wrote:
>
>> But this does not stop others from using the back door! The back door
>> should be bricked up.
>>
>> On 16/04/2019 18:52, Daniel Hardman wrote:
>> > Right. This is why Sovrin went down the road of testing revocation with
>> > a cryptographic accumulator instead of a conversation back to the
>> issuer.
>> >
>> > On Tue, Apr 16, 2019 at 2:49 AM David Chadwick <D.W.Chadwick@kent.ac.uk
>> > <mailto:D.W.Chadwick@kent.ac.uk>> wrote:
>> >
>> >     The current FIM
>> >     model places the IdP at the centre of the ecosystem, which is ideal
>> for
>> >     Google tracking users and capturing data. VCs do not do this.
>> >
>> >     However, the current VC data model gives Google a back door for
>> this as
>> >     follows:
>> >
>>
>
Received on Monday, 6 May 2019 02:34:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:49 UTC