Re: Ideas about DID explanation

The observation below is not quite accurate. There are currently
systems that allow for a person to _signal _coercion. Some alarm or
door entry systems are good examples.  To allow for the coercion or
duress to be signaled  you have (usually) two  codes. One for
normal use/behaviour and one for use if under duress/coercion. (In
fact  in some designs the 'duress code'  is unknown to the person
but implemented anyway from behavioural studies of persons in duress
situations). I agree that this is not sufficient but it is one way to
log  (self-declared) coercion. Of course there must be ways, and
legal is one of them,  to establish if coercion did really occur

Happy New Year.
Regards
Emmanuel  

	Hast Labs Limited, Registered in England No 3151102, VAT Reg No
710.7863.40
CONFIDENTIALITY NOTICE This e-mail message and any attachments are
only for the use of the intended recipient(s) and may contain
information that is privileged, confidential or exempt from
disclosure under applicable law. If you are not the intended
recipient, any disclosure, distribution or other use of this e-mail
message or attachments is prohibited. If you have received this
e-mail message in error, please delete and notify the sender
immediately. Thank you.

----- Original Message -----
From: "David Chadwick" 
To:"Adrian Gropper" 
Cc:"W3C Credentials Community Group" 
Sent:Mon, 31 Dec 2018 13:43:54 +0000
Subject: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  > 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
 >  >  > 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/