<drummond> scribe: drummond
Helen began by explaining it will be a non-technical discussion about how to talk about DIDs
The session objectives: 1) segment the audience, 2) simplify key terms, 3) connecting the dots to educate about DIDs
The first objective is to identify the audience first
scribe: Helen's background is in
marketing, particularly in privacy and security, including for
kids
... Helen asked how many members of the DID WG were present.
Roughly a dozen hands went up.
... several attendees are new to the DID space
... Helen stressed that successful communication is conveying
the minimum information the audience really knows
... do not bore them with unnecessary detail
... she also talked about the "nod and smile" problem: this
happens when the audience is unready to admit that they don't
understand what you are saying
... Helen cited a Forrester report that talks about B2B
websites that are drowning in jargon and self-serving
info
... her third point was that "most journalists do not speak
tech"
... they do not have a real understanding of the
technology
... Helen asked what kinds of audiences the attendees of this
session need to speak to?
<burn> drummond: one of the audiences most interested in DIDs is chief marketing officers
phila: supply chain execs and product managers
drummond: one interested audience is CMOs (Chief Marketing Officers) and their staff
Helen's next point was about developing empathy. Put yourself in the mind of the audience. What do they need to know.
Helen showed a slide with the One Ring (from Lord of the Rings) and said people don't need to know what finger it was on
Helen showed a slide with the 5 key problems that DIDs address - understanding the audience's needs
scribe: Helen emphasized that
simplifying terms is very important
... she showed a slide of the "DID word soup" that often
confronts people who want to start learning about DIDs
... Helen said that use cases are another way to really help
people understand a new technology - because they can see the
uses for it
... helen: showed a slide with 10 different use cases for DIDs:
fintech, government, KYC, Banking, NGOs, healthcare,
enterprise, law, security, education, travel
nicktr: There is also a big
problem in insurance and "insuretech"
... this is because insurance company's can't de-dupe the
claims
vkuntz: the back-end processes of banks are also a huge target
Helen showed several sources for use cases: the Sovrin Foundation Use Case Repository, Hyperledger Case Studies, and a Draft Community Group Report February 2019
scribe: Helen mentioned a
particular use case of the Province of British Columbia using
DIDs for verifiable credentials for businesses
... Helen shows a table from the W3C CCG Use Cases document
about 14 features of DIDs
... and then she referenced the 10 Goals of DIDs that are
listed in the W3C Credentials Community Group Community Final
Draft of the DID Specification
... Helen next talked about the visit of the PING (Privacy
Interest Group) to the DID WG yesterday and the descriptions
given by WG members to the PING co-chairs
<burn> drummond: they didn't have deep knowledge about DIDs, but about privacy. Great example of a connection.
scribe: Several definitions were given, and Helen pointed out that there was not any single explanation that will always work
IvanH: Said that he has not heard
very clear arguments about why a new identifier is needed for
some of these use cases
... what he has never heard described very well is "what is it
that DIDs bring to the table that those other identifiers do
not"
... instead he is drowned in other arguments about what DIDs
can be used for, but not precise descriptions of the
differences
jeff: Feels the most relevant thing is the positioning of DIDs vs. alternatives. Everything else is less relevant.
phila: I work for GS1 that
produces identifiers for the whole IoT and supply chain.
... the GS1 identifiers are federated, so decentralized to some
extent
... the problem that Phil wants to solve is making their
identifiers all resolvable, which they are not all today
... so Phil considers that the biggest difference is that DIDs
are cryptographically-verifiable
burn: Is always thinking about
how he explains DIDs to someone who is not technical (like his
parents)
... gives the example of wanting a bag of fertilizer, then a
pallet, then a truckload.
... But only if you ask questions about the truckload, then
questions come up
... that's what leads to the need for verifiable
credentials
... verifiable credentials have issuer identifiers and subject
identifiers
... and privacy is quite important for these identifiers
... the first idea was to just leave it open in the spec and
allow any kind of identifier
... such as email addresses or URIs
... but as they considered it, they realized that both email
addresses and DNS-based identifiers are controlled by
administrative authorities and can be taken away from you
... and with verifiable credentials, not having to rely on an
outside administrator is a big advantage
... and one is able to prove control
pamela: the words "crypto" and "resolvable" will lose an audience
<nicktr> +1 to Pamela - crypto brings immediate FUD to the conversation
pamela: the way Pamela tells the analogy of putting clothes on a clothesline: today you are going around putting your clothes on other's clothelines, and with DIDs you can put it all on your own clothesline
selfissued: DIDs are plumbing and thus, like IP addresses and URLs, we shouldn't try to have people need to understand them
jeff: agrees that they are plumbing, so lay people don't need to know them, but engineers do need to know them, and also product managers
selfissued: Agrees that it depends on the general audience
<phila> scribe: phila
drummond: I agree that DIDs are
plumbing
... the Web depends on URIs and people understand that
... the impact of DIDs ends up being addresses that are crypto
verifiable
... so they have more trust than URLs, even https
... to jeff's point - positioning does indeed resonate
... early interest in DIDs came out of blockchain
... you want to engage blockchain audience, start with block
chain
helen: decision makers don't understand blockchain
drummond: Helen's right - I talk
about bc day in day out - audience is usually blockchain
invasion teams everywhere
... So talking to them means starting with how DIDs apply to
blockchain
... Execs - I don't take that approach. I do what Dan did and
starts with verfiable credetials
<scribe> scribe: drummond
burn: Has seen plenty of examples
of plumbing that people don't want to think about
... there are also many misconceptions about "identity" and how
it works
... to some extent it is an emergent phenomenon from many
different interactions and contexts
... with DIDs you can make this work across many
relationships
... to use Pamela's analogy, it's like being able to have as
many clothesline as you want - one DID for each
clothesline
... so DIDs are actually "bring your own identifier" (BYOI) -
as long as you can prove you control it, the company will use
it
Helen: Helen then transitioned to
her point about the importance of using graphics
... she showed an example of how the Sovrin Foundation
communicates about DIDs and verifiable credentials with a
high-level diagram
... these are friendly and approachable to a broad
audience
... Helen used the analogy of how easy it is to cash to buy
something at a restaurant in person, vs. how awkward it is (and
privacy encroaching) on the Web
... Helen next showed a four layer diagram that the Sovrin
Foundation uses to talk about how something works
... Helen said that using metaphors works very well; people can
relate to these metaphors
... Helen next talked about "register": how your writing sounds
when you are describing technology.
... a "formal register" is typically academic
... a "news register" is like journalism
... "personal" or "informal register" makes it sound more
direct and identifiable
... she also recommends using simple words and not trying to
pack into too much technical description
... Helen showed a slide of general tips for writing about a
technology
... try to use words that the audience can related to and
remember
... Summary points: 1) convey meaning quickly and clearly, 2)
Most generalists don't speak tech, 3) see slides for the
rest
... Helen then showed a popular video a wonderful parody of
technospeak to remind everyone not to "be that guy"
Link: https://docs.google.com/presentation/d/1O_jjvRtTsmFSucuw3LdtaVewCRMiX3DmmajT_h20a4w/edit?usp=sharing
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/Helen showed/helen: showed/ Succeeded: s/??A/nicktr/ Succeeded: s/??B/vkuntz/ Succeeded: s/??C/IvanH/ Succeeded: s/... Helen then transitioned/Helen: Helen then transitioned/ Present: selfissued phila vincent_k jeff Arnaud Le Hors jfontana laurent Dudley_Collinson vkuntz Found Scribe: drummond Inferring ScribeNick: drummond Found Scribe: phila Inferring ScribeNick: phila Found Scribe: drummond Inferring ScribeNick: drummond Scribes: drummond, phila ScribeNicks: drummond, phila WARNING: No "Topic:" lines found. WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]