- From: Moses Ma <moses.ma@futurelabconsulting.com>
- Date: Tue, 1 Jan 2019 09:10:03 +1100
- To: Emmanuel Forche <forchee@hastlabs.com>
- Cc: David Chadwick <d.w.chadwick@kent.ac.uk>, Adrian Gropper <agropper@healthurl.com>, W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <af4015bf-9652-4dff-ae04-4ed5311a214d@Moses-iPad-Pro-105>
Anti-coercion functionality is a very interesting feature set. Every bank has an employee manual that includes what to do if they, or a significant other, is kidnapped. Usually, it’s the use of an alternate password that allows any transaction to happen... but closely monitored, while the authorities are alerted. If you’re going to “be your own bank”, it’s going to need a new kind of security. It’s probably too complex to include in v1.0, but it’s definitely worth redteaming and brainstorming something that will support easier rollback for transactions.
In our case, maybe something like a “coercion signal” password could be set up, that could trigger special functionality in the affected system, while alerting authorities to track the device and intercept its location. Then, if a VC from the correct law enforcement agency is included, the transaction could be entirely rolled back or otherwise mitigated. So our goal should not to be to solve the entire problem, but make it possible for systems relying on DIDs to implement potential countermeasures to not only coercion, but ransomware and phishing as well.
Anyway, +1 for Emmanuel!
Moses
-
Moses Ma | FutureLab Consulting Inc
moses.ma@futurelabconsulting.com | moses@ngenven.com
v +1.415.952.7888 (tel:+1.415.952.7888) | m +1.415.568.1068 (tel:+1.415.568.1068) | skype mosesma
>
> On Jan 1, 2019 at 5:33 AM, <Emmanuel Forche (mailto:forchee@hastlabs.com)> 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 Monday, 31 December 2018 22:10:41 UTC