Re: Ideas about DID explanation

Hi Emmanuel

I stand corrected. You are right to say that there are certain
specialised technologies that allow coercion to be signalled. I was
thinking about X.509 systems in general when I made my comment, and I
was not aware of any of these that allowed coercion to be signalled. So
it would be excellent if some sort of coercion notification could be
built into DIDs as an advanced feature.

David

On 31/12/2018 18:33, Emmanuel Forche wrote:
> 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" <D.W.Chadwick@kent.ac.uk>
> 
>     To:
>     "Adrian Gropper" <agropper@healthurl.com>
>     Cc:
>     "W3C Credentials Community Group" <public-credentials@w3.org>
>     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
>     <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 Tuesday, 1 January 2019 11:09:59 UTC