Re: Ideas about DID explanation

On 25/12/2018 13:34, Adrian Gropper wrote:
> Non-repudiation depends on chain-of-custody, which is technology, as
> well as process. The interpretation may be up to courts but if the tech
> or process don't take chain of custody into account the court can't do
> much about it.
> 
> Different DID Methods will be more or less susceptible to repudiation
> and I hope our spec makes it easy for inspectors and courts to decide
> which methods are good enough.

Technology does not take coercion into account. If someone forces me to
undertake a transaction, that I subsequently repudiate, the technology
may very well have a solid chain-of-custody in its logs, but the log has
no knowledge about the coercion, or what date it occurred. This is why I
said that ultimately non-repudiation is a legal issue. Technology is
necessary but not sufficient (faulty technology will of course make
non-repudiation impossible to achieve).

Happy New Year

David

> 
> Adrian
> 
> On Tue, Dec 25, 2018 at 8:08 AM David Chadwick <D.W.Chadwick@kent.ac.uk
> <mailto:D.W.Chadwick@kent.ac.uk>> wrote:
> 
>     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>
>     > <mailto: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
>     >
> 
> 
> 
> -- 
> 
> Adrian Gropper MD
> 
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: https://patientprivacyrights.org/donate-3/

Received on Monday, 31 December 2018 13:44:22 UTC