<wseltzer> Slides compendium: https://drive.google.com/open?id=1vnlhkrLUe7yap6g7-cBvkQIHL_NphUr7
<scribe> scribe: manu
wseltzer: Welcome back everyone,
we're tracking all input, we're going to start our day 2 of the
workshop.
... We have taken cards from yesterday into
questions/statements and we're going to do dot voting on
those... Kaliya will explain what we're doing next.
... Great agenda of additional talks/breakouts - exploring
cultural perspectives, avoiding mistakes/minefields, breakouts
discussing ideas, one of our goals it to help W3C figure out
what we should do next.
... That might be community groups, to incubate work, it might
be working groups to standardize work, it might be work to be
sent to other organizations, or input to other W3C WGs.
... A key takeaway here becomes the next directions of what
we'd like to collectively do next with all of this input.
... Lots of place for discussion in the roadmap, where we see
the future and how to get there. We wrap up at 4pm today so
folks can catch flights.
... I heard lots of great ideas and still lots of tension,
concerns from folks focused on authentication that the identity
isn't necessarily tied into authentication, concerns on
identifiers (work being characterized wrongly, misunderstood) -
if we're not looking at the right use cases, people come to
different conclusions. We have time to work out differences in
understanding, where is the agreement on the components of the
stack?
... One outcome could be that we're trying to solve different
problems, perhaps the technologies can coexist... we can offer
insights to one another even if we're not working on the same
piece of the problem.
... If we have issues with things others are working on - let's
focus on constructive criticism, how can we all help to make
the Web work better by building the right components around
authentication and identity.
Kaliya: We took output from
conversation yesterday and crystalized them into some
statements and put them on these forms.
... This is what the form looks like --
https://mit.webex.com/wbxmjs/joinservice/mtg/4e2f2c8c6aa2499fa4ff57e9e961581e?siteurl=mit&token=QUhTSwAAAARf3CNiSOA6s0HZ3erSbDBOP66rOlYCkn5W7aVxIveavX38e6v4v69VBCfgpENyvFVQSicO77PRbxUj8ULyazR0saTn9WaL%2BsFLlct6mYbYIKS2tGVk%2B0dpO%2FVA%2FxN5OlqHo05BvR1oGcR9ZJ%2BV9FpYjl96PBCjjqgN%2FXFT8bt4df2qFGns%2FHVmEwxreObvVxc%3D&userName=Manu%20Sporny&userEmail=msporny%40digitalbazaar.com&CSRF=9e99ffe4-85ca-46c2-bd28-17a6b6b8ee10&t
ouch=1544547439705&pgvDone=1544547439706&joinmethod=thinclientjoin&endurl=https://mit.webex.com/webappng/sites/mit/dashboard
Kaliya: Write your initials and then put a dot -- one dot only -- agree or disagree, add comments, and signatures - do not vote twice.
achughes: Do we vote on all cards?
Kaliya: Please vote on each card,
we need to gather input - even if it's "I'm confused."
... Go around and vote - right now.
Scribe notes 55 people in the room doing the dot voting.
Scribe notes lots of discussion around voting/input.
wseltzer: Ok, thanks for the
input on the proposals... the Program Committee is going to
take a look at the feedback and try to synthesize items moving
forward.
... Next up are presentations on Cultural and Economic
Perspectives... followed by avoiding mistakes/minefields
discussion.
Slides -- https://docs.google.com/presentation/d/1hhcDys1nrHtBeAX89RQiWvYWB4bwojVOKH0aIaPXaIM/edit
Takashi: Hi, Takashi from JCB -- before starting presentation, just noting that I am not a native English speaker.
Slide 2
Slide 4
<wseltzer> slide 5
Takashi: In ecommerce - in B2C -
Amazong is close to Rakuten.
... There are a number of fragmented identity platforms iN
Japan.
... Also, differnet payment methods.
slide 7
Takashi: Big Japanese companies
have siloed solutions - six big companies - user has to know
timetable... but just redirects to companies website.
... Driving license has a dominant position in Japan... as an
identity mechanism.
<wseltzer> slide 9
Takashi: Japanese government want
to expand usage of "My Number" card for Japanese Social ID
System... but most Japanese people don't use this card - only
10%.
... We have a strong need for loose ID federation in Japanese
Market...
Slide 10
Takashi: Large companies seem to
want to take a dominant position on Social ID...
... Governments seem to want Drivers license style
approaches.
... To achieve this, we need a scheme for DIDs and Self
Sovereign identity especially consent management.
... Thank you for your attention.
MikeJones: Mike Jones from Microsoft, I know that Yahoo Japan and KDDI implement OpenID Connect. Are they using that to interoperably login at other Japanese sites, or is it mostly silos even though they are using that federation protocol?
Takashi: Interop is not so great, in Japan, every company uses Social ID using Yahoo, ??, Facebook, and NTTDoCoMo...
shigeya: Let me talk about structured IDs, little different from user identity
<wseltzer> [presentation starts at slide 13]
shigeya: you know about bar codes
(slide: bag of mints -- comes from GS1)
... GS1 - they do the UPC - GS1 has a database...
... GS1 standards - identify, capture, and share - slide 16
Slide 16
shigeya: There are multiple
formats to identify, capture, and share... barcode is only one
of them, can be expressed in URLs.
... GS1 has identification keys - domains... trade items
(GTIN), logistics (SSCC), Assets (GIAI), and locations
(GLNs)
... Companies assign GLNs to locatins like factories...
examples of GS1 identifiers.
... These are all expressible as URNs... urn:epc:id:...
... These are not DIDs, but they kind of look the same,
different domain.
... There are also physical representations - barcodes, RFID,
there are different formats/syntaxes.
... So let's look at applications... GS1 Lightweight Messaging
Standard for Verification... RESTful interface to resolve GS1
IDs... use case - US Drug Supply Chain.
... We're interested in using Verifiable Credentials for
this.
Slide 21
shigeya: Here are some
difficulties with resolution services - Object Naming System...
DNS based pat of GS1 key to server mapping... not used other
than for research purposes.
... GS1 Discovery Services - centrlaized - map keys to servers,
suspended until well-defined demands from industry.
... but lately, there is renewed interest in mapping between
identifiers and associated data, together with verification of
identifiers.
... GS1 is the standard on product and business entity
identification,DID focuses on digital identity, we need a
cyber-physical link other than humans.
... DIDs could be used in the "id" fields in DID related
standards.
... There is a good intersection between DIDs and GS1 work.
Pam: You talked about resolution and mapping - are those different things in your taxonomy?
shigeya: Mapping and discovery is
... different.
... RFID is ... RFID leaks information... but information
record is somewhere else, stored on the server, that
information may be on a single server or multiple servers...
discovery service integrates all these data flows together.
Slides -- https://docs.google.com/presentation/d/1f9BW7lFdqcMZsZ08V1Mm0PV9J3aNC28q0JGRzgNneNE/edit
Pindar: What can this technology do to make things faster, safer, cheaper... what can it not do?
<wseltzer> Pindar's slides
Pindar: What about NETizen eXpatriates -- people that want to transact across borders.
Slide 2
Pindar: There are more people on
this circle than the rest of the planet... lots of people
... 50 billion machines coming down the pipeline.
... The Right to Work Online -- cannot be done w/o this
technologies...
... I work w/ displaced people - there are more people
displaced today than after WW2... 70M
Slide 3
Pindar: These people are away
from their home countries... global climate change makes it
worse... legal certainty - do they have it... these people are
going to grow to 700M in the future
... There is a potential billion person market here covering
... what about the lawful approach (there are non-lawful
approaches to solve these problems)
<wseltzer> "We're all migrants, we just don't know it yet"
Pindar: Examples of this, after
WWI, if your country no longer existed, passports doesn't work.
How can we create a "Right to Work Online"? It's not a
Sovereign view, it's not about borders, it's about
topology.
... How many people are in My Number? 10% of Japan.
... Aadhaar is over 1 billion users... great stats, interesting
ruling on constitutionality.
... Aadhaar has issues, but it's deployed.
... 50B devices online - we need to be concerned about
scale.
... There are other mechanisms in China - Social Credit System,
Real Name Electronic ID, Fintech, Common CLOUD.... identities
issued by governments to citizens.
... There is the Belt and Road Initiative - when you cross
borders, law is defined by borders - when you cross 65-68 legal
jurisdiction... Hong Kong is looking at digital roots.
... We have 3-5 times more internet capacity into Hong Kong
than all of China combined - how is this leveraged?
... What is the competitive landscale, market structure,
business models... what are the fundamental tensions between
geography and topology?
... We are mixing fire and ice - government issued - year
1648... in Hong Kong year 2047 -- self administered
... No nation below mathematics... physical border in
borderless world... self-administered IDs...
... Here's the belt and road blockchain - only deals w/
corporate identifiers, legal in switzerland, identifier system
for corporates, self administered IDs, the most important thing
is Self-Administered IDs, why do you need them?
... Companies don't have a right to anonymity - they have to be
registered, they have to pay tax.
... We need a golden source of data, we need to know where law
applies, that's one of the things that Hong Kong is famous
for...
... As a technical community - consistency - Hong Kong - golden
copies, grounded by government institutions, use it, assign
copies of data, have less legal responsibility and
liability.
... to scale cloud services, need identifiers system to allow
different cloud systems to scale.
... This is why we call them Self-Administered Identifiers -
corporates/individuals... Sovrerign states - Fire... dynamic
violence.
... in our Internet view - borderless... ice...
cryptographically strong static violence...
... We need to understand consent - freeze, not move -
different property that does not require rule of law -
... legal certainty - many of us that do contracts don't see
the light of day - computing engine of court system - interpret
run legal code... computational code - cryptographic
consistency - we can have a different type of discussion.
<wseltzer> [slide 16]
Pindar: Fundamental assumptions -
distance != cost, centralized != trusted, time != money
... What are assumptions implicit in our discussions... -
digital trade and digital work online is different.
<wseltzer> [slide 18]
Pindar: We've had Cyber Monday /
Black Friday - different by an order of magnitude.
... Singles day is way bigger.
Tom: We've been doing work in Kantara - a Trusted Identity
<wseltzer> Tom Jones and Mary Hodder's slides
Tom: What you see when you look
at this, Authentication of a User has to be different ...
Decentralized Identity on steroids - pieces of identity are
spread throughout space.
... How to bring things back together again... talks to strong
enough idea that we're trying to present to this group.
... Authentication and Authorization - separate and needs to
stay separate.
... WebAuthn comes up more like Authorization...
... The idea is that in this use case, pretty high assurance
that someone is over 21 if they need to buy some alcohol or
some other restricted element online.
... We're going to talk about these 4 actors - consumer that
wants restricted resource, supplier that has resource, verifier
of claim of majority (sort of like Verifiable Credentials
meaning), this verifier can validate binding between user and
claim.
... I'll try to use validate when I say that and verified when
I say verified claim.
... What about the right of a regulator agency?
... One of the most interesting cases is DEA position on
drugs...
@@@: When you say regulatory agency, do you mean provider of claim?
JohnB: What requirements are there?
MaryHodder: For state of
California, board of brewery, had to do a deep identity
verification for brewing... tap room, physical location, sell
things through website and people can come in and pick up...
brewing operations, they spot check, they don't look at our
records for every single sale.
... Often people flash a license... employees ar edoing that
check, there is no recording except through website
purchases... no one is even providing this.
... They are literally clicking a button, which is not good,
flashing license... but there is no real recording/requirement
that feds and state of california require for alcohol
purchases.
Tom: If you are buying alcohol,
you can have different requirements for different types of
purchases.
... The specific rules differ by state - online use case, they
will try to find rules that will work for all states.
... Last part - provider of late binding tokens and client-side
code.
... Smart card, TPM, etc. precondition is that you have a
consumer that has a late binding token that has it, they have
an over 21 claim, and finally they have a consumer that already
established an ID with some supplier.
... They are already online... that's where we are ... two
different use cases to look at this - supplier sends request
through user asking for a claim... user has a claim... user
sends it back.
... It's not verified - typically, supplier ... use late
binding token to be attached to claim, late binding token is
attached.
... If you are an OpenID person, this is just front-channel
authentication... at this point, we have provided a service to
supplier, we expect supplier to receive validated claim.
... This is small, 5-10 cents - standard practice - fraud
detection circuit.
... Second scenario, something that looks like a back channel -
consumer himself has to go and get validated claim.
... Gets validation, gets claim, supplier gets it.
... This is traditional advertising model... bound to
session.
... Fail paths - fairly obvious, user doesn't get verified, or
fails validation at supplier
... The real point is that the user gets to decide what
attributes he sends based on what he's doing at the current
moment.
... Examples of what could be used, client side code
... users shouldn't expose stuff to websites ... so we need a
way for websites to identify themselves... trust federations
apply to what we're talking about... alcohol... drugs,
different rules, different conditions.
ChristopherA: The VC and DID
community has been using the "Over 21" story over the last
couple of years.
... There are major differences in some places - for example
item 6 - we're not trusting that the user makes the choice, the
absolute minimum inormation should be given.
... Data Minimization story there.
... There is a separate selective disclosure story - there
shouldn't be a backchannel where the bar can correlate
information.
... This is in our whitepaper on data minimization an
dselective disclosure and how they're different... in the VC
group, and DID group, we've decided to drop this story... over
21 is too complicated, doesn't always apply, it's problematic.
We've gone to university alumni and university degree.
Tom: I understand that this is a broader scope - take the claim, moves to higher plain,
ChristopherA: We would be happy to share with you on this stuff.
wseltzer: Thank you very much Tom and Mary!
<wseltzer> [15 min break]
<weiler> scribenick: weiler
\/
jeffh: I want to throw out ideas and be provocative.
<wseltzer> JeffH's slides
[protocol & system design time]
scribe: need to carefully define
terminology and use it consistently. WebAuthn spent much time
on this.
... best to fi this at design time.
... In directory days (95-96 ---> 1998) "names" and
"identifiers" were often swapped.
... e.g. names are fungible and non-unique and identifiers are
unique and persistent.
... In implementing this ina RDMS, we threw out the X.500 idea
that DN's are real names. We jammed UUIDs in the DN for people
entries. and never revealed it.
... so when users entered a name in a form, we did not map that
to a DN and do the lookup - we did searches instead.
... The thing that made this work was that the UMich LDAP
implementation was fast.
... At COMPONENT implementation time...
[cites "Most Dangerous Code in the World"]
<wseltzer> https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
scribe: Much of this has been
fixed.
... at DEPLOYMENT time:
... are underlying techs secure (see above). need a carefully
designed deployment architecture.
... I asked advice from deployers of federated systems....
[slide on Deployment Time]
scribe: Failing to check
results.
... Assuming that a 'principal name' is an email and not
checking it.
... eduPersonAffiliation don't mean the same thing at all
sites.
... different sites may have different rules; danger in
assuming commonality.
... other federation members may not follow BCP's.
... users get confused.
... Overall: trust does not scale (across arbitrary policy
domains)
... SP800-63-3 is an attempt to define these for USG agencies
and might be a model for how to have uniform policies across
relatively disparate orgs.
... Consider a simple design with simple use cases, expecting
it to evolve.
... Build something malleable. and that has utility.
[slide: flexitility]
tony: you said 'take things small' - there is a limit to how small you can go...
jeffh: do something useful.
tony: even small could be useful, but has no context
jeffh: e.g. use U2F - doesn't get rid of passwords. We learned a lot that we took into FIDO2, where we're tryign to satisfy the passwordless case. that's an example.
tony: what if we just defined the message payload, no transports.
jeff: what do you do with that?
write an academic paper.
... I think you start with a basic use case
jim: re: reference to publication (NIST) - is this something w3c buys into?
jeffh: in commercial world, it's a good example to pay attn to .
dirk: i like the distinction in phases. focusing on spec writing: any juicy examples of terrible specs. and also good examples?
jeffh: OpenID1 is an example of
something we learned from. I compare it and SAML in a doc from
2008 - I characterize OpenID1 as a chunk of forged metal.
... you cannot profile it or change it around. It only works
one way.
... you learn from that. OAUTHv2, OIDC have many components -
they're more like molten metal. a Profile is a mold; you can
reshape them to do something new.
Dirk: OpenID1 was concevied by a small set of people. do you need to have a larger group?
jeff: as you iterate, you bring
new use cases in. if you have something that can be extended
(is malleable) to fixe new use case, that's a good thing.
... you're unlikely to be able to satisfy all use cases.
mike jones: I agree re: the centrality of iteration as well as "do something small". build the smallest deployable unit, so that you learn.
scribe: if you reach that kernel,
like open ID1, which morphed into 2, you learn things.
... most humans are not capable of entering idetifiers as URLs.
So you find email addresses, which people understand, despite
the downsides.
... I agree re: "have core fucntionaltiy" and have extension
points.
e.g. encryption in @@
jeffh: identity federation based
on HTTP was invented in 10s -100s of different places
... at stanford, we invented one. In 1999 Burton group
consultant said "let's get into a room" to merge two competing
standards
... In hindsight, that became OASIS security services technical
committee. something else became OpenID1.
... then OpenID2.
... then OAUTH to authorize services to talk on a users'
behalf.
... then MS and Google came in with new use cases and that led
to OAUTH2
[draws on paper]
scribe: early rat race, narrow
funnel. it's hard to get the planet to decide on one
design.
... Best example are automobile controls. that wasn't
standardized until 1920s.
... I remember a gas pedal in the middle. Right hand drive.
<Zakim> burn, you wanted to mention standards as process of attrition
[ https://www.youtube.com/watch?v=MFzDaBzBlL0]
dan: standards is a process of
attrition. once you build something that is of value to the
group, it can be good to declare victory on that piece. at some
point you'll find that there aren't enough people to keep going
(for now).
... it's easy to overextend on requirements.
... when you don't have agreement.
Jeff: this is an argument for
modular design
... other example is LDAP. We aren't working on it any more,
but we all use it. It's sedimented. You only mess with them
when you need to. e.g. tuning of TCP.
... TCP works. Until you find issues, like buffer bloat.
... but things sediment down and you don't need to pay
attention.
mike Jones: I reinforce your story re: independent invention signifying time for a standard. When JWt finished, there were four different
scribe: formats. we took that as
a sign that we should talk to each other.
... coming into the present day. there are a bunch of people
here working on DIDs and at RWOT there were people saying "I
built DIDs" and people
... were asking "how did you represent keys", what use cases
did you solve, etc.
... which showed they didn't have interop.
... if you want a DID thing that works, you need to make some
choices. Need one way to do X.
... if you want interop. engineerings in bldg 28 next door
looked at DIDs and wondered what to build. it's time to do
that.
Kim Duffy: i apologize that at RWOT that didn't come across
scribe: our pre-standards groups have not done a great job communicating the use cases (like educational credentials). We are actively working on that. we're trying to clarify confusions.
christopher: there's a
distinction between DID itself and @2 and specifics of
indivudal methods. different
... companies have chosen different architectures, crypto,
curves.
... I heard "given the blockchain you're using, what did you
use?".
... another issue had to do with VC, not DIDs - format for
signing VCs.
<kimhd> @weiler -- that's not what I said
<kimhd> I'll correct
christopher: there has not been consensus because W3C limited scope of WG to data format only.
mike: as an outsider, I think it's time to make choices. I think you have to have algo agility, but basic data structures need to be picked.
daniel: to be practical, I think
we need to specify how keys are declared. I think we can narrow
it down.
... that might be a place we can make progress.
... resolving them the same will never work.
... since they're constructed for different purposes.
... they don't resolve the same because they're serving
differernt purposes.
chris: @4 we are not ready to accept that new academic research.
kim: the proposal for the DID WG has only to do with data model and syntax. The cards were a little misleading. the interop part we want to standardize is the data model and syntax.
<kimhd> ^ Correction
wendy: I'm hearing challenges re:
the right level of modularity. I heard @4. It needs to be big
enough to be useful. I'm hearing from VC WG frustration at
scope of charter.
... drawing the right boundaries where we're okay with a group
setting a scope - and thinking about other modules we need to
build. As we move to next phases of discussion, we have lots of
cards to work through.
... I want to do some breakout gardening.
... for our time after lunch.
... on the wall on the R, there are items where confusion has
been expressed. We could ask the room if there's confusion you
want us to address today.
... there are other places where we have general consensus. and
there are cards that show a deep division. would be great
... to address the source of that division. and questions re:
chartering of work.
<aaronpk> scribenick: aaronpk
chris: is it possible to go
parallel rather than sequential now?
... a bunch of ppl are leaving at 4, some sooner, there's a
bucnh of momentum around chartering a DID WG
... we'd like to address the objections
... so spending a lot of time on others is going to stop us
from coming to some closure on the DID WG charter
wendy: there is a lot of interest
in addressing the questions of the DID WG
... and i think we want to address the presentation of
that
... and some of the controversy that came up
... the co chaaikrs of the cg result from a confusion of what
they are proposing
... so it's only fair to let them share what they are proposing
if we're asking the group to give input on whether that's a
good direction
... .and i know manu is actively listening and participating
even though he cuoldn't join us was offering to share some of
his input
... on the roadmap that the DID proponents have for moving
their work forward
... unfortunately manu reports his audio can't connect
<kimhd> it sounds fine
manu: so i can't hear what you're saying at all
<wseltzer> manu, can you speak?
manu: i'm going to go ahead
<wseltzer> manu++
manu: i wanted to clarify some of
the items around the DID WG proposal
... for those not aware, the work on DIDs has been happening
for about 3 years
<manu> https://www.w3.org/community/credentials/participants
manu: in the group called the credentials CG
<manu> https://w3c-ccg.github.io/
<manu> https://w3c-ccg.github.io/did-wg-charter/
manu: community is composed of
225+ people who meet weekly, calls each week are between 20-30
people joining, so healthy and active group, and run
experiements around verifiable credentials and things of that
nature
... about 8 months ago we put together a DID WG charter, highly
focused on data models specifically
... but as i mentioned, the CCG is front-running that work and
doing experiements around protocols and resolutiosn and the
open questions
... one of the things that became claer over the last year,
given we have 15 different DID methosd right now
... there's a desire to greate a W3C WG around the data model,
that's the small step that we believe is appropriate to take at
this point
... we did circulate a questionnaire about 4 months ago to the
W3C membership and a number of other large organiztaions
<manu> Member confidential slide deck on DID progress: https://docs.google.com/presentation/d/1iMH4m_3OQbnyTr-Vrhe2PRECbiWOMjeeym-oL2dyhC0/edit
manu: this is a member confidential slide deck on DID progress
<manu> public one here: https://docs.google.com/presentation/d/18cDpqkPhlGKcOlgnbt2_2PbFoNv0vryXopp5rIG8A0o/edit#slide=id.gc6f80d1ff_0_0
manu: there is a public one that
i'll also share here
... the outcome of this survey, we asked if the charter was
appropriate
... we got 80 responses, a large sample set
... of those 80, we asked how many of them would support and
join, not just support, a DID working group
<manu> https://w3c-ccg.github.io/did-wg-charter/
manu: that's scoped to the
charter we produced
... it is data model only. out of 80, 60 said they would join
the WG
... for those of you who are not familiar with the process,
that's well above what is needed to create a WG
... this is the primary thing that we're trying to accomplish
at the workshop
... to socialize that this charter is out there and has 60+ W3C
members in support of it
... and to socialize it
<Zakim> wseltzer, you wanted to discuss modularity and constraints, utility and to discuss W3C process
manu: so it's not a done thing
but it's a socialized charter
... there are things not in the charter, we don't talke about
DID Auth, we don't talk about DID resolution
... we're trying to pick a small set of work, then after that
go on to the next step
... which could be resolution or auth
... i'm going to stop there
wendy: thanks manu
<ChristopherA> Thanks Manu!
wendy: regarding the w3c process,
the components are support, willingness to work, lack of formal
objections
... or all of the objections to the work have been addressed to
the satisfaction of the w3c director
... so a goal of socializing the work is to get support and
address the concerns that others might have
... so i like the suggestion of breakout and making this more
of a discussion, i'd love to find a way to have manu
participate in that discussion
... but figuring for those who are concerned about this work,
or don't think its the right direction, what would help you to
address those concerns, and what else do you need to hear
... if there's an understanding gap or what would need to
change
mike: mike jones microsoft. i
want to reflect on some of the excellent observations that jeff
made
... about the ability to iterate and standardize
... at least as the charter was just described by manu, it
describes a data structure but doesn't define how to do
resolution or authentication
... and thinking in terms of minimum deployable unit you need
to have all three of those things to have a functionining
DID
... so it seems counterproductive to define a data structure
without defiing how to deploy it in practice
kaliya: as a person who can't get
into the techinical weeds, one of the things i've continued to
hear is we have to scope it so narrowly that what you've said
is out of scope and causes problems
... so if we can figure out how to expand the scope to address
those things that seems like a path forward
tony: defining a data structure
is too small at this point in time
... trying to understand the cardinatlity of the data
structure, how to use the data structure, it will create
confusion out there and create more confusion around the use of
the data structure
... so i do belive that there needs to be more discussion on
these aspects before moving forward
sam: mike your concerns about
just the data structures aren't enough to be deployable...
didn't we hear from jeff that we need to pick from those and
people can build things around it, and then people can build on
that later
... it's timely to do the data structure work, and peopel can
build things that aren't standard
mike: i could be wrong, but i
believe that these are interdependent, that you have to
understand in these cases how it's going to be used to know
what you have to represent
... it's sedgwicks' algorithms book that the opening phrase is
data structures are algorithms, they imply usage
chris: tho i will be the first to
say that i feel overly constrained by the no protocols no
crypto in the verifiable claims group, we did come up with
something fairly solid
... so i would find it acceptable to take that same approach
with DIDs and only focus on that side of things
... if i were to extend it i wouldn't extend it as far as
you've said
... i dont like the name DIDAuth, i would like to have a simple
two party proof of control as a sort of minimum viable test of
a DID
... i do no t believe we should talk about DID resolution or
universal resolving becasuse i think that's going to be up to
the marketplace
... we already demonstrate that works now, there will be market
realities to push people together
... definining a minimum viable proof of control will help
verifiable claims a bunch, it will demonstrate the DID spec
does what we promise, then we will talk with people who will do
three party and more complex structures on the back of that as
separate future working groups
wendy: time check, lunch is coming.
daniel: in terms of the technical
piece, i was curious when you bring up resolution it infers
other things
... resolutions infer other things, we're working on batching
that sticks things in bitcoin. other schemes don't do
that
... the idea that we standardize resolution, we'll run a plugin
that resolves each one, you can't really standardize the
resolution steps because they are inherently different just
like you can't standardize tthe math in a cryptographic
scheme
... so that's how you should in your mind associate a DID
method's logic and what we can standardize
<Zakim> kimhd_, you wanted to ask clarifying questions in case no one addresses it
kim: one thing that's coming up, i'm hearing what's different rules for what's requiered to make a WG
<daniel> You're next
kim: you're mentioning some
criteria of what i've heard before
... christopjher said we need to have a focused data model and
syntax. we've been incubating a lot of these standards, we have
a roadmap.
... one thing that mjight be helpful is to push for some
clarity on what we need for working group formation so we dont'
feel like we're reacting to what feel like arbitrary rule
changes
<wseltzer> https://www.w3.org/2018/Process-20180201/#WGCharterDevelopment W3C Process re charter development
mike: i'm not describing rules for WG formation, i'm describing in my experience as a stnadards developer what you need to do to have the work product of the standards output to succeed
chris: if we were adding one simple proof of control that everyone could support would that be enough?
<Zakim> manu, you wanted to say JWTs are a data format, that's it -- how is that any different?
mike: that's a step in the right
direction, i don't have preconceived boundaries on what the
particulars are
... the particulares may be different for all of them but you
have to write down one or two of them to have interoperable
implementations
manu: i'm disappointed with the
line of argumentation that some of a vocal minority in the JWT
community (mostly from Microsoft) are making... that Working
Groups focusing on Data Models only are not useful
... JWTs are a data model full stop
... in that sense, it's strange to me that doing a data model
is not enough for a WG
... it's a very strange argument
... the second thing is there are a number of companies that
are building and deploying verifiable creds to real customers
today
... this is not a theoretical exercise, there are organizations
involved i nthis work, and i'll note that those taking
exception to the WG are not building these systems
... so as someone who is leading a company writing this code
that having a DID spec in place even if only a data model is
going to help greatly that ensuring this market as it's growing
has something to build off of
... there are other pieces coming in place down the road but we
are taking a very staged appropach to what we're doing
wendy: we are going to break for
lunch
... take an hour for lunch and come back at 1:20
<wseltzer> [1 hour lunch]
<brentz> scribenick: brentz
weiler: we've done some shuffling of the schedule
scribe: any objections? No? Good.
Mathias: Currently doing IoT work. What does attestation have to do with EAT?
<wseltzer> Mathias's slides
scribe: the attestation is that
you are speaking with the device you think you are, iun a way
you can trust.
... [slide 2]
... these are not the only attestation suppliers. As in the
example of the supply chain, sometimes you need to know the
identity of the things you are dealing with.
... There is a working group around RATS, EATS is the
container.
... smaller devices may be limited to 64 kB of RAM.
... [slide 3] different systems have different ways of
expressing claims.
... encodings, assigning keys, running sets of PKIs, for the
policies that will be validated, these are all part of the
trust model.
... my device may be making claims, but we may want those
claims aggregated with others.
... when authenticating to a system, the device can attest that
it meets the appropriate security level.
... [slide 4] when you are talking ot a 3rd party, can you just
trust them? don't you want to go further?
... If they have the proper credentials, but the software has
been altered, that is only one possible problem that
attestation may address.
ChrisBoscolo: are there any 3rd party audits available? is there a way for outsiders to know that the process for making the chips is secure?
Mathias: there are certifications for that.
ChristopherA: Quick DID and VC
architecture roadmap
... two efforts we are tracking [Slide 1]
... VCs allow for multiple sources of information. In order for
many of the use cases with VCs, we feel we also need DIDs.
<wseltzer> ChristopherA's slides
ChristopherA: Hopefully the VCWG
will be wrapping up in a few months.
... There is a need for other things to be incubated [slide
2]
... this is where we allow the flexibility. DID Methods are not
ready to move into specification.
... there has been lots of discussion about what should be in
or out of the DID Document
... [slide 3] Once we can use VCs with DIDs, there are a lot of
use cases and special examples that can be explored.
... there are many questions around protocol and consent that
are unanswered.
... Doubt we will get to the bottom few in the next several
years.
... how do we turn this into a service of value.
... lots of discussion about DID Auth, there is a Rebooting Web
of Trust whitepaper that outlines these.
... [slide 4] OCAP solves a number of problems around ambient
authority.
... Credential requests and exchanges are out of scope.
... cryptographic proofs is a big confusing area, we don't just
use signatures anymore.
... zero-knowledge proofs allow for new and exciting things
that add real value.
... zkp is tough because it is academically and
implementationally challenging.
... [slide 5] giant diagram roadmap
... further down the page are things far in the future.
... one of the tasks of the ccg is to update this roadmap, this
will happen in january.
<Zakim> manu, you wanted to note that all of this is future work once we get DID WG (data model in place) and that all of this stuff isn't happening in a vacuum, we're being very careful
manu: just to clarify, this is a
roadmap, it is future-looking. What we need is a working group
specifically for data model and syntax.
... the other thing to note is that therte are a variety of
things being worked on in the ccg.
... these things are not happening in a vacuum, a lot of work
is going on around these things.
Dirk: how do all of these pieces
hang together? the verifiable credentials and DIDs, how do they
hang together?
... Would the credential be issued to a DID?
ChristopherA: Yes the claim would
be issued to the DID. There are correlation issues with using
an identifier this way.
... the process of a verifier getting the information they need
during presentation might be iterative, leading to trust
between two parties.
Dirk: so, if I only have one DID that satisfies this information, I have to disclose that one?
ChristopherA: yes, there is some
correlation leakage there.
... with BTCR there is a very anonymous scenario where DIDs are
uses more selectively.
Dirk: If I want to prove my birthdate to two people, do I need to share my DID?
ChristopherA: No, the Sovrin solution allows for pairwise DIDs and zero-knolwedge proofs about the claims you are sharing.
Dalys Sebastian: how does DID resolution work from an application developer point of view?
<wseltzer> s/???/Dalys/
ChristopherA: there are a couple
of different approaches. Markus did a resolver that did
VeresOne, BTCR, Sovrin DIDs as a first step.
... it was a plugin architecture that allowed for
expansion.
... interoperability between DIDs is difficult between methods
because the root of trust for resolution is different for
different cases.
... a developer may have a resolver and they would need to
choose the plugins they need to use.
... you may have a number of credentials from a number of
parties.
<Zakim> JoeAndrieu, you wanted to reiterate that proof of control is just a single factor
JoeAndrieu: fetishization of proof of control of a DID leads to poor understanding. There is potentially a lot more to a proof than a single attribute.
<Zakim> kimhd, you wanted to comment on did resolution
ChristopherA: VCs can only prove that someone said something, not that what they said is true.
kimhd: each DID method must say how to resolve it, along with the CRUD operations.
ChristopherA: but all of the
methods have something in common. With BTCR there is a lot of
magic happening on the back end, developers don't care about
that.
... they only care that the resolver did the right thing.
... one more thing, these aren't standards yet.
Greg is up and has no slides.
weiler: we are out of time.
greg: i won't take much time. We
have lots of money to invest. There needs to be a bridge
between standards and implementation.
... one example of our investments is in the Brave token. They
need an identity solution or there will be a lot of felonies
committed.
... Policy context could serve to guide this work. This is the
most political protocol I have ever seen.
greg: encourage you to not be politicized, but be aware that the work you are doing will be weaponized.
John Bradley: Our standards are pretty much wrapped up.
scribe: we are in our initial
deployment phase.
... we now have authenticators out there
... the latest version of Windows 10 has support for the new
tech.
... Google and Android support it.
... FIDO is working with them.
... Shout out to the apple folks who just released their
initial support.
... our next work is divided between FIDO and Web Authn
... we are looking at additional extensions to better deal with
the user experience for lost keys.
... looking at alternative algorithms in the coming years.
possibly threshold signatures.
... right now Web Authn is about proving possession of a TLS
certificate, once all else is stripped away.
... theoretically this could be extended to be proof control of
a DID
... we have a few projects over the coming years, but now we're
dealing with deployment issues.
... Web Authn as a first factor for log in can be done with
hotmail.
... there may be a version of chrome on a future version of
Windows that can use the platform authenticators
... hopefully there will be more sorting out and user
experience improvement.
tony: there are many authenticator key companies out there. Were do you see this going in the next 5 years?
John Bradley: there will probably be pressure on those at the lower end of the spectrum due to fingerprinting possibilities.
scribe: roaming authenticators
may be more specialized into certain roles for banking,
etc.
... a lot of the enterprise smart card stuff should move to
external authenticators
... there are shared device use cases that require external
authenticators.
... there will be room for multiple vendors in the space.
Mike Jones: you mentioned some gaps in DID for use with WebAuthn
John Bradley: there may be some minimal set of things we'd need to decide on using in order to make use of the DID documents as part of Web Authn.
scribe: from a standards point of view, even if someone has managed to get it to work, that may not be quite right.
manu: there is an experiment we
did with Web Authn keys in a DID document, using hardware keys
to sign.
... we need to start somewhere in a DID working group.
... there are many experiments we could do, but there is a base
layer we need to get down.
John Bradley: did you hack the DID into the RPID?
manu: no, we did a 10 line change to the google source code.
John Bradley: so the RPID was the url you were looking at, not the top level DID.
scribe: other questions?
Dalys_Sebastian: Were the verifier and the issuer of the same origin in web authn?
John Bradley: as long as they are in the same origin and have a TLS certificate it may work.
Tony: this is level one, there are things that need to be fixed in level two.
John Bradley: Manu ran into issues with this in web payments, big security problems with iframes in origins. bad things in java script. don't do this.
<pindarhk> Sorry I will need to be excused in about 30 minutes to head back to HKG. Apologies in advance.
manu: promising experiment, not a good browser to actually use.
jzcallahan: Manu asked us to talk
during this session.
... from Veridium, specializing in biomentric authentication
within a company.
... gratified that there has been a separation of discussion
between authentication and identity verification
... Gartner says these fields are colliding.
<wseltzer> jzcallahan's Veridium slides
jzcallahan: becoming conflated.
We've focused on the enterprise. A platform that supports
numerous native and non-native authenticators.
... now, smart phones eliminate the need for special hardware.
Coming soon, our devices will get really good at knowing we are
use.
... what's coming, in addition to the biometric, need
anti-spoofing measures.
... Kaliya doesn't understand the slide
Kaliya doesn't understand the slide
jzcallahan: don't worry about
placement.
... It is imperative to add liveness. Biometrics are not
passwords.
... an attacker who presents a facsimile should not
succeed.
... the context of the biometric authentication is
important.
... using different factors: time, common movement, etc.
... [IEEE 2410-2017 slide]
... what we discovered in the marketplace, mobile to mobile
mode needed to be updated to support server-side.
... m2m is good for authentication, basically equivalent to
FIDO.
... will be FIDO certified in the future.
... In other cases, for account recovery, using Shamir secret
sharing with one piece on the device and another on the server,
allows server-side protocols to avoid storing the biometric
fully on the server.
... the idea is we want to cover global needs
... instead of going through a KYC process (which may involve
biometrics)
... you can do different things [slide: initial
onboarding]
... doesn't require subsequent biometric enrollment
... reduce friction but support KYC/AML
... there are places this is required. Once biometric check is
done, it can be thrown away.
... there are only a limited number of cases that require
central storage.
... SSI Biometrics would allow for roaming KYC.
... make the credentials standard requires SSI
... how could we do biometric authentication in a Web Authn
context.
... [slide: Biometric DID Auth]
... this is a proof of conecpt for how these things could be
tied together.
<wseltzer> jbradley: that's easily phishable
<wseltzer> ... it fails at the QR code
jzcallahan: failed at the QR
code
... you have a cloud agent acting on your behalf
... Sovrin and uport could be used on the back end.
... allows KYC vendors to monetize their process.
Jill: can your system account for simple dynamic things?
jzcallahan: We don't want to
handle the whole KYC thing, we want to stay in our lane and
provide biometric credentials.
... KYC is the gate, the ongoing AML is where the costs
lie.
... we are paying close attention to the VC work.
Jill: client onboarding happens first, but you need to update who your customer is, that's what KYC means.
jzcallahan: we don't want to do our own transaciton monitoring, we want to provide the biometric claim that exists as part of the rest of the ecosystem.
Marie: I am from Gemalto, digital strategy team.
<wseltzer> Marie's slides
Marie: PSD2 regulation
discussion
... [slide 1] two objectives.
... banks are very protective of their customers and the
data
... this is not currently optimally done.
... lots of data breaches and account takeover. goal is to
reach same level of assurity with e-commerce as with chip
cards.
... [slide 2] European banking organization created SCA
... essentially 2FA
<wseltzer> Marie: PSD2 takes effect Sept 2019 for any banks or retailers in Europe or doing business in Europe
Marie: but also requires
dynamically linked data
... [slide 3] shop authenticates user out of band
... issuer decides everything in this model
<wseltzer> [slide 4]
Marie: not in line with what
retailers need
... retailers want control
... this will affect the bottom line
<wseltzer> [slide 5]
Marie: they are looking for alternatives
<wseltzer> [slide 6]
Marie: merchant will authenticate
the user.
... and decide at which step this must happen, and where to add
the friction.
... credit cards are determining the framework.
... FIDO and Web Authn seem like a good solution.
<pindarhk> I'm sorry that I didn't get to personally meet everyone. If you come by Hong Kong, please do drop me a line at EMAIL_HIDDEN :)
Marie: thanks to FIDO, there is a standard that anyone can verify
John Bradley: not everyone can verify the signature
Marie: This may not be doable today, but this presentation is about the 5 year road map
wseltzer: possibly a gap in the standards if that can't be solved.
John Bradley: I was just in France. Once we get the capabilities in the iframe, using the web payments API, that will use the bank as the RPID so the key that is registered can be validated.
Marie: the point of those slides is to introduce the PSD2.
John Bradley: yes, I think we can make good progress here, but there are privacy issues.
wseltzer: we have been working at W3C on this question between the Web Authn and Web Payments WGs, we are sending a charter for joint discussion of this work.
Marie: Is there a 3d Secure implementation in the Web Payments group?
John Bradley: yes
Pam: One question about your diagram. Who's directory server is it?
Marie: Visa, mastercard.
Pam: there may be a missing participant, where is the payment processor?
Marie: it is connected to the directory server.
tomj: should a relying party be
required to accept authorizarions from unrelated parties?
... this could create a real problem for this group.
<weiler> tonj: banks need to be fiduciaries for the customer, not the merchant
Greg: I was in Paris with Visa,
just talking about this. banks need to be fiduciaries for their
customers.
... in Europe this is different than in the US.
... with PSD2, privacy rights are treated like human rights, in
US they are contract rights.
... the contract orientation and the elevation of terms of use
means it is very difficult for self sovereign identity to
triumph.
wseltzer: thank you Marie. There
are snacks. let's break. we will reconvene after the break.
maybe some breakouts. not much time left.
... only a half hour left. mostly for breakout groups.
wseltzer: we have smart people
and a lot of work to do. possibly not a good sense of exactly
what is next.
... lots of interest in interop, a DIDWG charter, etc.
... we can continue the discussion with the mailing list from
this workshop.
<manu> -1 on new CG for DIDs
<manu> -1 on another workshop :) (except continuing work in RWoT, CCG, etc.)
wseltzer: we want to continue to develop solutions to these hard problems.
weiler: limited time
available
... looking for 2 to 4 conversations.
... who wants to choose a topic?
... vote for confusion resolution
... open ID connect DID?
... 2
... translator for Ethereuem openid?
... no
... a login with DID button?
... no
... Selective permissionless delegation?
... no
... these are not giving us discussion ideas.
... the ones with the most agree and disagree are the
chartering discussions
... one of the breakouts is the DID WG chartering.
... who doesn't want to go to that one?
Dirk: we've talked a lot about solutions, not sure what problems we are trying to solve.
weiler: chartering and use cases, is there a third?
ChristopherA: is there anybody else interested in the true anonymous use cases?
weiler: that's three.
<wseltzer> [breakouts, followed by adjournment. We'll capture outputs and report back on the participants' list.]