Insight for DID spec: proofs, not keys

[kimdhamilton]

From @kimdhamilton on July 22, 2017 16:46

From @ChristopherA on July 14, 2017 7:31

An insight from the work this week is we should not be talking about owner key, or control key, etc.

Instead, we should be talking about proofs.

For instance, this fragment from a DDO

  {
          "control": 
          [{
              "control-bond": 1.25
              "rotate-proof": [{
                  "proof-type": "pubkeyhash",
                  "bond-value": 1.25
                  "hash-base58check": "mvZ3MyLgsvYr87GGSbsPBWEDduLRptfzEU"
                  }]
            },{
            "revocation-proof": [{
                "bond-value": 1.25
                "proof-type": "pubkeyhash",
                "hash-base58check": "mvZ3MyLgsvYr87GGSbsPBWEDduLRptfzEU"
          }]
        }

It basically says that for control (which permits rotating the owner key and the DDO address) that there are two subtypes, a rotate proof and a revocation proof. In another ddo system the proof-type could be "signature", or even "revocation list".

Similar with owner (which permits updating of the keys allowed to issue claims, and the other content of the DDO, but not the control key or the DDO address), it can be proofs as well which may not just be signatures.

cc: @talltree @msporny @dlongley

Copied from original issue: WebOfTrustInfo/btcr-hackathon-2017#39

Copied from original issue: w3c/vc-data-model#62

[kimdhamilton]

From @ChristopherA on July 14, 2017 22:29

I started this at https://github.com/opencreds/did-spec/issues/4#issuecomment-315449659

I'd like to see a paragraph or so from each of us of top lessons learned, and important links to code, text, or issues contributed to.

[kimdhamilton]

From @msporny on July 17, 2017 0:59

I suggest we start moving a lot of these issues to the DID spec issue repository. @talltree, @dlongley, and I met in DC this past week to go through a revision of the DID spec that Digital Bazaar needs so it can align it w/ our implementation and thinking. I expect this will be an area of focus at the next RWoT.

Specifically, a capabilities based security model for DDOs and what you can do w/ keys associated w/ DIDs.

[kimdhamilton]

From @ChristopherA on July 17, 2017 1:21

Moving these issues is in progress — many of the issues from this hackathon have already been moved there. @kimdhamilton found a useful tool that moves them intact.

[kimdhamilton]

From @talltree on July 17, 2017 5:20

Christopher and Kim,

I'm glad to see these issues move to the DID spec issue repository. Are you
planning for these to start being discussed on the weekly calls, or should
we start planning a dedicated weekly or bi-weekly called on the DID spec.
There is a lot of work to do here and implementations are already underway,
which creates pressure to do it quickly.

Thanks,

=Drummond

On Sun, Jul 16, 2017 at 9:21 PM, Christopher Allen <notifications@github.com

wrote:

Moving these issues is in progress — many of the issues from this
hackathon have already been moved there. @kimdhamilton
https://github.com/kimdhamilton found a useful tool that moves them
intact.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
WebOfTrustInfo/btcr-hackathon-2017#39 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADLkTRPzv5-i1LImiRTdzrqxanrul4Nvks5sOrcXgaJpZM4OX7HS
.

[kimdhamilton]

From @agropper on July 22, 2017 19:17

Sorry, I've lost the thread... Is this an open call tomorrow? Where?

Adrian

On Sat, Jul 22, 2017 at 12:46 PM, Kim (Hamilton) Duffy <
notifications@github.com> wrote:

From @talltree https://github.com/talltree on July 18, 2017 5:0

Kim, thanks. Evernym has a company summit this week so my time on the call
tomorrow will be limited. I'll try to get on the chat and watch for it on
the agenda so I can be sure to join for that segment at least.

=Drummond

On Mon, Jul 17, 2017 at 3:34 PM, Kim (Hamilton) Duffy <
notifications@github.com> wrote:

I'm open to both. Btw, tomorrow we have about 15 minutes that you (and/or
Manu) can spend on DID topics as you see fit. Given the priority of this
spec, I imagine we could carve out a large amount of time for the weekly
meeting on an ongoing basis. As the year proceeds, we could juggle the
weekly meeting focus.

It's possible that even this won't be enough, so we could have either
dedicated recurring or off-by-one meetings as well.

@ChristopherA https://github.com/christophera https://github.com/
christophera what do you think?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
WebOfTrustInfo/btcr-hackathon-2017#39 (comment)
WebOfTrustInfo/btcr-hackathon-2017#39 (comment)
,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADLkTTM7rU_
eap54qVLp3Q9fBp990mVxks5sO7dWgaJpZM4OX7HS
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
w3c/vc-data-model#62 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIeYY2_DUN1ghU9jooe6EqqnLrGMc3oks5sQidggaJpZM4OgOKA
.

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.

[kimdhamilton]

Sorry @agropper -- this was an issue that I ported using an automated tool, and it pulled in some confusing comments. I deleted those. No call tomorrow

[kimdhamilton]

Summary of questions this issue presents

How to update either linked data signature set?

• "Linked data signature" -> "linked data proof"
• Modify library to accept signature field AND proof field

"Proof" is a more general term and "signature" could be a specific type. But proof allows other types of proof; biometric, etc.

How does this affect the taxonomy?

There are concerns about to taxonomy change without more discussion

[msporny]

I suggest that we close this issue at RWoT6 for the following reasons:

1. The JSON-LD signature library now supports 'proofs' and Veres One has done a complete implementation using only proofs and hasn't had any issues.
2. There is a plan to specify both a Linked Data Signature and Linked Data Proof mechanism via spec layering, which I can go over.

Fundamentally, I think we're done with this issue and the only remaining bit is splitting/layering the specs as all the other work has been done.

[msporny]

Just pushed the Linked Data Proofs spec here: https://w3c-dvcg.github.io/ld-proofs/

It's rough, but is now the direction we're going in, many of the implementations are switching over and thus resolves the question that was originally raised in this thread about whether we should be using proofs instead of "signatures and keys". We are now using proofs.

Closing.