Internet Identity Workshop 2016-04-26

Welcome to IIW - we have a special guest keynote today

A couple of months ago at BYU @dsearls gave an opening talk, and that set the tone for the unconference -that worked

12 years ago Kim Cameron of Microsoft defined the 12 laws of identity - I asked him to talk and update these laws

It's intimidating to be here with so many people who are key to my understanding of identity

The laws of identity weren't written by me but by a whole group of us https://www.identityblog.com/?p=352

the goal was to codify what I know by identity—Doc had just introduced me to the web through blogging, so I used my blog

at the time the world of identity was fragmented and talking on a blog helped have a conversation in public #indieweb

The internet was built without an identity system which is like building a house without plumbing

the internet was a patchwork quilt of identity one-offs - everyone went to their basement and hacked things up

at the same time the criminalisation of the internet was a huge growth industry

It was also clear that there wasn't a single identity panacea

we wanted to have identity for the whole internet, not just for a Facebook, a Google a Microsoft

So it had to be a metasystem, not a system; it had to incorporate previous systems

So we talked about "claims" - as opposed to the previous model of "assertions" that applied to a domain

the problem of determining what claims you believed was an important one

You can't just say you'll accept what identity providers say, you have to have of model of belief

All of the world works on claims now, which were baked into SAML and OpenID connect and so on

a digital subject is a person or thing in the digital world that is being dealt with

a digital identity is a set of claims made by one digital subject about itself or other digital subjects

self asserted claims are important - that is the basis of sovereign identity

I hate the past and ignore the present I live in the architectural conditional

I started as a physicist, so I propose laws with the goal of testing them to see if they apply

the 1st law we put forward was User control and consent - not drive by actors in the sky but users

2nd law was minimal disclosure for constrained use - not splattering your information everywhere for everything

you just release what you need to do a transaction, not everything about you

3rd principle was justifiable parties to a transaction - only include parties that need to be there

4th principle: directed identity - don't use universal identifiers for a specific transaction

5th law is pluralism of operators and technologies - interact via claims to bridge both

6th law is Human Integration - be aware that humans are part of the system - people have protocols too; relate to them

7th law is Consistent experience across contexts - if every site works differently the users won't know how to use it

what I do on my website should not be connected to what I do professionally, or to my credit cards

My sympathies with the armed forces who are forced to use their social security numbers as their service numbers

combining information with a common key like a SSN violates lots of laws of identity at once

the big mistake I made was not understanding the asymmetric power of the parties

the user, the identity provider and the relying party (service provider) have different power dynamics

we had an idea of identity cards to choose from so that they can use their personal or business identities

Google has done a good job of making this model work for logging in

The Relying parties were busy counting clicks, and they didn't want to add one to log in remotely

I hadn't understood how much control the Relying Parties had over the expereince of the users

the 2nd thing I didn't understand was the multiplicity of the sources of claims - not single identity providers

the relying parties want lots of different claims from many different sources - user, location, own systems

they may want claims from attribute verifiers; they may want to send claims out to other systems

both identity providers and relying parties need relationship management - arbitrating claims between providers

the relying party needs someone to manage their relationships; equally important is managing it for the individual user

I mentioned the relying parties first because they have all the power, but we need to care about the user experience too

the level of complexity brought about by criminalisation is too high, so we need specialists

I expect there to be Personal Identity Managers to be run on behalf of users

because of the need for specialisation there will be concentration of systems for relying parties and for users

hopefully these systems will be content-free - not using their concntration to prevent innovation

this concentration creates a huge danger

decentralisation is a great counterforce to this

I'm encouraged by blockchain as the operator is disposable - you don't have to take the word of some VP

This unconference process realising that most of the interesting things at a conference happen outside formal talks

I'm doing a session on Intro to the indieweb, and how Micropub and webmention are being standardised

I want to talk about #CHEDDAR the successor to do not track, taking ad blocking into account

I am deeply involved with blockchain but it is definitely overhyped.

We really don't want to put identity on the blockchain

bitcoin is a permissionless system - no-one can stop you mining or transacting

on the permissioned side there are different groups that need permission for certain roles

the different consensus protocols are about who gets to be the leader: PAXOS, POET etc - blockchain it's mining

what I need to know to suggest a consensus algorithm depends on the roles and number of players

if scale is locked in at the beginning, what happens when you mis-estimate it?

if just you and I have a transaction, there's no reason to use a blockchain

Under your research, what did you find that blockchain wasn't suitable for?

There are use cases for things that need to expire - must go away after 7 years - blockchain is too persistent

our identities do change, and we don't always want them to persist -think of refugees fleeing persecution

there may be existing signing agencies, trust agencies that you would prefer to the blockchain

if one of the requirements is compliance with the right to be forgotten or deleted, a persistent history is bad

if information has to be revocable, that doesn't imply that it will delete all copies

You could use blockchain for key distribution and unique identifiers, not for storing volatile information

if a database solves it, we don't need to be told about this - what new ideas are there?

a blockchain identity is first come, first based - bankers say you can't fix a mistake or reverse a transaction

a secure blockchain needs a very high amount of traffic - it may go away if there is too much bickering

Bitcoin is based on a proof of work that is hard to game, but the work provides no value in the world. Is there one that does?

Blockstack's system is blockchain agnostic - it can work on bitcoin or other chains

you don't necessarily want work that is useful, as that makes it more gamable

blockchain can't do small trust - other things are a lot easier.

zero-knowledge proofs can do a lot that don't require blockchain

you can't use blockchain for ephemeral trust the same way that you can with OTR

where rely on an oracle you can't use blockchain as it adds an external dependency

say I have a website and I want future blocks to depend on that site - if that is removed blocks can't be validated

we understand problems with very large like bitcoin and things under 50 where paxos works but there are edges

anything with latency requriements doesn't work on blockchain

do you rely on immutable ledger or consensus protocol? You could have a triple-signed receipt to reveal proof

if you need to revert a transaction a year ago, you can't

you can revert by creating a mirror transaction but it leaves a record.

if you are logging a history, you can do things like certificate transparency rather than a blockchain.

turing complete computation is not necessary for the blockchain, but you can just log the verification

reading the board I see that blockchain is not good for small, trust, medium trust or large trust

I work with ledgers all the time, and a big issue is converting from one to another

if you take it from a go forward basis, migrating onto a blockchain means you don't have a creation history

I have seen the size of storage be an issue so I am worried about the ever-growing size of the chain

with Segregated Witness we are moving the signatures away from the transactions to use less data

there are models where you mark a point in time and forget everything before that and move on

the root of this capability is to have a ledger; if you have something done with a ledger it might be a candidate

if you have a distributed consensus you could just store hashes

there are a lot of things implied by identity that don't belong on the blockchain

we're working to making sure that you can't put anything human readable in the blockchain itself

there are different kinds of blockchains that have different properties

you could replicate ICANN in blockchain by having a federated namespace that you delegate through for domains

what we are getting at here is the blockchain microkernel - what is the minimal thing we need for the blockchain to exist

I carea bout how big blocks are and how fast they propagate, and the federation model; we can simulate anything else

other forms of leader election have problems when the parties are changing a lot - eg Stellar is vulnerable to changes

if you roll your own encryption it's usually a bad idea; is the same true of a blockchain

last iiw the argument was blockchains was for everything, now we're seeing scepticism which is interesting

that was why I proposed this

What are the things that you can get with the blockchain that other tools provide

don't be on the bleeding edge of blockchain; there are lots of things you can do without that

with 8 parties you could ahave a round robin consensus model and still have a blockchain ledger

if someone comes up with something better than proof of work we'll shift over

Blockchain is not provably collusion resistant - the 2013 fork resolution was solved by collusion

is blockchain resistant to bad implementations?

there's 7 billion dollars of reward if you can crack bitcoin

well, there's the ability destroy 7 biillion dollars if you crack bitcoin; you don't get them

bitcoin is arguably antifragile as it absorbs a lot of attacks

what blockchains are bad at is like what databases are bad at - they need to be part of a system.

some people have talked about storing data in the blockchain - that has always been a bad idea

there are things created in blockchain that don't have to be used in it - multisig and hd signature are examples

Merkle Trees are cool