Re: Ideas about DID explanation

The entire concept of block chain is the creation of technically
non-redpudiable transactions to avoid double spending. Any structure that
would add ambiguity to the the clear purpose of the block chain should
(IMHO) be avoided.
Peace ..tom


On Tue, Dec 25, 2018 at 5:36 AM Adrian Gropper <agropper@healthurl.com>
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.
>
> Adrian
>
> On Tue, Dec 25, 2018 at 8:08 AM David Chadwick <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> 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/
>