From @kimdhamilton on July 14, 2017 18:30

• continuation of DDO?
• next DDO record?
• extension DDO?

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

From @ChristopherA on June 30, 2017 21:58

At some point we'll want to move from koblitz ECDSA signatures to koblitz Schnorr signatures. This will offer some huge advantages long term.

Note however, unlike ECDSA you can't recover a Schnorr public key from a Schnorr signature. This means you have to get the public key from either the data structure, or from some other source.

We need to be sure that our data structures support both current ECDSA and Schnorr signatures. This means we may want to always publish the koblitz public key (used by both) in the signature even though in the ECDSA case it may be redundant (or not, as there may be multiple valid public keys, see #9)

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

Introduction

Data minimization and selective disclosure (D&S, DataMin, SelDis) are very cool applications of crypto to do magic tricks, such as proving a person is over 25 years old without revealing their birthday or even which credential vouched for the person.

These capabilities are needed for creating, storing, presenting, and verifying user-controlled credentials among other things: DataMin is one of three mitigations against privacy threats in RFC6973, it is featured in article 5 of the GDPR, the USA Privacy Act of 1974 and often appears in FIPPs. This group's goal is to standardize D&S techniques for the Verifiable Claims work (to be used in Blockchain systems supporting self-sovereign identity), an official work item of the W3C Credentials Community Group. Some topics we plan to address include Merkle trees for redaction, Progressive disclosure, CL Signature schemes (Camenisch-Lysyanskaya), ZK (zero knowledge) protocols such as Fiat-Shamir, ZK Snarks and Starks; also commercial providers such as Qredo.

Current known participants in this work item are:

• • Lionel Wolberger
• • Jan Camenisch
• • Maria Dubovitskaya
• • Christopher Allen
• • Kim Hamilton Duffy

The overall agenda is to bring a range of intellectual horsepower from cryptography interest/expertise to simply wrapping one's head around what we can (practically) accomplish in this space. We may pop up several levels to think through user stories to clarify the needs.

• • Logistics
• • Go wide before we go deep
• • Go deep on language
• • Go deep on crypto & tech
• • Get code
• • Organize, prioritize
• • Report

This inventory is a step towards supporting the drafting and incubating of related Internet specifications, as well as further standardization and prototyping and testing reference implementations.

REFERENCES WITH SOME ANNOTATIONS

Data Minimization and Selective Disclosure Repo: https://github.com/w3c-ccg/data-minimization

2010 Pfitzmann, Hansen. A terminology for talking about privacy by data minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management" Link: https://www.researchgate.net/publication/234720523_A_terminology_for_talking_about_privacy_by_data_minimization_Anonymity_Unlinkability_Undetectability_Unobservability_Pseudonymity_and_Identity_Management

RFC6973 Cooper, Tschofenig, Aboba, Peterson, Morris, Hansen, Smith, Janet 2013. Link: https://tools.ietf.org/html/rfc6973. The draft can also be helpful, "This document focuses on introducing terms used to describe privacy properties that support data minimization." 2012 Hansen, Tschofenig, Smith, Cooper. Privacy Terminology and Concepts. Network Working Group Internet-Draft Expires: September 13, 2012. Link: https://tools.ietf.org/html/draft-iab-privacy-terminology-01

Redaction Signature Suite 2016, Draft Community Group Report 26 June 2017. Longley, Sporny. Link: https://w3c-dvcg.github.io/lds-redaction2016/ "This specification describes the Redaction Signature Suite created in 2016 for the Linked Data Signatures specification. It enables a sender to redact information in a message without invalidating the digital signature."

AGENDA IN MORE DETAILS

• • Logistics: Who are we, who should we work with, what is our cadence, how do we meet, when is this due.
• • Go wide before we go deep. What is this? Discovery of other groups working on these issues; literature review. Find standards, FIPPS, trends. Bring a range of intellectual horsepower from cryptography interest/expertise to simply wrapping one's head around what we can (practically) accomplish in this space. We may pop up several levels to see the broader picture.
• • Go deep on language. Clarify our nouns and verbs: Nouns, Inventory of relevant terms (glossary), the things/algorithms/protocols etc. Verbs; Inventory of relevant use cases, journies, what are we trying to achieve, what the relevant nouns do for us. How does someone represent what they need, and how can we minimize this or be more selective? Can we handle partial claims e.g. someone asks for proof of zip code?
• • Go deep on technical issues. What crypto is available? Innovations in the blockchain space? How do we canonicalize (JSONLD)?
• • Get code: What procedures exist? Is there a low hanging fruit (e.g. Merkle Tree redaction?) Discover or generate examples, sample code, prototypes.
• • Organize, Prioritize, Bring order: - List the gnarly parts: key management and revocation. Rank solutions for relevance to CCG
• • Report: Submit a report back to the CCG

From @ChristopherA on June 30, 2017 21:50

There are some interesting future scenarios for use of multisig in BTCR.

The easiest is revocation. If the tip is a multisig address, for instance a 2 of 5, I could give my 5 closest colleagues the right to revoke my DID if at least 2 notice misbehavior of my account and move the unspent funds on the tip off. They can post a revocation reason (see #5) in an op_return), or put the key on hold (see #6).

The challenge is key rotation/recovery. The two kinds of multisig in Bitcoin are the recommend P2SH and the older but not deprecated op_checkmultisig.

Key rotation/recovery with is difficult as P2SH doesn't use keys the same way as P2PKH as it , so in order for the multisig participants to change the tip owner key to a new address they would need to point to a P2PKH transaction by using some code in the revoking transactions op_return. Until we can support script signatures (see #14) this means that DDO changes would require two transactions increasing cost.

Key rotation/recovery with op_checkmultisig has different challenges — it include the signatures of the signers for which can be used to recover their public keys, but then we'd need to support multiple public keys for signing the DDOs (and potentially verifiable claims) but there are not any good examples of this in JSON linked data signatures yet.

For purposes of this hackathon we should focus on single signature P2PKH but for the spec we probably should talk about possible multisign scenarios.

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

From @kimdhamilton on August 12, 2017 2:28

Per discussion with @ChristopherA , create testnet DID creation tool in-browser (test only)

See source for https://brainwallet.io/, but revert back to previous commit. good feature set

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

From @veleslavs on July 9, 2017 12:29

Myself and @jonasschnelli have been brainstorming and working in private about a proposed Identity Enrolment Transaction for Bitcoin (and other comparable blockchains).

https://github.com/veleslavs/bips/blob/wip/bip-XXXX-Revocable_Public_Key_Enrolment_Transaction_with_Optional_Cost.mediawiki

We would certainly welcome more pre-draft feedback on this work-in-progress BIP.

cc: @muneeb-ali @shea256 @jcnelson @ChristopherA

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

From @ChristopherA on June 30, 2017 7:6

Related to issue #5 it may be useful to have a "DID hold" op_return with a date, such that the DID is not considered revoked, but that it isn't valid yet. This way you can pre-publish a DID.

There also may be some useful tricks by adding to the P2PKH transaction a timelock.

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

Owned vs. Unowned Claims and Self-Sovereign Identity

Natalie Smolenski
Cultural Anthropologist and Business Development
Learning Machine

When Christopher Allen presented ten principles of self-sovereign identity for community discussion, he listed “Control” as the second principle. He described it as follows:

Control. Users must control their identities. Subject to well-understood and secure algorithms that ensure the continued validity of an identity and its claims, the user is the ultimate authority on their identity. They should always be able to refer to it, update it, or even hide it. They must be able to choose celebrity or privacy as they prefer. This doesn’t mean that a user controls all of the claims on their identity: other users may make claims about a user, but they should not be central to the identity itself.

The distinction here between owned and unowned claims is important, and how they are both managed will be key to functional implementations of self-sovereign identity.

The term “self-sovereign” has been catching on as of late, and has been used to describe instances of digital identity (government-controlled digital passports, the internet of things) which are clearly not self-sovereign. This confusion stems in part from difficulties individuals have understanding the difference between claim ownership vs. claim sharing and verification. Yet this distinction is one on which the future of individual privacy and autonomy depends.

Claims made about individuals by other parties already proliferate and will continue to proliferate with blockchain technologies as well. Yet as the pseudonymous transactional structure of chains becomes increasingly tied to digital identities, the danger is that the blockchain could become the infrastructure for a regime of control unprecedented in human history. There is no reason, in principle, why individuals could not become objects in a giant supply chain, tracked like commodities as they move and transact around the world. Participating in this tracking could become the precondition for access to all forms of tokenized resources—including government currencies, utilities, financial services, the ability to make purchases within certain jurisdictions, and basic rights and privileges.

In short, what began as the best attempt to date to preclude the momentous expansion of surveillance capitalism could end up becoming its apotheosis if we do not address early on the individual ability to manage not only claims about themselves that they own but claims they do not own. Obviously the two cases entail different sets of considerations, and this is why I suggest beginning discussion about them now.

Sources:

Christopher Allen, “The Path to Self-Sovereign Identity.” Life with Alacrity. April 26, 2016. http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html.

From @ChristopherA on June 30, 2017 7:46

There was some discussion on this at w3c/vc-data-model#32

I would love it if we at least be able by end of the hackathon be as good as PGP able be able to claim that Alice's pseudo-anonymous DID knows Bob's pseudo-anonymous ID (which is basically all that PGP does).

If we are also able to all one party to PROVE that the other party holds the control key for their DID, even better (PGP doesn't do this).

Publishing some local nyms/local names could also be powerful (see: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/topics-and-advance-readings/linked-local-names.md & https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2017/blob/master/topics-and-advance-readings/did-names.md )

Finally, maybe some other statements like "is-a-natural-person" would be useful without moving into territory of personally identifiable information.

I'd also like to set a precendence for DID:BTCR that that all such claims that are not counter-signed/acknowledged by the subject are not considered to conform to fully self-sovereign IDs between natural persons. This may be controversial.

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

From @kimdhamilton on July 14, 2017 18:37

Due Monday

Send to:

• Verifiable Claim CG @kimdhamilton or @ChristopherA
• Credentials CG @kimdhamilton or @ChristopherA
• Blockcerts community @kimdhamilton
• Drummond forward to DIF group before their hackathon

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

From @ChristopherA on June 30, 2017 6:44

I really like idea of using a bech32 encoded DID:BTCR as @sipa did some amazing work investing a good error detecting AND correcting encoding algorithm. https://github.com/sipa/bech32

@veleslavs & @jonasschnelli's proposal for encoding the transaction index and block number also make great sense, and I like that the magic values can be used to identify different variants blockchains close to bitcoin (I hope they propose a lightcoin value as it already supports segwit) https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Postion_References.mediawiki

However, this proposal is still not officially a BIP, we don't know who else is supporting it, has not been adopted elsewhere, and may change.

We should check with Blockstack to see if they are up to supporting this proposal or if they have reservation. (I hope they like it).

cc: @muneeb-ali @shea256 @jcnelson

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

Please correct the first page, typo.
Typo: name is wolberger, not wolberg

From @ChristopherA on June 30, 2017 6:34

Blockstack was the first to suggest that the DID an index of the transaction within a confirmed block, rather than the transaction ID. The advantage of this is that it is possible to have a transaction id that isn't confirmed, as it is only the hash of the transaction. The disadvantage of it is all of the bitcoin explorer APIs search on transaction id.

The most secure method of confirming a DID:BTCR will be to have a full node with -txindex on, but ideallly we do want to support lighter clients being able to confirm via a online explorer.

We should investigate if any explorer APIs allow us to search for a transaction index within a block, or announce support of @veleslavs & @jonasschnelli proposal for a bech32 transaction id.

cc: @muneeb-ali @shea256 @jcnelson

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

From discussion with @msporny @ChristopherA and @kimdhamilton

Spec should be declarative: as long as you end up with X, doesn't matter how you construct it

The BTCR examples are doing 2 things, which Manu recommends separating.

1. proof of control
2. verifiable claims

For BTCR, why fragments?

• DDOs have almost nothing to do with VC, but can shove VCs into a DDO
• BTCR can build up a datastructure over time, but mechanism is different btw ledgers
• what is the best way to mark "go look for next object"
• we don't have a way to rotate or revoke claim issuer -- see doc for REVOKED

From @kimdhamilton on July 10, 2017 22:19

Specify an tx-signed deterministic DDO, that conforms to DDO spec 1.0, and is not a verifiable claim.

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

From @ChristopherA on June 30, 2017 19:27

In a sense, we could use the method that P2SH uses in bitcoin as a new signature system type for DDOs and Verified claims. Basically the scriptPubKey is the pubkey, and the scriptSig is the private key. This would require us to re-package bitcoins script https://github.com/bitcoin/bitcoin/blob/master/src/script/sign.h to instantiate a new BaseSignatureCreator for the message instead of a Bitcoin transactions, and invoke ProduceSignature.

This is basically one of the goals of Smart Signatures (see https://github.com/WebOfTrustInfo/ID2020DesignWorkshop/blob/master/final-documents/smarter-signatures.pdf )

This might be a bit of a large bite to commit to in this July's virtual hackathon, but it is the long term future.

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

I noticed a couple of typos in the Amira 1.0.0 document:

diff --git a/final-documents/amira.md b/final-documents/amira.md
index 7334fbd..c5efdea 100644
--- a/final-documents/amira.md
+++ b/final-documents/amira.md
@@ -532,7 +532,7 @@ While the app has become popular, she notices it is straining under
 heavy technical debt. Amira reaches out to BigBen44 once again as
 BWHacker2. The two rekindle their connection, and Ben tells Amira that
 he wants her back full time. Amira gives notice to the bank, reactivates
-her BWHacker profile in the directory, and steps into her dream job of
+her BWHacker2 profile in the directory, and steps into her dream job of
 writing socially-responsible software.

 **Appendix A**
@@ -542,7 +542,7 @@ writing socially-responsible software.
 The 15-stage model presented here is an instance of an Information
 Lifecycle Engagement Framework, as illustrated below.

-![](media/image1.png)
+![](images/amira-1.png)

 Each phase in the model presents a concise description of one or two
 interactions illustrating the phase. Rather than attempting to describe

I have corrected them and also generated the odt and pdf files using pandoc. If this is sufficient, I will submit a pull-request. If I need to do something further, let me know.

From @ChristopherA on July 8, 2017 3:2

At some point we need to write up some best practices vs reasonable practices documentation.

For instance, ideally you should treat your keys like you do with bitcoin — you use your root key to sign your transaction and immediately sign a few other objects with it (such as the DDO), and you never use it again. If you need ongoing signing keys, put them in the DDO and expire them regularly.

For a high-value pseudo-anonymous identity, you should treat your keys like glacier does for high-value bitcoin transactions, with raw transactions and air-gapped computers: https://glacierprotocol.org/

Clearly the DDO itself should not be centralized, so services like IPFS

As a different kind of example, in my first personal DDO at https://raw.githubusercontent.com/ChristopherA/self/master/ddo.jsonld, I do some things that are not recommended for a pseudo-anonymous identity (as it is clearly not anonymous). However, my choices there are reasonable. First, my DDO is centralized (it is a DNS URL, and it is hosted on github), but my commit of my DDO is signed by my PGP key there. Both are mirrored in a variety of places. When we later can add timestamping it will have more provenance.

Even though in my personal DDO example I'm not trying to be pseudo-anonymous, I also plan to try to not reveal information about others. So I might say I "know" another DID, but I will only do so if they have accepted it as a counter-claim (i.e. they "know" my DID). There is no technological way to force this, but as a social practice we should encourage it.

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

From @ChristopherA on June 30, 2017 6:57

I know that @lukejr and others will complain that DIDs have the potential to bloat the blockchain and UTXO mempool, as each DID:BTCR will have to have at least one unspent output.

For know I propose that we acknowledge this objection and keep it on our issue list. We will recommend P2WPKH over P2PKH so that witness data and op_return data can easily by purged by nodes who do not wish to retain all the data. If at some point we can address the UTXO bloat issue (say with @petertodd pay-to-contract approach?) we will do so. In addition, we will be clear in our various materials that DID:BTCR is not intended to scale to all the world's citizens, but is instead is for self-soveright identities with high security and pseudo-anonymity requirements.

In the meantime, we are not the only ones using op_return, so in the spirit of "Perfection is the Enemy of the Good" we will support P2PKH and op_returns that point to DDOs.

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

From @kimdhamilton on July 14, 2017 18:41

Each of us should create a bitcoin testnet DID and a github DID where the commit is signed with our PGP key, so we can start creating some web of trust schemas and examples.

• @ChristopherA did:btcr:xyv2-xzyq-qqm5-tyke

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

From @ChristopherA on June 30, 2017 7:6

Related to issue #5 it may be useful to have a "DID hold" op_return with a date, such that the DID is not considered revoked, but that it isn't valid yet. This way you can pre-publish a DID.

There also may be some useful tricks by adding to the P2PKH transaction a timelock.

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

From @ChristopherA on July 9, 2017 22:44

Related to #3 "Censorship Resistance in OP_RETURN Transactions", as per @sipa's comment WebOfTrustInfo/btcr-hackathon-2017#2 (comment) we also want to have as goal to have censorship resistance for the revocation transaction.

You want censorship resistance for the revocation, not the publishing. If you're being
censored for registering, just don't start using the identity and try again. If your revocation
is censored, your identity may have been stolen.

So walking through the scenarios:

Scenario One: Clearly if your DID is broadly distributed and easily identifiable (as it would be in the case if you have a DDO pointer as per #2, or possibly even with the TX1 proposal in #24), then a miner might choose to arbitrarily censor any revocation transactions associated with that DID. A counter-argument might be that there are lots of miners, so as long as at least one honest miner a day accepts a transaction fee to revoke, you can have at least a 1 day revocation window. This is superior to many certificate revocation scenarios today that are not very reliable at all or require very centralized authorities.

Scenario Two: However, if it is a DID is without an op_return pointer to the DDO or has other identifiable characters (aka a "default DDO") and you are using a simple address as output serving as the revocation signal, this is harder to censor. The miner must know about your DID to find the addresses to censor, requiring them to have received it from someone, or possibly by crawling the net looking for verifiable claims. I'm not sure that this scenario is much different than the current correlation efforts by bitcoin analysis firms today. Thus if this is a problem, we may be able to leverage someday the same efforts to increase fungibility to also increase censorship resistance.

Finally, @sipa says:

Regardless of how you encode things, if your identifier is short, it means that the
revocation is detectable for everyone.

I'm not sure I agree with that statement.

In Scenario One the key problem is that the DID is identifiable and broadly distributed, not that the ID is short or long. Here censorship resistance against miners is harder.

However in Scenario Two both the DID and its future revoking transaction are not easily identifiable or correlatable thus it requires the censor to have knowledge of your DID from some other source — in this case, again the difference between searching for a short identifier or a long one is minimal. If the censors are miners, they not only must have searched or collected your identifier, they must also resist all other miners who are not interested in censoring the revocation transaction, which is a general Bitcoin problem, not a DID specific one.

cc: @jonasschnelli @veleslavs

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

From @ChristopherA on June 30, 2017 19:10

Ideally, based on bitcoin principles, a key pair is only used twice — the first time only locally to create the hash that become the address, and one last time when the public key is revealed as part the signature of a transaction moving the funds to a new address.

This in DID:BTCR we should try to approach this ideal. If you use a DDO, you can only use the key pair three times, creating the address, spending the address, and one more time after the transaction is confirmed. All other keys reside in the DDO, which can include things like a PGP key. This does mean any update to these keys or the DDO information does require a bitcoin transaction and pay the fees associated.

In the case of a bare DDO (i.e. no actually DDO object pointed to in op_return) there is only once key that can be used for things like verifiable claims. This violates the bitcoin principles on key reuse. However, a bare DDO is the most censorship resistant, as it can't be identified as being different than any other P2PKH transaction.

In the case of a bare DDO, we may want to recommend that any use of the key for things like verifiable claims be the same day, possibly requiring a chainpoint-style merkle proof of existence in addition to the signature for bare DDO verified claims. This limits key reuse to the day of the transaction.

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

From @ChristopherA on July 9, 2017 23:11

I've come to the realization that both @veleslavs & @jonasschnelli's proposal at #24 and the original DID:BTCR proposal are all basically different methods, which the top level DID spec specifically encourages and supports.

If we do one for Lightcoin as well (LTCR? TX2?) and if Blockstack (BLST? cc: @muneeb-ali @shea256 ) also joins us, this means that we could all use the common bech32 encoding for our Decentralized IDentifiers.

Thinking through this further, this has some consequences on our design.

First, we've been proposing so far a DID that looks like my test DID of did:btcr:tx1-xxyv-xxxx-fpmf-u0 — however, in fact, we don't need the tx1 prefix as that is actually a method designator. So it could be shorter and thus did:btcr:xxyv-xxxx-fpmf-u0, and @jonasschnelli DID would be did:tx1:rk63-uvxf-9pqc-sy — both would be W3C conforming URNs and valid DIDs.

However, this is another level of redundancy that we could consider. The bech32 encoding (see #2) actually has 'magic bytes' in it that signify the chain. In my case xxyv-xxxx-fpmf-u0 the first x tells us to look for the transaction on the bitcoin testnet, and in @jonasschnelli's case rk63-uvxf-9pqc-sy the first r tells us to look at the bitcoin main chain. Future magic numbers could tell us to look at a fork of the bitcoin main chain (hopefully none of those happen!), at a lightcoin chain, a sidechain, etc.

This leads to the possibility is that it could be instead be used as a submethod identifier — r and x are for the tx1 style DIDs on main chain and testnet, new magic codes for s and y could be for btcr style DIDs on main chain and testnet, and some other values could be for lightcoin or used for Blockstack's proposal.

f we can agree to a common root method spec, supporting all the variants, this could be useful. It does mean that there is a centralization of assignment of the magic codes, but that is also true for DID methods (for which we at least use the W3C process).

The disadvantage of combining is that anyone with a fifth idea or future idea would have a harder time getting a new submethod proposal once a joint proposal was publish. The advantage to everyone having a different DID method identifier is that they all can compete in the marketplace of ideas freely as anyone can propose a DID method. Of course we can also leave the differences between all these variants as separate but open submethod specs ;-)

For now I suggest we keep them as separate method specs, and help @veleslavs & @jonasschnelli create a parallel TX1 DID spec conforming to the W3C process with their BIP proposal. We can discuss if there are sufficient commonalities that it makes sense to go into creating submethod specs for the differences.

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

From @ChristopherA on June 30, 2017 7:2

The easiest way to revoke a DID is to just spend the previously unspent funds on the tip.

This technique was inspired by my revoke-ssl approach suggested in https://github.com/ChristopherA/revocable-self-signed-tls-certificates-hack and presented at https://www.meetup.com/SF-Bitcoin-Devs/events/222712738/

In that proposal it was suggested that optionally the op_return could encode the reason for the revocation. For instance: key compromise, change of affiliation, superseded, cease of operation, or unspecified, hold

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

From @ChristopherA on June 30, 2017 7:15

We would like multiple approaches in DID:BTCR to point to the DDO.

The first is simple — don't include an op_return at all. A DDO is constructed based on information from the transaction and the block the transaction is confirmed in. These include the control key (from the public key in the P2PKH script), the owner key (the hash of the future key that is the address the first txout has been sent to), and the date from the blockheader. There may be some other useful information that can be assumed.

The second is a short URL, less than 40 or 80 characters, that points to the location of the DDO, which is self-signed by the transactions public key.

The third is a content addressable hash, possibly with URI at beginning. We should consult with @jbenet's IPFS team what the best method is. Some hash encodings with URI may be too large for 40 characters. There is also related to issue #3 — a bare hash value is indistinguishable from any other has, but an hash identifiable as an IPFS hash could be censorable.

Finally, the fourth is pointing to Blockstack's layer two update record. I'm not quite sure if they are planning on updating how they do that anytime soon. Does that need a URI or prefix?

cc: @muneeb-ali @shea256 @jcnelson

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

From @ChristopherA on June 30, 2017 21:35

It doesn't appear that there is any standard yet for encoding of a koblitz curve public key (i.e. the secp256k1 curve).

There is a proposal of base58 prefix of 4 for compact Bitcoin public keys (see https://en.bitcoin.it/wiki/Base58Check_encoding ), but as far as I know no one uses that.

Bech32 is superior to base58 in a variety of ways, may be we should consider using that? I do know that Lightning is proposing using bech32 for public keys, but they are also putting other info there.

@jonasschnelli I know that your lib will output a hex encoded public key. Do you know of anyone else directly encoding public keys in base58? Are you aware of anyone using Bech32 for public keys besides in Lightning? Since you are adding bech32 to your lib, would you consider offering a public key encoder?

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

From @ChristopherA on June 30, 2017 7:49

My vision for the core Use Case for DID:BTCR is at w3c/vc-use-cases#31 — I encourage everyone to read it. I'd also love to continue to work with @jandrieu on moving the use case forward toward his full 15-step model that he did for Jorum during our hackathon if he is up for it. Maybe Natalie could help? @kimdhamilton?

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

the authorizedRevokingParties is mentioned in the blockcerts-revocation paper several times. Where is it stored to ensure that the revocation process is decentralized?

From @ChristopherA on July 12, 2017 0:7

(this is a pre-draft of a post to be an issue on https://github.com/w3c/vc-data-model/issues/ or possibly added to w3c/vc-data-model#58 once it is more thought out)

As evidenced by the failure of polling in the W3C Verifiable Claims WG last week on the name of the role of Validator vs. Inspector, and the lively discussion in the WG meeting today https://www.w3.org/2017/07/11-vcwg-minutes.html, we lack a really good model for describing the multiple actions that happen in our verifiable claim architecture, in particular when blockchain-based DIDs are being used.

In addition, our whole industry has been terribly bad at the practical considerations as to the issues of how revocation should be designed. I personally have experienced this with SSL/TLS, which for almost a decade and a half had only lip-service support of revocation, and even now is still being challenged to deploy more advanced solutions

So I want to walk through DID:BTCR from the vantage point of a number of steps that fall into the Integrity/Inspection/Validation/Verification/Confirmation/Revocation spectrum of roles.

First, please forgive in advance the specific words I'm using below — they are used more to signify the different placeholders as opposed to a well thought out proposal as which words should be used.

In our #RebootingWebOfTrust User Story Alice, our pseudo-anonymous programmer. daughter of immigrants, has heard that Bob, a refugee advocate has a need a mobile phone app. Fearing that her own extended family might be harmed if she is revealed to be helping Bob, she wishes to introduce herself and present credentials that she is qualified for the work, but remain pseudo-anonymous.

So first she establishes a DID and self-signed DDO. She has a professional colleague and friend Donna with a public persona (i.e. not anonymous) who indirectly knows Bob through yet another colleague (i.e. Bob & Donna share a trust network but connected by multiple-degrees of separation).

Donna issues a Verifiable Claim that she "knows" Alice and she is willing to attest to her competence in mobile development, which Donna gives a signed copy of back to Alice. Alice counter-signs this claim and adds it to her DDO (this is something unique to the very self-sovereign BTCR method, and may not apply to other methods).

Alice then sends a response to Bob's request for programming assistance, along with the claim issued by Donna.

Now we dive into some mechanics:

Bob receives this offer from Alice (possibly itself a self-signed claim) along with the claim issued by Donna. The first thing his software does is do an INTEGRITY CHECK of the claim itself. Is it properly formed? Has it expired? Is it properly signed by the issuer? Is it properly countersigned by the subject? If it fails any of these INTEGRITY CHECKS, Bob will not even know about it, and the whole message and claims will be rejected.

The next thing the software MAY do is INSPECT INTO the claim the DID number found in Donna claim. This will typically be automatic, but if Bob is hyper-concerned about internet traffic correlation (as he is advocating against a nation-state) it may require a human to decide if they wish to proceed further. But Bob is an EU citizen and feels sufficiently protected, so his software is set to INSPECT INTO automatically.

The first DID is Donna's. His software INSPECTS INTO the Bitcoin Blockchain for the appropriate transaction, and then looks at the first TXOUT of that transaction to see if it has been spent. In this case, it has, so this transaction cannot be VALIDATED. However, it has not failed, so the software now goes forward to that new transaction (the "tip" of the DID chain).

This time the software INSPECTS INTO this transaction's first TXOUT, and is not spent and there is a properly formatted op_return pointing to a DDO, which reside's on Donna's github account. The software now INSPECTS INTO and finds the DDO.

Now the the software does an INTEGRITY CHECK on the DDO, and if is, then it VALIDATES the DDO by comparing it to the control key that is found from signature used to send transaction to the Bitcoin Blockchain that the INSPECTION CHECK revealed. If they match, both the DID and the DDO are now VALIDATED.

However, the claim itself was not signed by the control key so it is not VALIDATED yet. So the software INSPECTS INTO the DDO, and finds another key (either looking through all the appropriately listed keys, or possibly because of a hint added in the claim). If the signature on the claim matches, now the claim issuer is VALIDATED.

However, the claim makes a statement to yet other DID, so it not yet VERIFIED, only VALID. The software must now do the same set of operations on Alice's DID to INSPECT INTO her DID and determine if it too can be VALIDATED.

Finally, if both the issuer's DID and subject's DID are VALID, (which includes the previous INTEGRITY CHECK of Donna's claim and Alice's countersignature of Donna's signature on the claim) the claim is now VERIFIED (thus it is called a "Verifiable Claim").

However, this verified claim is not yet CONFIRMED. In order to be CONFIRMED, Bob's Web-of-Trust CONFIRMATION criteria needs to be met. In this case, **Donna" is a third-degree connection, making Alice a fourth-degree connection. Over half of the world is a fourth-degree connection!

In this case, the software kicks out the claim for Bob to make a decision on (i.e. the claim and DIDs are both VALIDATED and VERIFIED, but not CONFIRMED). He decides to look further into what Donna is willing to share in her DID. In this case, Donna is vaguely known to him ("a familiar stranger") and her github repository is active and has a long history of mobile development. He looks now at what Alice shares in her DID, and it is almost nothing, and has no personal info. However, her response to his request for proposal is interesting, and he hasn't found anyone yet, so he decides to CONFIRM and accept this claim to give her a trial.

If Alice fails her trial, Bob will change his criteria to never waste any time on her again, or even possibly never even bother to look at CONFIRMING any more Donna's claims (a locally-negative trust, but is non-transitive to others in the self-sovereign scenario required by the BTC method).

However, Alice doesn't fail her trial, and later Bob issues her a new claim saying that he also liked Alice's work, and maybe even issues a claim that countersigns Donna's original claim, showing appreciation for Donna's good recommendation.

(the next section will discuss when things go wrong, aka REVOCATION)

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

Hi @cwebber ,

In your great article on ActivityPub you make mention of Append-only and content addressed storage as a topic for future papers.

I am very interested in this topic. Do you have any pointers to additional information sources?

(Actually your paper is so interesting.. also fully decentralized uses and the DID work are great!)

From @kimdhamilton on July 10, 2017 22:49

Ryan Grant gave a useful intro to DIDs and DDOs. We're going to write this up for review for broader sharing

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

From @ChristopherA on July 11, 2017 21:14

Create a testnet-based DID pointing to a DDO, and document the "reasonable practices" DID scenario (i.e. secure but not truly pseudo-anonymous identity, see #20) for DID:BTCR.

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

From @kimdhamilton on July 16, 2017 23:55

What should happen if no OP_RETURN is present?

At the moment, this can happen in 2 cases:

• Intent was to create a DID with no continuations
• No intent of creating a DID with a transaction

This ends up with weird cases if the signer did not intend to create a BTCR did:

• if OP_RETURN is present in the tx, it is listed as a DDO continuation
• either way, it's as if they are getting a btcr did "for free" without some special marker. This may be acceptable, but if so we should call out this interesting side effect.

This issue is two-fold:

• How to address in UI
• How to address in spec

The latter can be moved to the proper repo after we determine how to address.

Copied from original issue: WebOfTrustInfo/btcr-tx-playground.github.io#9

for the control keys in the Deterministic DDO we have items like this"

"hash-base58check": "mvZ3MyLgsvYr87GGSbsPBWEDduLRptfzEU"

Melvin Carvalho mentioned the provisional IANA prefix for bitcoin -- would this be relevant here?

From @PositronicBrain on July 13, 2017 10:49

IPFS uses a base58 encoding for the hashes which points to documents, example: QmeNm7hRTtLsYtQA1w8Tu9wHzu8ZfBFc4w59UMuAK3b2ar, which has length 46 bytes. In order to save space in the OP_RETURN one would like to store the raw decoded bytestring.

The above address has decoded representation: 12 20 ee 45 65 85 70 89 4a 2f fe f3 fe 11 de b3 0a ac 08 c4 39 8b e1 bd 25 0d 85 dd bc ca 67 1f 99 bf with length 34. The first byte 12 determines the encoding, sha256 (the standard one in IPFS). The second byte 20 is the length of the hash following it.

Should we keep these two bytes or drop them in the op_return?

Arguments in favour: without them the hash is a random number and censorship resistance improves. We also save space.

Argument against: knowing the hash used improves future compatibility.

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

From @ChristopherA on June 30, 2017 6:51

It has been raised by @petertodd and others that using an op_return to encode the pointer to the DDO could hurt censorship resistance, as minors could identify those transactions that are DID related and not include them.

Instead, they recommend encoding it into the script of a P2SH transaction as some form of pay-to-contract. However, I still don't have a proposal from @petertodd on the best way to do this (he wants a similar capability to prevent censorship of open timestamps transactions). Another concern about the pay-to-contract approach is that it may mean two transactions to do a DDO update. An advantage is that it may support P2SH multisig DDOs.

For the first prototypes of the DID:BTCR method, I suggest we stick to P2PKH and P2WPKH transactions and we can support more censorship resistant methods later.

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

From @ChristopherA on July 14, 2017 21:4

To keep the dialog open about BTCR and the results of this hackathon, notify various communities and try to keep conversations going.

This should be the last issue closed in this repo.

• W3C Credentials CG Public List [email protected]
• W3C Verifiable Claims WG Public List <Verifiable Claims Working Group [email protected]
• DID Repo Issues https://github.com/opencreds/did-spec/issues/4
• Rebooting Web Of Trust Announcements (MailChimp)
• tx1 BIP proposal for txref bitcoin/bips#555
• tx1 BIP proposal in bitcoin-dev community email list https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014396.html
• DIF community (@Drummond, how?)
• Blockstack Community
• IPFS Community

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

From @ChristopherA on July 8, 2017 3:14

There are currently a limited number of libraries for canonicalizing JSON-LD. In particular, for prototyping some DID tools as shell and/or C commands, we can do JSON, RPC and do bitcoin signing but we can't canonicalize it.

I'd like to see a standalone Javascript page and/or RPC web service that you can download locally to your computer that can:

• given a JSON-LD, validate it
• given a JSON-LD Verifiable Claim, validate it
• return a cleaned up JSON-LD
• return a canonicalized JSON-LD ready for signing
• verify a signed JSON-LD object signed with RSA or koblitz

By default we should NOT offering signing via RPC as that is just a bad habit security wise. We can either use other local tools for that (bitcoind signmessage for instance), or sign locally in a separate local javascript file.

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

From @kimdhamilton on July 10, 2017 22:24

Dependent on #27

• Represent DDO as a Verifiable Claim
• Claim signed by the same key as the Bitcoin transaction

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