Manu: I work at Digital Bazaar, have done standards work at IETF, W3C around payments, verifiable credentials/claims
<manu> Presentation (with PDF)
Manu: We'll start with high-level
concepts and then dive into details
... Credentials then to decentralized IDs
... and get even more specific to talk about one particular
blockchain for decentralized IDs
... definition of credential - anything you might put in your
wallet (information bout yourself)
... Verifiable Claims (to become: credentials). We want to make
it easier to express these on the web in a way that is secure
and privacy respecting
[Slide 4 - example of a credential]
scribe: the WG is working on a
standard data model for expressing these credentials.
... work has been around for 3-4 years, but the WG has been
around since May 2017
... we hope to have the test suite done by Q3 and then advance
to Candidate Recommendation
... 10 commitments to implement
dezell: What does implementers
mean?
... client software? infrastructure?
manu: I am talking about
implementers at the business level - they will use software
libraries and integrate into applications
... I'm not talking about the infrastructure
implementation..the more challenging thing is to get businesses
interested in using it
... so there are 10 businesses that are experimenting with
proofs of concept
Manu: You need to tie information
about a person to an identifier
... we have traditionally used identifiers such as HTTPS URLs
or email addresses
... we've used social security numbers
... etc.
... but the general problem is illustrated in the equifax
breach
... these identifiers that we've used are problematic because
they don't belong to the people themselves.
... (That has to do with DNS)
... we pay the price of lack of portability, privacy issues,
data security.
... the way that DNS works on the Web is that we lease our
identifiers
... which leads to problems
... the proposal here is Decentralized Identifiers (DIDs)
... these are lifetime portable identifiers that you (or your
organization) owns
... does not depend on a central authority
... these identifiers are protected by crypto
EXAMPLE => did:example:123456789abcdefghijk
components:
"did:"
<did method>
<did method-specific string>
Manu: Users are not intended to see these identifiers (just as we don't see IP addresses)
<Arnaud> timbl thought humans wouldn't see URLs...
ivan: When you say
"cryptographically protected" what does that mean?
... E.g., I can use Orchid in publishing community...ISO has
ISNI
... what is the fundamental diff between those and DIDs?
Manu: How can I verify you are
you?
... public/private keys help ensure that the person who hands
me an identifier is the person who has the private key
... what is different here from traditional PKI is that DIDs
have a decentralized lookup mechanism.
... that let's me automatically verify a message from you
without out-of-band prior negotiation thanks to the lookup
mechanism
reto: My first question - if I
want to know you are Manu you can show me a passport and I
check out the picture, etc.
... if I see that you have a private key matching a public key
on a blockchain (presumed to be there forever)
... how does it prove you are the Manu sporny that I think you
are
... doesn't there need to be an authority that I trust that
says "This is Manu because this authority vouches that this
public key belongs to him."
Manu: This is where verifiable
credentials comes in
... the crypto is for enrollment / set up
... verifiable credentials need to be exchanged to gain
trust
... I might ask you for a set of credentials such as "a photo
that Ivan vouches for"
... since I know what you look like in life, I can ask for
verifiable claims such as a photo. That does not guarantee
anything but increases my confidence
... if an organization wants to know that you are an employee,
or a licensed accountant, I can ask for credentials
... that identity proofing happens at the credentials
layer
... the DID layer is just to secure the underlying
information
... DIDs use blockchains/decentralized ledgers as a way to
register and look up information
... most identifiers prior to this have been centralized
... we have a spec (Decentralized Identifiers) from the
CG)
... we have implementers (6 listed on table, including Veres
One which we will look at today)
... this is the first spec bringing together blockchain
companies/efforts for interop
IJ: Is method mapping centralized
in the CG?
... that part is not decentralized.
<reto> "Since DIDs are intended for decentralized identity infrastructure, it is NOT RECOMMENDED to establish a registry of unique DID method names."
IJ: DID resolver
<reto> above from: https://w3c-ccg.github.io/did-spec/
Manu: DID resolver knows what system to resolve to
IJ: Who owns the document to map?
Manu: Anyone can write software to resolve things...it's just documentation
reto: It goes against the spec (which says it's not a registry)
Manu: People can choose to ignore
it.
... it's for people implementing DID resolvers
... but it's not authoritative
... people can write whatever DID method they want
... I don't quite understand the concern
... there is no central organization in charge of the mapping;
developers can ignore it
IJ: We can discuss later but my main question over the whole presentation is whether the resolution is really decentralized
Manu: There is no single implementer for resolvers
<sandro> ij, I'm with manu on this -- nothing is every 100% decentralized -- you have to actually do threat modeling to understand which harmful aspects of centralization remain
IJ: I am still trying to understand. Right now it seems that if resolution is centralized, it's a lot like DNS.
<Arnaud> there is a possibility of clashes over the method names though
IJ: It seems that way (re: risk of name clash).
[Slide 17 who is involved]
Veres One (v1) is a DID method
scribe: "a globally interoperable
blockchain for identifiers"
... vision is for people to control their own own identifiers
and by extension data
scribe: one problem is that identity siloes
[Slide 23]
Manu: A variety of blockchain
governance models can apply
... permissioned/permissionless, public, private
... Veres One is custom built for doing DID management
... we did not do an ICO for the Veres One blockchain
... we want to make sure identifiers are inexpensive over the
long term
... cost of a single transaction on bitcoin can be
$15-$70
... with Veres One the cost is approximately $1
... commoditization of identifiers should drive down
costs
... furthermore, since this blockchain is custom for DIDs, you
can optimize transactions; 18M transactions per day
... the consensus delay is about 30 seconds, compared to 3600s
for bitcoin or 375s for Ethereum... we did a Beta in October
and expect to go into production in June 2018
... each ledger that we are talking about has a DID
Method
... this is how the DIDs are implemented on a particular
blockchain
[Map of global server system]
scribe: Manu: the summary for Veres One
is that we have verifiable claims going on in W3C, and DIDs in
a CG, and we have multiple implementations and specs
... at some point we are looking to create a WG ... the W3C TAG
is going to review this over the next couple of months
dezell: How are you getting the speedup?
<sandro> Arnaud, as I'm understanding the system, it's essentially harmless to have name conflicts, since only one of them will actually resolve properly. That is, if five different systems used the same method name, resolvers could just try all five and the crypto would only verify for one
<Arnaud> sandro: correct but it's not exactly optimal, is it? :)
<Arnaud> sandro, there is still an expectation that it is unique and as far as I know it's very much first come first served
Manu: Different consensus algorithm since we are not a crypto-currency
<sandro> Arnaud, Yes, I'm just saying I don't think name-conflict is a significant threat. The system can defend against it easily.
<Arnaud> ok
<Zakim> dezell, you wanted to ask why Veres One is so much faster
<Zakim> dom, you wanted to ask about (prospective?) consumers/producers of DID
dom: Thank you for the presentation. Can you say more about whom you expect to produce/consume DIDs and their biz motivation?
Manu: We believe that people will
have digital wallets and personal data stores
... verifiable credentials, coupons, payment instruments will
be stored
... those digital wallets, if they want to be
"self-sovereign"
... they will need to get these identifiers somewhere
... we believe that DIDs will be picked up by personal wallets
and personal data stores first
... there are also a number of other organizations that are
looking at DIDs for IOT
... government to corporate communication is another use
case
... we've been working with the US Dept of Homeland Security
Science and Technology Directorate (DHS S&T) and other
orgs
... British Columbia is funding work in decentralized
identifiers for gov-to-citizen and gov-to-corp services
... that's where some of the early work is being done
sandro: I have lots of questions...where's the right place to go for 30 minutes?
Manu: Happy to chat
... the credentials cg is actively developing the spec
... so for questions about the spec or challenges I suggest
interacting with the credentials cg
... email to the CG, for example
sandro: How do you handle password recovery?
Manu: Good question. Also key
recovery
... if you lose your private key and you have no recovery
mechanism, the DID is gone forever
... so a lot of wallets are focused on doing key recovery
well
... we are looking at social recovery mechanisms like "three of
these five friends" or "BOTH google and facebook"
... so there's a lot of work around account recovery
<Zakim> reto, you wanted to ask why control identifiers leads to contol of identity data
reto: I also asked questions on
ac-forum (won't re-ask here)
... regarding the assertion that because you control identifier
you control your data
Manu: How do you make the jump
from "control over identifier" to "control over identity
data"
... the theory is that if you have an identifier that you
control and other orgs tie data to it
... you control the use of the identifier (rather than some
other party)
... the theory is that people will choose digital wallets that
enable you to take your credentials and port them to another
wallet if you want
... verifiable claims flow around the network a lot
... the idea that you won't be able to access them is unlikely
to happen
... by using an identifier that you truly control, you will be
able to move data from one store to another and not affect the
ecosystem
<Zakim> dezell, you wanted to ask about potential $1 cost for digital offers
dezell: $1 per transaction can be high for some types of transactions (e.g., coupons)
manu: Governance around the
ledgers is uncharted territory
... the board of governors of Veres One has a mission to drive
down costs, largely today based on rental of cloud space
... we don't think coupons will have DIDs
... coupons can be UUIDs
... you can tie the coupon to an identifier..but I think they
are a good use case for verifiable credentials
... you can then attach it to a person who has a DID
Ivan: What happens if I want to move from bitcoin to veres one? Don't I have the same identifier migration issue?
<dom> [I understand Ian's concerns about centralized methods better in light of that question]
Manu: The hope is that attaching
identifier to utility is better than attaching to a
company
... but you are correct, we've not created cross-blockchain
identifiers yet
... Any further questions? Email me or the CG; join the CG!
[Thanks Manu!]