W3C home > Mailing lists > Public > public-credentials@w3.org > June 2017

[MINUTES] W3C Credentials CG Call - 2017-06-20 12pm ET

From: <msporny@digitalbazaar.com>
Date: Tue, 20 Jun 2017 15:33:03 -0400
Message-Id: <1497987183311.0.19790@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Dave Longley for scribing this week! The minutes
for this week's Credentials CG telecon are now available:


Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

Credentials CG Telecon Minutes for 2017-06-20

  1. Bitcoin DID Method (BTCR)
  2. Chainpoint v3.0
  3. Linked Data Signatures
  Kim Hamilton Duffy and Christopher Allen
  Dave Longley
  Dave Longley, Kim Hamilton Duffy, Glen Rempe, Ryan Grant, 
  Christopher Allen, Frederico Sportini, Moses Ma, David Chadwick, 
  Glen Braun, Manu Sporny, Joe Andrieu, David I. Lehn, Sean Bohan, 
  Nathan George

Dave Longley is scribing.
Kimhd goes over the agenda
Kim Hamilton Duffy:  I'm going to talk to some of the signatures 
  suites to give an overview of what's in those suites. Manu isn't 
  able to make it today but Dave Longley may be able to fill in for 
  some questions while that's happening.
Glen Rempe:  I'm the vice president of Engineering with Tierion
Kim Hamilton Duffy:  We're talking about having a remote 
  hackathon in July, 2nd or 3rd week. Ryan and Christopher and I 
  are interested in getting some code and more detailed specs out 
  related to that.
Kim Hamilton Duffy:  Next week we'll have Jan Camenisch 
  presenting on selective disclosure, CL signatures, etc.
Kim Hamilton Duffy:  We haven't had much time to discuss those 
  work items much so far, looking forward for that.
Kim Hamilton Duffy:  We're getting a lot of responses on the poll 
  -- decentralized IDs is in the lead, lots of interest there. VC 
  related items getting interest. Privacy and security requirements 
  doing well. Data minimization and selective disclosure.... we'll 
  be snapshotting these results next week and going ahead with 
  identifying which work items to start on first.
Kim Hamilton Duffy:  Let's jump into the work items.

Topic: Bitcoin DID Method (BTCR)

Kim Hamilton Duffy:  Ryan?
Ryan Grant:  I'm talking about BTCR method specific 
  implementation of distributed identity. This falls under the DID 
  spec format.
Christopher Allen: Did:btcr:tx-5678-678-6789-678
Ryan Grant:  It's a way to control an identity and prove that you 
  control it using the bitcoin blockchain.
Ryan Grant:  Basically, we have a spec to follow under the DID 
  master spec and our task is to define how an identity is 
  controlled and changed using entries on the bitcoin blockchain 
  and tie that to a DDO (a description of what the identity is).
Christopher Allen: Did(decentralized identitier):btcr(bitcoin 
  refererence):tx-kddk...(a bech32 encoded transaction ID)
Ryan Grant: 
Ryan Grant:  And then get that implemented in some software. 
  That's what we'll be working on at the hackathon and that's what 
  the topic is. What's done is that we have a clear spec to meet 
  with the DID spec, we have an implementation plan that we 
  outlined at the latest RWoT conference in the Spring.
Ryan Grant:  Summary page in IRC.
Ryan Grant:  Dead link in there that needs to be fixed.
Ryan Grant:  We have a clear outline of the work we need to do 
  and fleshing out that doc into a draft spec. What we're aiming 
  for going forward is in October, Boston conference we'd like to 
  have a draft spec and operating software. Couple of questions we 
  need to answer about whether we're using two transactions or one 
  transaction with a special OP code in the bitcoin scripting 
Christopher Allen: The October conference is 
Ryan Grant:  We'd like to make some progress on that at the 
Ryan Grant:  Any questions?
Kim Hamilton Duffy:  About the DDOs, I talked to Christopher 
  briefly, is the assumption that the DDO is stored in IPFS or 
  could be URLs or content at one, or what?
Ryan Grant:  Are we pointing to external DDOs? (DID description 
  object). The DID record is a pointer to the information that you 
  want to present for your identity and you can change that at any 
  time. And that's contained in the DDO. We're going to try and 
  support both. Links out to IPFS as well as a new idea about a 
  fully deterministic DDO that is implied by the set of 
  transactions that have occurred with the DID itself.
Christopher Allen: FedericoSportini Great!
Frederico Sportini:  I would definitely be interested in taking 
  part in the hackathon. We would also like to implement the BTCR 
  ... do our own implementation or write a community one, clients 
  interested. We talked briefly with Christopher at last RWoT and 
  we have a few questions on BTCR and if we could discuss how to 
  solve these issues it would be great for us. Thanks.
Christopher Allen:  Thanks. Basically I'm curious how many other 
  people are interested in this initial thing, bitcoin based DID 
  system. We want to see more people taking advantage of the 
  techniques we create with VC and the uses for it. Don't want to 
  use a lot of the CG time for how the different approaches work. 
  We know how to do it in a simple way and another way to make it 
  compatible with Blockstack and IPFS and other uses. Bigger 
  question has more to do with what the DDO looks like. Whether the 
  DDO should be a VC itself.
Christopher Allen:  For some of the simpler uses maybe it should 
  be, but current 1.0 spec just has it as a JSON structure. Harder 
  question is, more specific to bitcoin, to preserve anonymity and 
  to preserve censorship resistance it has been suggested to use a 
  more complex structure that sort of hides the information such 
  that a miner can't recognize "this is somebody trying to register 
  a change in a DID so i'm not putting that in my block" there are 
  ways to hide that add extra complexity and we're not sure if it's 
  worth it or how high that risk is.
Christopher Allen:  If people have opinions on that or a better 
  solution please let us know.
Ryan Grant: Christopher is describing a tradeoff between 
  OP_RETURN and using script hashes
Glen Rempe:  So I would suggest taking a look at our new 
  Chainpoint 3.0 solution which is coming out shortly with a full 
  openstack backend. New proof format for anchoring data to the 
  bitcoin and ethereum blockchains, it would be a good solution for 
  anchoring any data. We use OP_RETURN for anchoring in bitcoin. 
  There has been discussions looking into alternatives that would 
  be more censorship, pay to contract hashes, etc. But no solid 
  implementations to use as a reference yet. Using OP_RETURN is 
  pretty much the name of the game these days.
Christopher Allen: The base of btcr uses op_return, the 
  paytocontracthash has been suggested as being more censorship 
Kim Hamilton Duffy:  That would be perfect, a quick over of the 
  signature suites and talking through Chainpoint 3.0 -- we'd be 
  happy to have you present.
Ryan Grant: Did:btcr:tx1-rjk0-u5ng-4jsf-mc
Ryan Grant: 
Christopher Allen:  I'm familiar with Chainpoint and would love 
  to have you talk more about that. The biggest thing you should 
  maybe be aware of is that we're linking to the TXN through a 
  proposal that links in a different way. It's a much shorter and 
  specifically oriented to have both error correcting and error 
  detecting capability. If your interested in supporting that in 
  Chainpoint that would be fabulous.
Glen Rempe:  I'd be happy to take a look at that.

Topic: Chainpoint v3.0

Glen Rempe:  Chainpoint updates... We have a new version of the 
  proof format Chainproof 3.0. There's a change going on with us 
  which is that it won't just be a proof format that we're hoping 
  people will standardize on. But also what is currently a closed 
  backend stack for verifying. We're creating an entirely new 
  opensource version of that backend stack, available for others to 
  run. We're partnering with some large orgs to run additional 
  copies of this backend stack and they will participate in what 
  we're calling the chainpoint network that will share data through 
  a privace blockchain and you can use any instance to verify a 
  proof against bitcoin or ethereum.
Glen Rempe:  Previously the proof format purely a JSON-LD doc, 
  new is still JSON-LD but we thought its format, highly nestable, 
  extensible. We're including precision timestamps in that proof 
  for the first time. Firstly the NTP time for the servers 
  generating the proof (time proof is submitted), when you submit a 
  hash to us we give you back instantly a V1 UUID which contains 
  the high-precision timestamp and random data. The handle for the 
  proof contains a precision timestamp. To reduce amount of trust 
  required in the timestamp we are incorporating the NIST beacon, a 
  512 random value published every minute by NIST, put together in 
  a hashed list blockchain of those publicly. We're incorporating 
  that value into every proof we generate, which lets you bookend 
  this proof. This lets you say it wasn't submitted prior to a 
  certain time according to NIST.
Glen Rempe:  You can prove the time you submitted the proof was 
  within a window of time, cryptographically. New meta data in 
  there too, timestamps, UUID, ISO8601 format, and providing 
  several tools using JSON schema format for validation.
Glen Rempe:  Lastly, we're also supporting a binary format for 
  this proof, we provide a simple tool where you can use ... 
  applies message pack and compression onto the JSON-LD proof so 
  you have something that's maybe 35% of the original size of the 
  proof. This can be presented in binary form or in base64-encoded 
  binary form. Our API will return it in either format at your 
Glen Rempe:  Those are the big highlights on what's changing and 
  I'm happy to address any questions.
Christopher Allen:  This is actually a joint meeting of the CCG 
  and the Digital Verification CG.
Christopher Allen:  Are you interested in submitting this as a 
  draft for us to work on and move it towards an official standards 
  process at some point?
Glen Rempe:  I know that the Chainpoint format has been going 
  through the community standards process and perhaps we can take 
  that discussion offline with Wayne because he's in a better 
  position to answer.
Christopher Allen:  Can it be used in a fashion so it can be used 
  in a signature block of something else that's being signed in 
  other ways?
Glen Rempe:  Yes, as this is a JSON-LD doc with its own 
  chainpoint type, if that outer document is also JSON-LD with a 
  JSON-LD signature you can also embed this into a larger document 
  and it would be a part of the signature of that overall document.
Christopher Allen:  Thanks.

Topic: Linked Data Signatures

Kim Hamilton Duffy: https://goo.gl/jU9oSS
Kim Hamilton Duffy:  Presenting Linked Data Signatures. What's 
  the intent and scope for each signature suite in the work item 
  list? This is not deep technical detail review, but getting 
  people on the same page for what's involved.
Kim Hamilton Duffy:  On slide 2. RSA Signature Suite 2017. We 
  worked on this at the last RWoT. We had a little hackathon. 
  People working on implementing this suite to vet it out. It 
  worked out. Now the idea is to take it forward. What did we do 
  during RWoT? We took the draft community report and said "Is this 
  complete enough to implement?"
Kim Hamilton Duffy:  As a new signature suite to add to the LD 
  signature suites.
Kim Hamilton Duffy:  It would allow us to verify JSON and linked 
  data signatures. There had been concerns with JWS -- a lot of it 
  around needing to base64 encode the contents. Also related to 
  ending up with a message that cannot be stored in a JSON document 
  store without decoding it and losing the signature, etc. We used 
  the unencoded payloads open for JWS a relatively new feature.
Kim Hamilton Duffy:  It uses a combination of unencoded and 
  attached payloads and get the signature value in that way. A lot 
  of details in the RWoT paper at the end. The big surprise was 
  that there was very limited support in the JWS libraries for this 
  unencoded payload option. So we took the PHP library and figured 
  out what was going on there, built test cases there, and built 
  the equivalent in Python, JavaScript, Java. Worked out fine in 
  the end. We want to address a couple of things with folks in the 
  JWS community. Should we add these as extensions to their 
  libraries? Don't want to include as a hacky thing. If this 
  feature is available, then it's very straightforward. Usage is 
  just like other LD signature suites.
Kim Hamilton Duffy:  Concerns around managing additional binary 
  things we need to carry along, base64 encoding, etc. addresses 
Kim Hamilton Duffy:  We should add clarifications to the 
  specification, Manu had all of one day to write it up, we can 
  enhance that with things discovered during implementation.
Kim Hamilton Duffy:  Most important part is that it removes 
  friction where LD signatures weren't playing well with JWS. 
  Community concerns around that -- was a blocker but Manu and some 
  JWS folks worked through it and we now have this solution that 
  makes them compatible.
Kim Hamilton Duffy:  Any questions?
Kim Hamilton Duffy:  Moving onto the Merkleproof signature suite. 
  This is Chainpoint v2, not 3.0 that was just discussed.
Kim Hamilton Duffy:  No timestamps. This is just Chainpoint v2 
  with an additional type indicating its space in the LD signature 
  suite. A lot of people are wanting to use LD signatures to 
  describe data that has been put into a Merkletree and anchored to 
  the blockchain. Wayne had donated this to this community and we 
  want to formalize this suite. The work has already been done, the 
  main things we might want to have discussion over is naming or 
  things like that. Effectively we have a lot of implementations 
  using it, blockcerts is using it. Chainpoint v2 has been used by 
  a lot of people in the wild.
Kim Hamilton Duffy:  Questions?
Ryan Grant:  I don't completely understand what the Merkle proof 
  is offering, do you have a link to follow?
Kim Hamilton Duffy:  I didn't include the links because the bulk 
  of what's in spec.
Moses Ma: I should probably introduce myself and offer a use case 
  that we have brewing.
Christopher Allen:  The main point that may not be clear from the 
  discussion is just having a signature for things isn't 
  necessarily good enough. Adding a timestamp by a merkle proof 
  that basically says -- is an acknowledgement of the rough time of 
  the event is useful. The timestamping service or the 
  chainproofing service basically gives you all of the leaves so 
  that you can reconstruct the merkle proof the way it was 
Christopher Allen:  Chainpoint 3 offers more fidelity and 
  information and compression of the data.
Christopher Allen:  And other features I'm forgetting. I'd love 
  to see the 3.0 stuff brought in now that we have a chance to 
  standardize on this.
Kim Hamilton Duffy:  For blockcerts to use it -- blockchain 
  transaction gives us a timestamp. There's a signing key related 
  to that and we're using JSON-LD normalization to get the 
  consistent hash that's getting placed in the merkletree.
Kim Hamilton Duffy:  To prove the hash of this document matches 
  what's expected.
Moses Ma:  Hi everybody, I'm Moses. The use case we're working on 
  is in the ICO space. We've recently recruited the former FCC 
  commissioner to help us comply with requirements. One use case we 
  came up with is to create a DID for an investor -- FCC wants to 
  prevent cheating (real person) -- and then a VC saying how much 
  crypto they've spent/accrued. We are working on that kind of use 
Moses Ma:  The stuff about Chainpoint 2.0 that's really 
Moses Ma:  Any questions about the use case?
David Chadwick: There are very few use cases where timestamps are 
  actually needed. Making a will in private is one such case. But I 
  do not see this to be a VC use case. By their very nature, VCs 
  are given by issuers to subjects therefore two parties are 
  involved. In this case secure time stamps are not needed since 
  both parties can verify the time
Dave Longley:  Term that's useful "proof of publication". gives 
  more trust that something happened at some point in time. can 
  check in other location. [scribe assist by Kim Hamilton Duffy]
David Chadwick: Proof of publication requires an author and a 
  publisher, so again secure time stamps are not needed
David Chadwick: If two parties are involved they can verify the 
  time between themselves
Frederico Sportini:  I was curious to know what is the 
  relationship between Chainpoint and open timestamps. Do they use 
  the same timestamps, competing implementations or what?
Moses Ma: If you're like to chat about our use case or just 
  become friends, please contact me at moses@ngenven.com or skype 
  eddress "mosesma"
Glen Rempe:  Both open timestamps and chainpoint are opensource 
  protocols. We feel that ours is more documented and understood 
  and easier to use. They both anchor to the blockchain, open 
  timestamp to bitcoin, Chainpoint to bitcoin and ethereum. They 
  only support a binary version, we have a JSON-LD, pure binary, 
  and base64 encoded version of the binary. Both trying to achieve 
  similar goals, use OP_RETURN for bitcoin, but I think we do a 
  better job. We will handle scale out of the box, orders of 
  magnitude more than open timestamps does. At the rate of 10s of 
  1000s of hashes per second. Those are a few things I would 
Christopher Allen:  I need to speak to this a little bit. I've 
  been frustrated by the situation. Peter Todd was participating in 
  RWoT. We reconciled some proposals to make Chainpoint 2 and then 
  Peter and Tierion talked to make Chainpoint 3 and open 
  timestamps. Things fell apart and I tried to address or fix that, 
  I'm going to support whichever one goes through the standards 
  process. If open timestamps wants to say we're going to listen 
  and be inclusive of designs for a large number of people I will 
  support that. They are roughly equivalent. Open timestamps have 
  some potentially unique ideas not implemented. I will support 
  whatever is standards track.
Christopher Allen: There are a couple more listed at 
Christopher Allen: In particular 2016 Pseudonymous Signature 
Christopher Allen: 
Dave Longley:  LD signatures is the base signature suite, 
  includes defining different components -- canon., message digest, 
  signature [scribe assist by Kim Hamilton Duffy]
Dave Longley:  Addresses key verification -- bidirectional 
  linking. Specific signature suites can override [scribe assist by 
  Kim Hamilton Duffy]
Dave Longley:  On top of that, others have been developed. RSA 
  2017, 2016Koblitz EC [scribe assist by Kim Hamilton Duffy]
Dave Longley:  Redaction signature suite: CL signatures to create 
  pseudonymous. redact certain portions, without revealing too much 
  [scribe assist by Kim Hamilton Duffy]
Dave Longley:  Is a proposed work item (we'll discuss next week, 
  btw) [scribe assist by Kim Hamilton Duffy]
Moses Ma: Let me restate what was noted: "Hi everybody, I'm 
  Moses. The use case we're working on is in the ICO space. We've 
  recently recruited a former FCC commissioner to help us build new 
  technology that could comply with certain requirements. One use 
  case we came up with is to create a DID for an accredited 
  investor -- the SEC wants to protect investors -- and then a VC 
  from a wallet saying how much crypto they've spent/accrued. We 
  are working on this kind of use case."
Moses Ma: SEC not FCC
Dave Longley:  Another way -- take giant doc of claims, break 
  down into individual statements, salt each, put in merkle tree. 
  Manu and Evernym would be able to speak to this [scribe assist by 
  Kim Hamilton Duffy]
Christopher Allen:  Need nonces to avoid fingerprinting [scribe 
  assist by Kim Hamilton Duffy]
Christopher Allen:  Need nonces to avoid fingerprinting 
  (correction) [scribe assist by Kim Hamilton Duffy]
Christopher Allen:  The redaction suite allows something that is 
  fully signed -- you have proof of the entire set of claims, 
  presenter can present a set of claims and have it still be valid. 
  You can do it cryptographically through redaction using 
  merkletree, using nonces, etc. to prevent fingerprinting, like 
  the FOAF problem two decades ago. When people published hashes of 
  email addresses and you could figure out who is friends of 
  others. The CL cryptographic technique is another way to present 
  but has computational requirements.
Moses Ma: The convolution of a set of claims is not a simple 
  problem. I should ask our AI lead to come on the call with me and 
  talk about how to organize and weight a set of claims optimally 
  to provide a multi-dimensional express of reputation.
Dave Longley:  Run canon first, produces ordered statements ---- 
  always get same order. each stmt is separate claim. each must be 
  salted to avoid fingerprinting [scribe assist by Kim Hamilton 
Dave Longley:  Correlation problem: if you get hashes, can 
  compare against others. when you have canon form, can modify in a 
  way to produce randomless. Place each in a merkle tree, sign 
  root. This is one way [scribe assist by Kim Hamilton Duffy]
Dave Longley:  Other way is to use CL signatures [scribe assist 
  by Kim Hamilton Duffy]
Dave Longley:  Can think of as a bit stream. can choose to 
  present (or not) certain bits [scribe assist by Kim Hamilton 
Dave Longley:  Reveal just those bits. Each one has certain 
  computation complexity. can be difficult if a lot of info. 
  [scribe assist by Kim Hamilton Duffy]
Dave Longley:  Tradeoffs either way [scribe assist by Kim 
  Hamilton Duffy]
Ryan Grant: I voted for redaction, but a late vote last week
Frederico Sportini:  How should we get in contact? [scribe assist 
  by Ryan Grant]
Frederico Sportini: Federico.squartini@gmail.com
Frederico Sportini: And find me on the rwot slack
Ryan Grant: Great!
Moses Ma: Thanks everyone. I'd love to get some URLs for intro 
  materials? There were a lot of acronyms to learn.
Christopher Allen:  Did I answer your question adequately about 
  the salting of canonicalized statements?
Dave Longley:  I think that portion would be considered part of 
  the signature mechanism -- as you may need to include, for 
  example, some kind of "seed" for generating the salts and include 
  that in the signature parameters (but this would be kept secret 
  when disclosing)
Dave Longley:  So it seems that you canonicalize, then generate 
  signature parameters, which include a "seed" input for the salt 
  generator and any other parameters required ...
Dave Longley:  Then to perform the signature you generate the 
  "salt" for each statement from the seed and some algorithm -- and 
  then you hash that.
Dave Longley:  It's more like a preparation step for signing or 
  perhaps even part of the "digest algorithm" than the 
  canonicalization algorithm.
Dave Longley:  It's a special salted hash, effectively.
Received on Tuesday, 20 June 2017 19:33:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:38 UTC