Identity protocol v1: Difference between revisions
Line 15: | Line 15: | ||
** Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check. | ** Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check. | ||
** Big Auction Provider, Inc. digitally signs a SIN as having a certain reputation score, on their website. | ** Big Auction Provider, Inc. digitally signs a SIN as having a certain reputation score, on their website. | ||
** Decentralized | ** Decentralized market users digitally sign one another's SINs, building a decentralized reputation | ||
* Has some creation cost, deterring spam. | * Has some creation cost, deterring spam. | ||
* Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data | * Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data |
Revision as of 04:12, 2 July 2013
Design goals
Fully decentralized, anonymous, secure identity.
A SIN ("System Identification Number") is the unique record identifier by which this identity will be known.
Attributes:
- Ownership may be digitally proven
- Start as anonymous; opt out of anonymity by attaching identifying key-value pairs (real.name = "John Smith", gov.us.ssn = "123-45-6789").
- Disposable
- All key-value pair updates digitally signed by SIN owner (key holder)
- Third parties may offer digital attestions:
- Identity Verification, Inc. digitally signs a SIN as passing their Not A Criminal/Level-1 check.
- Big Auction Provider, Inc. digitally signs a SIN as having a certain reputation score, on their website.
- Decentralized market users digitally sign one another's SINs, building a decentralized reputation
- Has some creation cost, deterring spam.
- Sacrifice may be digitally proven, bootstrapping root of trust from blockchain data
tl;dr: A “master public key” generated by the user forms the root of digital trust.
Creating sacrifice transactions
Creation cost is attached to decentralized identity by means of sacrificing a small amount of value.
An implementation of Announce/Commit Sacrifices. That author's feedback on this protocol was very helpful.
- MPK = master public key
- BH = current block height
- Create and sign transaction T2. Broadcast if desired.
- must include Hash160(MPK) OP_TRUE anyone-can-spend output with value >= 0.001BTC
- nlocktime = BH + 144 blocks
- no more than 1000 bytes in size
- Create, sign and broadcast transaction T1
- must include OP_RETURN serialized(T2) output as last txout
Creating a SIN
- Prefix = 0x18 (mainnet) or 0x19 (testnet)
- SIN_Version = 0x01, similar to how a UUID's form is dictated by a UUID's self-identified version
- MD = Hash160(MPK)
- SIN = base58_encode_check( Prefix + SIN_Version + MD )
- Hyphenate SIN for easier human reading
Validating the root identity information
- B1 = block w/ T1
- B2 = block w/ T2
- Verify B2 height - 144 >= B1 height.
- Verify announced T2 is valid
- Verify mined T2 spends same inputs as announced T2 (not equal to account for Transaction Malleability)
- Fail and waste sacrifice if not.
Thus a minimal root record is MPK and is provably
- linked to the sacrifices
- MPK starts a new chain of digital signature trust, for further record updates
Future work
After creation, the root identity and key-value pairs must be stored $somewhere.
After that root identity is created, additional key-value pairs may be associated with the root record via updates verified by MPK, stored in an alt-blockchain or DHT somewhere. That is outside the scope of this minimal document, at this time.
Key attributes of this system, like price and transaction size, are hardcoded. It is presumed that version 2+ will improve upon this, once field experience is gained and lessons are learned.