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: Timothy Holborn <timothy.holborn@gmail.com>
Date: Wed, 8 May 2019 04:43:18 +1000
Message-ID: <CAM1Sok0qNxTLBsqYiH84o_gKe5QGNTTE5EKDezv-ANJnuh26Bg@mail.gmail.com>
To: Brent Zundel <brent.zundel@evernym.com>
Cc: Carlos Bruguera <carlos@selfkey.org>, Daniel Hardman <daniel.hardman@evernym.com>, David Chadwick <D.W.Chadwick@kent.ac.uk>, "=Drummond Reed" <drummond.reed@evernym.com>, Credentials Community Group <public-credentials@w3.org>
Why not multimodal?

Or did I miss that part of the functional spec, being discussed...?

There are use cases where tracking the use of a verifiable claim is as
important as the claim itself, for various reasons, including protection
from scope-creep.

Noting also, I am.firmly of the view that solid interoperability is
essential.

Timo.

On Wed., 8 May 2019, 4:18 am Brent Zundel, <brent.zundel@evernym.com> wrote:

> Carlos,
>
> The problem is not that issuers must be trusted (they must). The problem
> with the business model is that it is predatory. It allows the worst abuses
> of surveillance capitalism to continue, under the guise of self-sovereign
> identity.
> As I see it, once a credential has been issued it is not the issuer's
> business how I use that credential. Let's say I have been issued a
> credential asserting my national citizenship (such as a passport), then use
> my credential to prove my address so that I can join a local gardening
> club. Is it the passport issuer's business that I like gardening? Let's say
> my bank issues me a credential asserting my account information, then I
> use that credential to set up automatic donations to my church. Is it the
> bank's business which church I attend?
> A credential revocation scheme that requires the issuer be contacted in
> order to verify the current revocation status of the credential allows the
> issuer to track every use of that credential.
> Revocation schemes such as Sovrin's do not require the issuer to be
> contacted to check the revocation status of the credential. They also do
> not require public revocation lists. They allow for proofs on
> non-revocation that reveal nothing other than whether a credential has been
> revoked.
>
> On Sun, May 5, 2019 at 8:35 PM Carlos Bruguera <carlos@selfkey.org> wrote:
>
>> 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 Tuesday, 7 May 2019 18:43:54 UTC

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