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. ✪
Glenn 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. ✪
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: 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: 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 system. ✪
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. ✪
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 ✪
Glenn 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 resistant. ✪
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. ✪
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. ✪
Glenn Rempe: I'd be happy to take a look at that. ✪
Topic: Chainpoint v3.0
Glenn 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. ✪
Glenn 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. ✪
Glenn 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. ✪
Glenn 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 request. ✪
Glenn 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? ✪
Glenn 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? ✪
Glenn 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. ✪
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 them. ✪
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: 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. ✪
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 registered. ✪
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 case. ✪
Moses Ma: The stuff about Chainpoint 2.0 that's really interesting. ✪
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" ✪
Glenn 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 highlight. ✪
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. ✪
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." ✪
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 Duffy] ✪
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 Duffy] ✪
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] ✪
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. ✪