<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.)