TPAC 2018 DID WG proposal breakout -- 24 Oct 2018

<dlongley> Sam Weiler: I'm at W3C.

<dlongley> Chris: Capital One.

<dlongley> Ken: Amex.

<dlongley> (other really fast introductions)

<dmitriz> *dave: let me know when you want to switch off scribing*

<dlongley> manu: Thank you everyone for coming.

<dlongley> manu: We're going to go over some use cases, questions we will ask the W3C membership, etc. And end with questions. We're not doing a deep dive into the technology today but we can discuss it if that's what people want to talk about.

<dlongley> manu: If you want to ask questions please put yourself on the queue.

<dlongley> manu: If you do "q+" you will get on the queue.

<dlongley> manu: We're working on a proposal for W3C. Not a deep dive. For those of you who don't know what a DID is, you're not alone. It's a new type of URL that is globally unique. For most of you that's HTTPs.

<dlongley> manu: That's where HTTPS stops, DID URLs are different in that they tend to be on decentralized ledgers making them highly available. They are cryptographically identifiable -- you can prove it's your identifier. In most cases, DIDs are also created with no central authority.

<dlongley> ChristopherA: And the word is identifier and not identity.

<dlongley> manu: Excellent point, identity might come out of this [be built on top].

<dlongley> manu: a DID breaks down into three separate bits. It's always `did:` and then a did method. A method is like a ledger or network where that DID lives. At the end of the DID is the method-specific string, it's up to the method to decide that.

<dlongley> manu: An example at the bottom is a Veres One DID.

<dlongley> manu: `did:` is the top layer, you don't put HTTP in front of it.

<dlongley> manu: So when you dereference that DID you get a DID Document back. It has authentication mechanisms and public key material. DID documents are places where you can put cryptographic public keys.

<dlongley> manu: It can also have service endpoints -- you can tell people how to contact you, ways for you to express your website, payment provider, linked in provider, so on.

<dlongley> ivan: What does it mean -- dereferencing?

<azaroth> A document that covers the information Manu has in the slides: https://tinyurl.com/did-primer

<dlongley> manu: I'm hand waving but it's like HTTP GET -- on a decentralized ledger you go out to a node and get a document from it.

<dlongley> ivan: That means you have to update all the infrastructure.

<dlongley> manu: No, that can happen, but you don't need that to happen.

<dlongley> tony: You're not putting private keys on there?

<dlongley> manu: No, not putting those out in the public.

<dlongley> manu: Public keys, not PII. But that's the tension.

<dlongley> manu: An interpretation of GDPR states any hash is PII.

<dlongley> joe: Only an interpretation, open to debate.

<dlongley> Jason: What are the use cases this is trying to solve?

<sandro> reto: So if this can do GET it sounds like a full replacement for http, and I can use it for my CSS

<dlongley> manu: One use case I'll throw out. The US Federal Govt. CBP, specifically, needs to identify organizations that ship things into the US and they don't want to issue IDs to them. They want them to show up with their own identifiers that and a verifiable credential taht says they are a valid shipper.

<burn> This is a new naming scheme, not a replacement for http, ftp, or any other existing naming scheme

<dlongley> manu: These are examples of organizations and active PoCs that use these technologies and have needs. Also useful in education and healthcare.

<dlongley> manu: It's bring your own identifier.

<nage> or to say it differently it is an identifier layer that can/should/could have naming layers built on top of it

<dlongley> manu: That's fundamentally the use case.

<dlongley> Jason: Ok.

<dlongley> manu: Where do we use DIDs? Another set of work going on in another WG called Verifiable Claims/Credentials. We want to be able to assert things like their job title, name, over age of 21, so on. On the slide we've replaced identifiers with DIDs and the data is more portable. Not locked to a lease-based DNS system and controlling that identifier directly.

<dlongley> manu: That's where they slide in at W3C work. Typically identifiers are DNS based ... we like DNS and want it to stick around and it is very useful. But one of the downsides is that the identifiers cost significant amount of money and can be taken away from you fairly easily.

<dlongley> manu: Fundamentally here identifiers are controlled by individuals and organizations.

<dlongley> tony: Today there is fixed pricing for domains, someone will have to store that DID document and are you subject to them upping the price and so on? Will this create something that isn't level?

<dlongley> manu: That's a legitimate concern. I'm just going to about blockchains. When you store something in the blockchain it costs a certain amount of money. When you store it you don't have to keep renting, it's there forever. It's possible that they keep hiking the price ... still possible, some blockchains where it's too expensive.

<dlongley> manu: So the DID Document is stored on ledger. So for just blockchains -- the data sticks around. But other systems can be devised (and some do not store the data on blockchain).

<dlongley> ChristopherA: If you notice, that was not a human readable name. We're punting on having names that are human readable. We're choosing identifiers that were not contention on their semantic meaning.

<dlongley> tony: There is some bearing on their semantic meaning because there's different types of DIDs.

<dlongley> ChristopherA: But you're not going to poach a domain for Coca-Cola at this level.

<dlongley> manu: That's the general premise here. You want orgs and individuals to control their identifiers and not have to rent them.

<dlongley> manu: A number of orgs have already done an interesting number of PoCs.

<sandro> what's a "p o c"?

<burn> p o c == proof of concept

<dlongley> Proof of Concept

<sandro> +1

<dlongley> manu mentions orgs that have done PoCs

<dlongley> tony: From a Microsoft perspective we are interested and we're playing in this area, issues to be worked out but interested.

<stonematt> what role does the individual consumer have in the POCs so far?

<dlongley> manu: Asked W3C organizations interested in a DID WG at W3C.

<dlongley> manu: Pretty healthy group of organizations interested.

<dlongley> manu shows slide with lots of orgs

<dlongley> manu: There's also something called the Decentralized Identity Foundation. In general those members are also supportive of DIDs because they enable their work.

<dlongley> manu: This is a healthy group of companies, it's not a small collection.

<nage> stonematt: it varies from PoC to PoC, we are working with a few that have done test deployments of consumer identity wallets and are giving interesting feedback. In most cases it is invisible to the end user and looks like a password manager in terms of backup and a contact list in terms of key management.

<dlongley> manu: Who is behind this work? This work has been arguably incubated for 6 years. First group is CCG and RWoT on slides.

<dlongley> manu: A lot of the Credentials CG member are here today.

<dlongley> manu: A lot of the work is being worked on here at W3C and RWoT. Also working on things at IIW. IIW is happening right now -- and we would have 15-20 more people here if there was no conflict.

<dlongley> manu: Should we create a W3C DID membership? -- was the question proposed in our survey.

<dlongley> manu: We asked if W3C members would join the W3C DID WG, 63 said yes, 19 said they would not join but it was "i'm not a member" or "i'm a small company", etc. -- happy to share data with W3C staff.

<dlongley> manu: We asked them what their membership status was. 32 of them were W3C were members, 37 were not.

<dlongley> manu: That's really interesting, can pull more companies into W3C and increase membership diversity, new tech pool.

<dlongley> manu: Jason you asked about use cases -- this slide shows those. Identity management is very broad, just in general in that sector. Verifiable Credentials was the other big one. The primary deployment path for Verifiable Credentials is using DIDs. This is ok to take a picture of.

<dlongley> manu: Strong cryptographic authentication. You will here people talk about DID auth -- there are like 8 types of that and we need to figure out what that means.

<dlongley> manu: Cryptographic Access Control is interesting. Services -- how do you find out other types of services associated with an identifier. Healthcare contacts, emergency. Digital signatures of legal agreements, business process, auditing, etc. Healthy interest.

<dlongley> manu: There's a clear theme there.

<Zakim> weiler, you wanted to ask about DID Auth and to ask about DID Auth (slide 20)

<dlongley> ChristopherA: One thing not on there is IoT

<dlongley> manu: And we should have put that one there.

<dlongley> sam: There are lots of different types of DID auth?

<dlongley> manu: Depends on the type. Many of them. Import process -- use digital signatures though and that could be argued as a form of authentication. So hard to answer that question without getting more involved in what DID auth means. It's useful for non-browser as well as browser. System to system communications. If systems are authing with each other is that DID auth?

<weiler> sam: how many of these use cases can be handled without DID auth?

<dlongley> ivan: Out of these services/use cases, which are the ones for which the decentralized aspect is really fundamental? I know in the publication work for example, there's a very strong need for identifiers that can be used all around. In the scholarly world at least, these days orchid. Everyone has those included and it's centralized and required. And that community is happy and it doesn't cost a penny.

<dlongley> ivan: Obviously the fact of having a reliable identifier is extremely important.

<dlongley> manu: If people are happy with orchid there's no need for them to move to DIDs. What we've seen so for -- is where identifiers are a pain point, for example US Govt they don't want to issue identifiers or the IRS they don't want to issue identifiers. When organizations or communities are ok with the identifiers they have. But in other cases, in trade, trade finance, in education for professional licesnses, transcripts, those industries are very interested i

<dlongley> n this.

<dlongley> manu: Because they don't have to do the identifier management.

<dlongley> ivan: This is not a complete answer. These are good answers for organizations for well-managed identifiers. That they are decentralized would give it a different twist. I know some wouldn't trust a gov't ID but where does the decentralization come in specifically?

<nage> many identifier organization can extend their use cases and reach by using decentralized identifiers + verifiable credentials. They can then issue and revoke the information in their registries such that they can be proven, used and leveraged independently from the real-time API integration available from their systems directly.

<dlongley> ChristopherA: Specifically to Holland, it's one of the countries that is working very hard on the Self-sovereign identity area. They do not wish your identifier to be used in the way that it is used today because history ... because more Jews/Gays died. They have a moment of silence in May for a historical event related to this. They are looking into how to stop these horrible things from happening again. Empowering the power to bring their identifiers to t

<dlongley> he gov't is the only human rights answer to solve the problem.

<dlongley> ivan: I'm in fully in agreement with what you say and you may want to emphasize that on your slides. Other identifiers exist and what you bring here is the decentralized aspect and the other stuff is in some way not important.

<dlongley> phil: The global trade item number GTIN is usually called the bar code. We have our numbers everywhere.

<dlongley> phil: Are you killing my business, Sunshine?

<dlongley> manu: The short answer is no. Specifically GTINs were used along side DIDs in PoCs. I think there's an interesting use case for GS1 to have DID identifiers. For GS1 who does this type of identifier allotment, there's an easy on ramp for them to support it.

<dlongley> phil: You've mentioned the border protection stuff and that's a key driver. We're supportive. The EU next year requires every tobacco packet requires its own identifier.

<dlongley> phil: What is it that the decentralization does? Identifiers are like toothbrushes and standards, everyone agrees they are a good idea and no one wants to use anybody else's.

<Zakim> azaroth, you wanted to ask about an orcid DID space

<dlongley> rob: ORCID could produce their own method. You get all the benefits of the verifiability and credential management on top of their system. In the future they might then allow additional companies such as journal companies to let them create identifiers on their own.

<dlongley> reto: About the Dutch situation, why would it have helped if the identifier had been pushed out to someone else? Tax systems want to make sure everyone pays their taxes -- they have an index and a registry, so why does it help? If you want to identify people and go to the tax registry and find all the bits or you can go to the identifier provider.

<nage> Interesting note, many identifiers in today's systems model better as verifiable credentials, because they work more like access tokens or units of authorization in terms of correlation -- in this case it is better to present the identifier as a credential so that you may use selective disclosure and directed identifiers for presentation to avoid becoming an unintentional cross-site cookie.

<Karen_> https://orcid.org/

<dlongley> ChristopherA: Because the use of DIDs allows for a variety of ways to minimize disclosure, you can use selective disclosure for blinding of information to reduce correlation, you can keep the information in silos where it can't be connected. So if you look at British Columbia, they may have a single card to access a variety of services each gov't suborg can't access the other suborgs information. They have pairwise identifiers between them.

<dlongley> ChristopherA: You can say "I paid this much for taxes, but you can't correlate that to other information."

<Zakim> JoeAndrieu_, you wanted to answer reto

<dlongley> dmitriz: One thing worth emphasizing that may help frame them as opposed to other types of identifiers. DIDs are a subset of identifiers cryptographically verifiable. They carry crypto information usually public keys. DIDs are for use cases where something or someone will need to prove control.

<dlongley> joe: Maybe the simplest way to put it is that attributes aren't in the DID architecture. They are separate. You can access that DLT or blockchain and still not know who is Jewish or where they live,e tc. Where it's all centralized you can get to it more easily.

<dlongley> nage: You no longer have to use the same identifier with every presentation of the information. People are concerned that the identifier will follow you around wherever you use it but because it's cryptographically identifiable, I can use different DIDs for different contexts.

<dlongley> nage: There's a lot being built on top of this as a base building block.

<dlongley> ivan: I'm still trying to find the best message. It's the cryptographic part and the uniqueness part which is the really important thing. It's not the decentralized thing. The really big thing and that should be in the center of the messaging. There is crypto involved very heavily and I can prove different things. I don't have to use the same identifier for different contexts.

<dlongley> ivan: That is the real point, not the decentralized aspect of it. I understand that it's core of the technology. I don't want to be offensive to anyone, it looks like you used fashionable buzz words here and not what's central to it.

<azaroth> +1 to Ivan that cryptographically verifiable is the key point, also a well known requirement in W3C

<kimhd> these are great points -- those messaging issues are critical

<dlongley> tony: When you are talking about the DIDs you're also talking about the DID Document and that contains the crypographic material, not necessarily the identifier.

<dlongley> manu: Sometimes, the DID can itself be constructed from a public key. If you rotate keys you go to the DID Document.

<dlongley> reto: You said you love DNS very much. But a lot of motivation for DIDs are the disadvantages of DNS -- why not split this? Cut the crypto-verifiable identity and separate the decentralized replacement for DNS. It seems why mix them?

<dlongley> manu: We are only so many people and can only work on so many things at a time.

<Zakim> nage, you wanted to emphasize the identifier vs credential point again

<dlongley> nage: I think a lot of what a lot of people are using identifiers for is a kind of authorization and those constructs work very well when the identifiers are centralized. When they are decentralized you can break things up and revoke. You can maintain the privacy of the identifiers as they follow you around. There's some interesting interplay with these specs as long as we're careful along the way so the data models don't try to do too much at once.

<dlongley> ChristopherA: This is a working group for a data model. We're not talking about protocols at this point. That being said, we already have ... Stack is one of the submitted DID methods, they are trying to replace DNS. Namecoin replacement people basically have a .bits domain which is a cryptographic domain that IANA has reserved for use. That doesn't use the traditional style of domain servers.

<dlongley> ChristopherA: There are people at a different layer that are exploring this -- no easy answers -- just don't want to get in their way. They like working with DIDs. If they want to do interesting but wild experiments let's see what they do.

<azaroth> To go on record, The J Paul Getty Trust supports the work for the reason just expressed. We want to enable verifiable identifiers for cultural heritage resources (art, etc) that isn't tied to specific, transitory organizations' lease of a DNS entry. Then when the artwork changes ownership, the DID can move with it.

<dlongley> ChristopherA: If the market produces a decentralized DNS that's fine we can do that then. Our focus is -- can we get a spec for what is a DID, what are the minimum things that a method MUST support, what SHOULD it support and be done.

<dlongley> tony: Is there urgency and if so, what is it?

<dlongley> manu: There are a number of companies in the space deploying into the market now -- and we're concerned that if we don't start generating something right now everyone will go in different directions. There are twelve different DID methods. A subset are very serious and if we don't nail it down and we're going to see proprietary mechanisms and it's a bad story.

<nage> for the notes: many of today's use of identifiers are built for allowing correlation and authorizing access in some way to a certain amount of information or type of access. When you decentralize the identifier layer you can replace these identifiers with verifiable credentials that have issue/revoke patterns that allow that data to be better controlled and privacy preserving. These combinations of cryptographic keys, identifier continuity and signed

<nage> verifiable information (verifiable credentials) allow for a lot of neat net use cases.

<dlongley> manu: The US CBP has said in a Capitol Hill testimony and if you want to use trade with the US you will be required to use DIDs and Verifiable Credentials.

<dlongley> manu: There are plenty other markets and use cases.

<dlongley> rich: I work for Evernym. We have policy council working with the US and the EU. We've had very productive conversations. We are working with govt and it's a foundational tech and it's not head in the sand.

<dlongley> rich: Why is there so much pressure? These are very long lived assets. It will be very painful because once they are used in the real world we are stuck.

<sandro> heh. Missed the queue by 0.5 seconds

<dlongley> ChristopherA: Some of the funds for the research came from previous administrations.

<dlongley> ChristopherA: These technologies help decentralize things and help address some of the issues with too much gov't control.

<dlongley> ChristopherA: Some gov'ts want to make sure the right things happen.

<dlongley> Christopher names others investigating this area and that want this structure

<dlongley> ChristopherA: I did not think that governments would come this fast but they are doing so.

<dlongley> peter: We do have this interest for cards for entitlement. There's an identifier associated there and there's an element that's not top down from the gov't. People want these to access the services, the thought process matches it.

<dlongley> peter: Don't know about the technology.

<sandro> My question, now not to be discussed at meeting, is can I use an http(s) URL as a DID, and if not why not? It seems to me any place in any system that expects a DID must work fine if I give it an http URL with suitable content.

<dlongley> manu: So, back to the questions... "Is this the right time?"

<dlongley> manu shows slides on use of DIDs

<dmitriz> *sandro: I believe that is the case and the intent (that you can use an HTTP uri in place of DID)*

<dlongley> manu: 25 researched DIDs, 26 orgs using them, 14 already produced products. If we wait another year we may miss the sweet spot and we may get a dominant player in the industry and that wouldn't be a good thing.

<nage> sandro: we could build some type of http did method spec, where there was a standard for resolving the document and proving control of the key. One of the important ideas to consider is how do you trust the did document returned so you know it hasn't been tampered with or changed against the identifier controller's wishes (in the case of http there are only certain guarantees that are possible).

<dlongley> manu: There is a W3C Strong Authentication Workshop happening in Redmond, WA, Dec 10-11th, please come.

<dlongley> manu: We're targeting an AC vote on a DID WG in January. Hopefully a DID WG in Feb-March timeframe. Entirely dependent on the people in this room. When you see the vote come up please vote in favor.

<dlongley> manu: https://tinyurl.com/did-wg-proposal

<dlongley> manu: Please take a look at it, it includes the DID WG charter proposal.

<dlongley> manu: It's there including a primer and all that sort of stuff.

<nage> Thanks manu for the excellent presentation!

<burn> (many others present beyond those listed)

Self-Sovereign Identity Breakout Session

<manu_> scribe: Manu

<manu_> scribenick: manu

<manu_> Joe going over definitions

<dmitriz> *do we have a link to the slides?*

<manu_> joe: Decentralized Identity is where the user has control - administrively independent of any administrator.

<manu_> joe: There are 3 efforts supporting this direction,

<manu_> joe: Verifiable Credentials, Decentralized Identifiers, and WebAuthn

<manu_> joe: It would be great if we could have some notion of identity that's not centralized...

<manu_> joe: We want a plurality of identity

<manu_> joe: The Identity emerges across multiple internactions - sole sourced authorieis to multiple authorities.

<manu_> joe: This is a stack I use to think through services - distributed information architecture

<manu_> joe: at bottom is root identifiers - DIDs

<manu_> joe: DID Documents are policies attached to DIDs

<manu_> joe: Verifiable Credentials - someone saying something about raw data.

<manu_> joe: Personas, etc are next up

<manu_> joe: Then consent is the next layer up, how do you give permission, request permission

<manu_> joe: Then understanding - then what services do you want to provide.

<manu_> joe: Some future standards work -- DID Auth -- maybe WebAutn Level2 is a good path there.

<manu_> joe: OCAP-LD is another one object capabilities

<dmitriz> +1 to importance of standardizing Credential Requests

<manu_> joe: Credential Requests... then consent

<manu_> joe: Maybe credential receipts from Kantara?

<manu_> joe: Storage and internal representations - run algorithms over sources of data...

<manu_> joe: The underlying data model in VC is RDF

<dmitriz> *Consent Receipts from Kantara: https://kantarainitiative.org/file-downloads/consent-receipt-specification-v1-1-0/ *

<manu_> joe: Analytics and Algorithms - want to know info algorithm is run against and I want to know the algorithm

<manu_> joe: We could have standards around how you do that

<manu_> joe: Crytographic Suites -

<manu_> ChristopherA: There are a lot of different approaches/requirements -- existing cryptographic modules -- we have a variety around signing JSON-LD cryptographi suites, RSA one, secp256k1, CL Signatures, data canonicalization, hash tree signing - partial information -- data minimizations.

<manu_> ChristopherA: There are a number of proposal, security review, higher quality code, etc.

<manu_> gkellogg: should this be considered a stack? Consent -- can that be a form of a claim? Does it need to be associated w/ data at every point of transfer?

<manu_> joe: Yes, maybe -- maybe it's not a stack, it's not linear

<manu_> joe: sometimes consent isn't involved, sometimes it is.

<manu_> ChristopherA: This slide isn't a stack, there are missing pieces -- this is just low hanging fruit.

<phila> --> https://opencreds.org/specs/source/roadmap/ Credentials Community Group Roadmap

<manu_> https://w3c-ccg.github.io/roadmap/

<manu_> W3C CCG Roadmap ^^^

<manu_> joe: This includes stuff like JWS, Verifiable Credentials, stuff that's anticipated to be worked on.

<manu_> joe: Want to open it up to discussion - what gaps are there? what are some of the pitfalls/challenges? Let's throw some intellectual grenades.

<manu_> ChristopherA: We have this innovation pipeline - everything from socializing stuff from RWoT, IIW, My Data, -- do proof of concepts, etc.

<manu_> ChristopherA: Decentralized Web - early experiments/trials - as those emerge, make things functional - that's when we move things into W3C formal process - starting w/ CCG, influencing existing spec text, all of these things listed are inspired from innovaction pipeline.

<manu_> ChristopherA: Where are there things that are parallel - in RWoT, in DIF, that might guide us differently.

<manu_> TonyN: The TC ISO Blockchain thing is going on this week - they have a roadmap for identity - there is a set of specs by the national bodies, etc, that will plau an important role.

<manu_> TonyN: They are discussing some PII stuff. Some of the identity architecture is s imilar to what's being produced here, some of it isn't.

<manu_> TonyN: I have some concerns over some of the technology that's been chosen here, JSON-LD and its complexity, simplify things as far as claims are concerned. I think that needs to be addressed.

<manu_> TonyN: I think Entity Attestation work should be considreerd - constrained devices - produce claims in limited computing environments. COSE Tokens needs to be considrered.

<manu_> TonyN: I think there are issues on resolution that need to be brough up, how do I get a DID, resolve a DIDs, can DIDs be moved between blockchains.

<manu_> TonyN: There is a lot more that can be scoped out before we take the plunge here.

<manu_> nage: There is a lot of new work here on anonymity and key requirements - lots of overlap w/ WebAuthn - how to do key management, want to make sure we get those discussions on the table. Don't want to reinvent the wheel.

<manu_> nage: A lot of discussion around universal wallet - some place secure - not so much from a Web standpoint vs. cryptographic toolkit approach. Create standard libraries, implementations - what are crypto standards, what are web standards

<manu_> ChristopherA: One of my big questions - as different groups play into the blockchain game - Hyperledger, Linux Foundation, ISO.

<manu_> ChristopherA: For example, ISO data minimization standards - couldn't pay for $5K cost at ISO.

<manu_> ChristopherA: I worry a bit about taking too much definition - we've gotten a little further than some organizations... what can we do to encourage "them" to come to us.

<manu_> TonyN: I think the Strong Authentication and Identity Workshop in Seattle in December is one place where that can happen. I know people from ISO will be there.

<manu_> nage: Hyperledger will be doing forum on same time as that workshop.

<manu_> Ken: Is there an order to the list on potential standards work?

<manu_> ChristopherA: There is ongoing discussion on JSON-LD and signature techniques.

<nage> Hyperledger Global Forum information is here (especially for those in Europe, we will be there talking about a lot more of this along with organizations who are deploying it) https://events.linuxfoundation.org/events/hyperledger-global-forum-2018/

<manu_> TonyN: There is a lot of JWT/CWT stuff out there that have set signing, etc - vetted - get those reused - there will be some complex scenarions where JSON-LD may be the answer there. Simpler scenarios, you want a flat json claim in a compact form.

<phila> --> https://www.w3.org/Data/events/data-ws-2019/ W3C Workshop on Web Standardization for Graph Data

<phila> Creating Bridges: RDF, Property Graph and SQL

<Zakim> manu_, you wanted to mention data graph workshop

<manu_> ChristopherA: We need to talk w/ blockchain companies - they're moving on, they find these whole processes way too slow - ICO spigots are tighter, but they're still getting money.

<manu_> ChristopherA: How do we bring them in and get some consensus - get ICO funded companies involved - it's been difficult

<manu_> joe: German blockchain association just published a document yesterday -

<manu_> joe: We need to be rigorous about how we say the things we do "controller" vs. "owner"

<manu_> nage: People are implementing and deploying very quickly - we need to talk about the dangerous things in the early parts of the cycle - there are implementations in the wild that are ignoring these issues. I know many of us are involved in one form or another, but there are people that are not paying attention.

<manu_> joe: I know there are jokes about blockchain fairy dust - part of our challenge w/ this stuff is approaching blockchain and understanding the challenges.

<manu_> TonyN: I'd like to step back to the last session - potential WG for DIDs. To me, I think there are a lot of unresolved issues w/ DIDs. I understand there are needs - urgency... there are different DID implementations, those aren't going to change their minds... they will go down path they believe. They will go down path that's right for their use cases.

<manu_> TonyN: I wonder if it's that urgent, or if we need to better understand use cases for DIDs, to me they look very oriented toward a single type of blockchain, they're not universal across blockchains... having a bag of identifiers 00 each blockchain may treat identifiers differently. Who runs the resolver? They may not be as forthcoming.

<manu_> TonyN: There are some privacy issues here - I don't want to slow things down, want to understand the bigger picture - we don't want a standard that doesn't work afterall, or major tweaks.

<manu_> joe: So, what's the urgency - we have to respond to potential design blindspots that we don't know y et. Aadhaar is an interesting eamples, for Indian society and Indian government - large dollars... $1B to build, saving $1B/year - many countries are being ptiched to build Aadhaar systems.

<manu_> joe: This longer Identity, self soverign identity - want to figure that out so we don't have rollup by default - don't know what that new system is... I know we're wrong in some parts, but don't know which parts yet.

<Zakim> nage, you wanted to note that developers aren't waiting and to mention roots of trust and semantic meaning of keys

<manu_> nage: A lot of these are things we want to bring in to standards - consensus - when you bring one identifier to a new system - one of the things W3C can do is decide how to talk about trade-offs in cryptography - what do you get, what do you not get?

<manu_> nage: Many Hyperledger Fabric folks - dont' want to engage in W3C, but we may be able to pull groups in... we need to do something here to get them here.

<manu_> Karen: Can we look at stack/roadmap?

<manu_> Karen: I speak w/ folks in tech/business - this slide is incredibly overwhelming - these are all new concepts... we need them to be unpacked... for example, give me a day in the life of a DID.

<manu_> Karen: Business folks aren't wired like tech folks - for example, focus on Consent... need to visually/verbally message to key segments, early adopters to this approach.

<manu_> joe: We are taking that feedback in - we need better language.

<Zakim> phila, you wanted to ask about resolvers

<manu_> phila: +1 to Karen - I'm trying to explain to my community what an API is, what is a URL?

<manu_> phila: Tony used a word, resolver - what's that?

<manu_> phila: Big companies don't know what that means,

<manu_> phila: If we're planning a roadmap - a resolver - does that need to be called out? If there is a resolver, what is it? how do you advertise that, etc?

<manu_> phila: What is a resolver? We need to ansewr that question

<nage> and a third piece -> how do you trust the did document someone handed you

<dmitriz> nage: did documents are signed, though..

<manu_> JohnB: What is the DID and how do you get the DID Document - having been involved in some number of failed identity projects in the past, you have to build up a critical mass - to get enough people interested, that's why we have standards, so companies can contribute together - small chance of people succeeding vs. failing - what's the liklihood of people building their different notions of DID Auth - are we going to pull people together....

<nage> yes, signed by whom? You need confidence from the rooting system to be sure you aren't looking at attacker keys instead

<manu_> ChristopherA: That's part of my point - if we do not act NOW - then things will go in different directions.

<nage> different DID methods can provide different guarantees, we need to talk about them and understand what you get and what you don't

<manu_> ChristopherA: That's dangerous - there is enough critical mass - 12 players noted that they want to work together, if we start delaying for perfection, they're all going to disappear.

<dmitriz> nage: I think the whole I idea is that they're signed by whoever is controlling the keys. so that part is (almost tautologically) verifiable, no?

<manu_> JohnB: Yes, it's true that many blockchain backed companies that have money - can they be successful in the long term?

<dmitriz> (and the contents of the document, and the keys, is bound to the DID identifier itself)

<nage> We are talking about different parts of authenticity. Who possesses the identifier is in control of the method and guarantees provided by the method, the authenticity of the returned document leverages the signature you describe. You must be able to validate both layers

<manu_> Joe: We saw Civic turn around because of the standard... Blockstack too.

<manu_> JohnB: We have had others see the standard and go the other way... I have scars from previous iteration of this idea. Coming to consensus around the document/resolver is important.

<burn> manu: we have been careful to push all content through the CG and IPR process.

<manu_> ChristopherA: There are a number of us w/ defensive patent declarations, we haev been careful to pull stuff in.

<manu_> nage: The community is doing a lot of things, how do we know resolvers can be trusted, there are questions that have come up more than once... we need to understand what can be standardized. In terms of what can be corraled - do apache2, work in places that have IPR assurance, right code custody.

<manu_> Ian: For contributions to the CG - bound to scope of what the contributor put into the spec ... once it moves into WG, scope extends to everyone in WG, even if they didn't contribute spec text... reciprocal grant provision, if you have essential IP, you grant royalty-free license, essential claims - you get the commitments through WG - if essential IP implementers aren't in the group, then there is a reciprocal thing there that protect that area as well.

<manu_> JohnB: There are people that have patents in this space, you'll need to figure out how to handle that.

<manu_> joe: Is there anything that extends further?

<manu_> Ian: There is effectively a mutual non-assert that kicks in...

<manu_> Ian: There was effort made to broaden the pool.

<manu_> joe: That's a wrap, thank you

- DRAFT -

TPAC 2018 DID WG proposal breakout

24 Oct 2018

Attendees

Contents

Self-Sovereign Identity Breakout Session

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output