W3C home > Mailing lists > Public > public-credentials@w3.org > December 2018

Re: Ideas about DID explanation

From: David Chadwick <D.W.Chadwick@kent.ac.uk>
Date: Tue, 25 Dec 2018 13:06:50 +0000
To: public-credentials@w3.org
Message-ID: <27fd0d80-b7ce-a2bc-7c97-f9371c3d1ecc@kent.ac.uk>
Non repudiation is legal issue, not a technical one. So it does not
really matter if the user chooses the date or not. The courts will
decide the matter

David

On 24/12/2018 22:20, Tom Jones wrote:
> Very bad idea to let the user chose date for breach. That would break
> any possibility of using key for nonrepudiation. It is of no interest of
> the resolver why the key is no longer valid 
> 
> thx ..Tom (mobile)
> 
> On Tue, Dec 11, 2018, 7:00 AM Manu Sporny <msporny@digitalbazaar.com
> <mailto:msporny@digitalbazaar.com> wrote:
> 
>     On 12/11/18 8:43 AM, Lucas Tétreault wrote:
>     > What I'm stuck on right now is keys that have been breached vs. keys
>     >  that were rotated for some other reason?
> 
>     We are exploring the possibility of annotating the reason for the key
>     rotation (expiration, revocation due to loss, etc.)
> 
>     > If a key was breached then presumably any and all credentials that
>     > were signed with it should be revoked. Thoughts?
> 
>     If you can note when the key was breached in the DID Document (or
>     elsewhere) when you revoke it, then you don't need to revoke all
>     credentials that were signed with it.
> 
>     Also note that many high-stakes issuers are most likely going to use
>     HSMs, so if there is a breach, they will only revoke credentials during
>     when they thought their system was vulnerable due to the private keys
>     being difficult/impossible to exfiltrate from their hardware-secured
>     storage.
> 
>     -- manu
> 
>     -- 
>     Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: Veres One Decentralized Identifier Blockchain Launches
>     https://tinyurl.com/veres-one-launches
> 
Received on Tuesday, 25 December 2018 13:07:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 December 2018 13:07:19 UTC