DID Working Group F2F in Fukuoka — First day — Minutes

– DRAFT Minutes –

Date: 2019-09-16

See also the Agenda and the IRC Log

Attendees

Present: Drummond Reed, Manu Sporny, Ivan Herman, Brent Zundel, David Ezell, Daniel Burnett, Markus Sabadello, Kenneth Ebert, Joe Andrieu, Grant Noble, Kangchan Lee, Phil Archer, Andrei Sambra, Tobias Looker, Charles ‘chaals’ (McCathie) Nevile,Christopher Allen, Yancy Ribbens, Amy Guy, Dudley Collinson, Helen Garneau

Regrets:

Guests: Jay Kishigami, Mike jones, Jim Huang, Sander Stolk, Arnaud Le Hors, Shigeru Fujimura, Pamela Dingle, Dave Raggett, Gregg Kellogg, Chunming Hu, Jeff Jaffee, Yoshiro Yoneya, Travis Leithead, Rong Chen, Daniel Buchner, Dan Brickley, Kazue, Dan Druta

Chair: Daniel Burnett, Brend Zundel

Scribe(s): Charles ‘chaals’ (McCathie) Nevile, Manu Sporny, Joe Andrieu, David Ezell, Andrei Sambra

Content:

1. introductions

Daniel Burnett: please volunteer to scribe. The chairs already volunteered.

Daniel Burnett: We need to talk about Intellectual Property. For members and guests, it is important to understand this.
… Please note that only people who have already agreed to the IPR rules are able to make substantive contributions to the spec.

Amy Guy: See slides

Daniel Burnett: We also operate under W3C’s code of conduct - the summary is to be respectful. Also, if you have explained your point, and people don’t agree, then the chairs may say it is time to move on rather than repeating it.
… we will wait until after the break to do introductions. Also, we plan to have a group dinner (everyone pays their own way). Would someone be able to take up finding a venue (or two) to propose, and reserve?
… We are going to talk process - what do we need to do, and then a few short presentations on where are we up to, and what do people want to do with DIDs.
… After lunch we will start working - Use cases, and then at the end of the day figure out a starting point for a spec. There is one from the Community Group, which has outstanding issues, in any event we will need to talk about ho we handle issues.

2. Process presentation

Daniel Burnett: If you would like to add an agendum to the meeting, you can edit the slides - the relevant one is the google doc

3. Process

Ivan Herman: See Dan’s presentation

Daniel Burnett: we took the major bits of the charter and we will go through it.

Charles ‘chaals’ (McCathie) Nevile: See mission and goals

Daniel Burnett: Reminder, DID == Decentralised Identifier.

Charles ‘chaals’ (McCathie) Nevile: See what is in scope

3.1. Scope

Brent Zundel: What is a DID, what does it look like.
… once you resolve a DID, what do you get?
… we need to describe how the documents actually work.
… In scope is the question “what does decentralized mean?”
… We are going to work from use cases, so we know what problems we are trying to solve.
… We also need to work out how you can extend our work, and how we expect people to use it
… Out of scope: protocols, like authentication. APIs. Method specification. Solving Identity on the Web is beyond our scope. And we won’t define new crypto, authentification methods, etc. We can specify what they need to address for DIDs, but that’s it.

Charles ‘chaals’ (McCathie) Nevile: See process of developing a spec.

Brent Zundel: (Note that in the diagram, PR == Proposed Recommendation, whereas normally it will often mean pull request

Drummond Reed: Brent the stand-up comedian: “Wait until we try to raise some PR by filing a PR for our first PR”

Brent Zundel: We need Formal approval to start a First Public Working Draft (because it starts a point in the Patent License procedure), then as many Working Drafts as we need, then Candidate Recommendation where we think we are ready and are looking for sufficient implementation feedback.
… We need approval to go into Candidate Recommendation, then Proposed Recommendation when we are sure we are done. Then there is a review period for W3C members - that is not the time to be proposing more changes, it’s too late.
… and we want to make tests early and often.
… Working Draft does not require group consensus - you don’t have to agree with things, it allows people to review and note the things they do or don’t like so we can develop consensus on it which we need when we want to publish a Candidate Recommenation.

Charles ‘chaals’ (McCathie) Nevile: Once we get to Recommendation, it’s stabilized, and beyond minor errata, we would need a new Working Group to make a major change.

Ivan Herman: Once we are at Candidate Recommendation we don’t plan to make technical changes - if we decide to do that, we need to issue a new Candidate Recommendation. And Proposed Recommendation is basically completely locked.

Daniel Burnett: It is common to have feedback on a Candidate Recommendation, and you might issue a second, but if you are issuing 3 or 4 you’r probably holding it wrong.

Brent Zundel: We have 4 deliverables to produce.

Charles ‘chaals’ (McCathie) Nevile: See deliverables.

Brent Zundel: Notes are not formal standards - the formal standard is the Recommendation we plan to produce. We will also produce test suites and ancillary information.

Ivan Herman: We can publish as many Notes as we want, they are not formal standards they are “useful documents” we can publish whenever we agree we want to, and their only formal status is that they will continue to be available. We can also republish them when we want to.

Phil Archer: Nice to see so many people here, good work to get us this far. How much of the use cases and spec can we copy across from the Community Group who have already incubated a reasonable proposal to start with

Brent Zundel: Hopefully we can take a lot of that, but we are here to formally decide on it.

Daniel Burnett: We will talk about Rubric tomorrow.

3.2. W3C Notes

Daniel Burnett: We can use notes to publish anything, and does not have to be a consensus position - it can be used e.g. to publish a description of an implementation. Note that the dates in the time line are the first and final expected versions, suggesting we keep working on these things until the last minute. But please, let’s not. Getting it done earlier is really helpful.
… We have two years. That’s not a lot of time in standards work.
… We want to produce a First Working Draft by November. With luck we could maybe do it here, or in a couple of weeks.

Charles ‘chaals’ (McCathie) Nevile: See timeline plan

Daniel Burnett: We want to have our end date, and publish a month early to be on the safe side. So we nee the Proposed Rec done by July 2021 at latest. So we need to have final Candidate Recommendation by about March - especially if we are going to get a pile more feedback (because we don’t want 2 or 3 hours of calls / week to deal with the feedback)

yanghau: slide: https://docs.google.com/presentation/d/1ESS_6TuU7iHcAKkSB_py2zY5NJUKggs_uRDfEdl41HE/edit?pli=1#slide=id.g2aa9106826_2_5

Daniel Burnett: So we probably want to get to what we think is Candidate Recommendation in November 2020.
… It takes about 6 months from the last feature you decide to add to have it actually ready for Candidate Recommenation.
… So if you want features, we want to freeze them in May 2020 (that’s 9 months from now)
… If we aren’t frozen for new features on May it isn’t the end of the world, but things get tighter. It isn’t impossible to extend our charter, but it is a painful thing to do and it’s much better to just hit our timeline.

Travis Leithead: How often will the group be meeting, to move this forward?

Daniel Burnett: Good question. We put weekly teleconferences in the charter, expecting a face to face early next year. Probably about March, we will talk about it tomorrow, and then we will see what we need to do, how we fit things in, etc.

Drummond Reed: This is helpful - thanks. So the takeaway is that the next 6 months is where we do the substantial work on features and major changes.

Daniel Burnett: Yes - especially the things where we might seriously disagree. There will be lots of cleaning stuff up after feature freeze still (which is why it takes 6 months - there are always things you find that need cleaning up). But if the cleanup inspires a cool new feature, then we fall into a terrible bear trap.

Kenneth Ebert: Is this why we want the test suite early?

Brent Zundel: We don’t want to roll out a test suite near the end of the process - it takes time for people to get used to it and start running it. Earlier is always good.

Daniel Burnett: In another group we have added work late in the process. It hurts

Gregg Kellogg: I edit in JSON-LD. Our practice is that you make tests and provide them along with the change proposal, so you are always testing what is actually written in the spec draft.
… Same thing with examples - update them as you make changes to the spec.
… Strongly support getting the test suite work done up front.

Drummond Reed: +1 to having the test suite stay close to the spec, and especially as soon as we get close to feature freeze

Daniel Burnett: Note that at the very beginning you can end up writing a lot of tests that get thrown away, or not be able to run tests anyway. But by feature freeze, you really do want to have the discipline.

Jay Kishigami: could you give us brief information on liaisons we need to keep up?

Daniel Burnett: don’t think we have any official ones. There is Decentralized Identity Foundation.
… we are happy to talk to other organizations as they become relevant. Note that most other SDOs are talking about identity not identifiers

Charles ‘chaals’ (McCathie) Nevile: W3C internal horizontal review, do you have that?

Brent Zundel: We should start Horizontal review as soon as we have a first working draft.
… Has to be done before CR

Drummond Reed: Because there has been visibility of DIDs, there are other SDOs who want to know what is happening and where it is up to.
… e.g. ITU, OASIS are interested in the progress of this.

Phil Archer: I represent a centralized Identifier SDO - GS1, and will be effectively a liaison.

Rong Chen: We have an implementation already.

Drummond Reed: What DID method is it?

Christopher Allen: some DID work will continue to happen in the credentials community group, other than the deliverables for this group.

Drummond Reed: On Christopher’s point, the DID Resolution spec is out of scope for this WG but is a continuing work item for the Credentials Community Group

David Ezell: during the gap between feature freeze and Candidate Recommendation, what does the WG do?

Brent Zundel: here is a link to the list of irc nicks: https://github.com/w3c/did-wg/blob/master/assets/nicknames.json

Brent Zundel: raise a PR to add yours or contact ivan_

Markus Sabadello: See current work items of the Credentials Community Group:

Daniel Burnett: There is plenty of work still to do - checking the tests, getting implementation reports, cleaning stuff up to make sure it actually works. We want a well-reviewed standard, checked for security, privacy, internationalisation, interoperability, and that people are really implementing.
… There is a point where implementations don’t want to keep changing to add new ideas, and as we progress we will give existing implementation more weight as a reason not to take up changes.

Manu Sporny: If there is a long list of liaisons we risk having more people slow the work down, but we do want to coordinate with others working in the area.

Chunming Hu: Is there a liaison with the DIF?

Daniel Burnett: Yes, we do care a lot about what they are doing, and we have many members in common.

Markus Sabadello: There are a number of working groups in DIF - identifiers and discovery group is the one most closely related to our work.

Markus Sabadello: See DIF working group on Identifiers & Discovery:

Drummond Reed: We didn’t list DID resolution as out of scope for this WG. It is a second parallel piece of the infrastructure not in scope for this group. It is a continuing work item for the Credentials Community Group CCG…

4. IRC tooling.

Ivan Herman: IRC is the W3C’s workhorse. If you want to speak, join the queue by typing “q+” - “q-“ will get you off the queue again. “q- later” will move you to the end of the queue to let someone else talk first.

Daniel Burnett: You can also say “q+ to …” and when you are acknowledged, you will get a reminder of the “…”

Charles ‘chaals’ (McCathie) Nevile: [typing “/msg zakim, help” will get you more than you wanted to know about the things you can do…]

5. History of DIDs

5.1. Brief history of DID

Charles ‘chaals’ (McCathie) Nevile: See slides starting here.

Drummond Reed: We’re running to time still :)
… a few slides to show where we have been, then questions so we can cover the material

Charles ‘chaals’ (McCathie) Nevile: [IIW == Internet Identity Workshop, a conference that happens twice a year]

Drummond Reed: most standards related to identity like OAuth has happened at IIW conferences.
… We started with thinking about how blockchain could support Identity, (not yet Identifiers at that time).
… Thanks to Christopher Allen for helping guide is there.
… Verifiable Claims Task Force spun out of W3C Web Payments work.
… one of the people at the Fall 2015 IIW was from US gov’t Department of Homeland Security - very interested in blockchain identity stuff, but the challenge he saw was privacy.
… They started funding work in the area.
… My company then, Respect Network (later bought by Evernym), and Digital Bazaar, were working in the area. Proposed to do this as a community-based spec.
… So we had a pretty mature draft spec in 2016, published. a lot of companies involved in the area were interested in working on that. So next, we proposed that decentralized Key Management would be important work
… Proposed the DID work we had to the Credential Community Group at W3C, as a place to develop it further.
… by 2018 we had companies implementing and working on DIDs, and decided we would like to have a full W3C Working Group.
… That took some time to get started up.
… in early 2019 completed the Dept Homeland Security contract on Decentralized Key Management Design and Architecture (published in Hyperledger Indy, there is a link in the slides)
… Will give a sense of how deep this work has got.
… By then we knew this Working Group was getting set up, so began holding weekly calls on DID an DID resolution specs, in the CCG. And now here we are…

Mike Jones: Process question… Community Group produced a spec. Has there been a decision to adopt that document as a starting point?

Brent Zundel: Not yet. We will look at it later in this meeting and work out how we use it as input

Charles ‘chaals’ (McCathie) Nevile: See further slides - where didd the terminology come from?

Drummond Reed: Thanks to Manu, Dave and others for bringing this to W3C.
… Decentralization is only one aspect of these new identifiers but seems to be the one that “sticks”
… Most identifiers we use today online aren’t permanent. URNs are but are uncommon.

Brent Zundel: https://docs.google.com/presentation/d/1ESS_6TuU7iHcAKkSB_py2zY5NJUKggs_uRDfEdl41HE/edit?pli=1#slide=id.g60978c4f6c_18_0

Drummond Reed: the reasons most people seem to be here is because DIDs are cryptographically verifiable. It’s essential.
… There are multiple ways you can achieve the four requirements. But we don’t know of anything else that meets them, which is why we are here now.

Joe Andrieu: p28

Charles ‘chaals’ (McCathie) Nevile: See what URNs and DIDs look like

Brent Zundel: the link i posted takes you to the first slide in his section

Drummond Reed: DIDs don’t support unicode, which makes them easy to process

Charles ‘chaals’ (McCathie) Nevile: [chaals: so long as your keyboard is in latin]

Charles ‘chaals’ (McCathie) Nevile: See some current usage information

Drummond Reed: This is a couple of data points. How do we establish the legitimacy of DID method namespaces? We have a registry in the CCG.

Daniel Burnett: gkellogg ‘resulting document’ is a vague term. We will need to explain resolution vs dereferencing to answer.

Drummond Reed: I like the fact that governments, like British Columbia province in Canada, who are issuing DIDs for public use.
… see https://vonx.io
… For more information you could go to https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/did-primer-extended.md

Brent Zundel: data model spec

Daniel Burnett: Wanted to mention that part of the story I tell is the work on Verifiable Credentials. In the data model there is an issuer identifier and a subject identifier. Some use cases imply serious requirements for privacy, so we wanted to know what to put there. Email addresses were obviously no good - they can change. http URIs had that problem too, because you only ever lease a domain. So we looked at these blockchain-based identifiers

Charles ‘chaals’ (McCathie) Nevile: that allow proof of control, which turned out to be pretty magical

Drummond Reed: +1 to avoiding lock-in being a major reason de

Manu Sporny: Nice history - thanks for reminding us :) Wanted to elaborate on Dan’s point. There are may different paths people followed that lead here. In payments we had a requirement to get e.g. someone’s address, age verification, and so on. We wanted people to have credentials they could use, but we didn’t want to lock people into a particular provider. We want to ensure that they are portable, so you can decide where to take it, and what to

Charles ‘chaals’ (McCathie) Nevile: put into it.

Manu Sporny: Verifiable credentials go with DIDs like two things that go together really well.

Drummond Reed: +1 to data portability being a major driver

Joe Andrieu: resolvability will be something we discuss today, and some DID methods that are not globally resolvable, which is an important nuance to note.
… What does it mean to have a permanent identifier? It isn’t like having something tattooed onto you that you can’t get rid of. It is about having control yourself rather than some administrator or third party able to shut it down on you. You can stop using it or destroy it yourself, but nobody else can do that. There are plenty of use cases for ephmeral DIDs.

Drummond Reed: +1 to Joe’s points about the nuances of both persistence and resolvability

Daniel Burnett: +1

Daniel Burnett: We don’t want to give the impression of a permanent identifier without understanding that this is NOT identity

Gregg Kellogg: Once the DID is assigned it doesn’t go away, and there is a way you can use the DID to retrieve a DID document, and being decentralized implies to me that a DID could be resolved in two different ways, potentially leading to two different documents? Is that something I can do since i have control of my DID?

Kenneth Ebert: Emphasize we are not building identities, they are identifiers. You can wrap different identities in them with different use cases and characteristics. So this is a foundation piece, not the full package of everything.

Drummond Reed: The idea of decentralization is that you don’t need to rely on a single authority to give you the DID document, not that you might get two different documents.
… if you control the DID, then you aren’t relying on a third party to make sure you can get the DID Document. So depending on the DID method, you can get high assurance that a DID document is the real thing… which is what Certificate Authorities do, but they are doing it in a cerntralized way. Note that a couple of the biggest Cert Authorities are heavily involved in this work and see it as important to their work.

Markus Sabadello: there could be DIDs that two people can resolve in different ways because it depends on the method.

Phil Archer: the 4 elements are useful. Think we need to be careful about how we talk about this. There are a lot of IDs that meet 3 out of 4 (different sets of 3).
… We don’t have a technology nobody thought of before, and we need to remember not to annoy others by claiming we did…

Drummond Reed: I strongly agree with PhilA about the point that many other identifiers provide 2 or 3 of the four core properties of DIDs.

Daniel Burnett: If you have agreed to the IPR policy, please get a sticker from Grant so we know you can make a technical contribution without further ado.

6. Perspectives on DIDs

Brent Zundel: getting started again.
… next stretch: four presentations on DIDs, how they have been used, the technology, etc.
… each topic is about 30 min
… first up Markus Sabadello

6.1. Perspectives on DIDs - Ledger-Based

Markus Sabadello:
… Hello. From Vienna, Austria. New W3C member to contribute to W3C DID work.
… will talk about ledger-based DIDs
… those categories, e.g., ledger-based DIDs is not exhaustive.
… DIDs can be implemented in different ways and people have innovated with different approaches
… so while we started with blockchain, there are others.
… Blockchain as a distributed database can be useful for registering identifiers.
… This is also connected to the notion of Self Sovereign Identity from Christopher Allen
… the idea that identifiers or identities should be self-administered as a matter of human rights and derived from the enlightenment

Ivan Herman: See Markus’s presentation starting point

Markus Sabadello: DIDs can be created by writing data to the blockchain/DLT. (non-ledged DIDs use other means)
… Earliest design, the subject creates an identifier (“random”) and generate a key pair (asymmetric keys)
… then you can sign a transaction (or document) and store that on chain. Send a transaction to the blockchain with the public key and identifier and potential meta-data.
… then later you can prove control over that identifier because you have the private key.

Markus Sabadello: a second approach: create a key pair, then an identifier based on the public key, e.g., using a hash of the public key
… which is basically how bitcoin transactions work.
… the idea is to use that same mechanism not for transactions involving cryptocurrency, but for changes of state in identifiers.
… so instead of a centralized registry to request a key, the subject creates the key itself
… Another approach: create a key pair, with meta-data, and post a transaction.
… 4th key pair in wallet, write the identifier to a smart contract. This is similar to how some ethereum DID methods work.

Joe Andrieu: [I missed some details about the 3rd option]

Markus Sabadello: after writing a DID to the chain, it can be updated.
… of course, on the immutable ledger, you can’t change the transactions already posted, but you can post transactions that change the state for subsequent evaluation.
… the DID method always identifies the method-specific identifier and how you turn that identifier into a definitive DID document, which is called resolution.
… bitcoin methods use a different method, as the network itself wasn’t designed for DID creation, updates, and deactivations
… in the case of BTCR, it is a hybrid method, where some data is extracted on chain, including a pointer to secondary attributes which are combined to create the DID Document
… The identifier in BTCR points to a specific transaction
… while in Sovrin, its half of the public key.
… the point is that each Method can choose different mechanisms for resolving from the DID-specific identifier to the definitive DID document.
… Veres One supports DID documents natively.

Manu Sporny: the string is the public key for Veres One

Markus Sabadello: Ledger-based DIDs are globally resolvable
… the ledgers are accessible to anyone and therefore anyone can resolve any DID of these methods to the authoritative DID Document
… This has some interesting consequences for GDPR

Manu Sporny: This group is going to have to be particularly aware of GDPR and, in particular, how it affects ledger-based DIDs.
… at a minimum we need to warn implementers.
… There are privacy implications here and we want PING involved earlier rather than later.
… We’ll need to write about those.

Ivan Herman: I would say that we may want to go out and find experts in Europe. For some this has become a business to understand GDPR.

Kenneth Ebert: Are ledger-based DIDs the most predominant kind?
… what % in the registry are of that kind?

Markus Sabadello: not sure what % in registry is. It is still the most resonant/visible type of DIDs for people coming into the work

Tobias Looker: Could you talk a bit about the benefits of DLT DIDs versus those off-chain.

Markus Sabadello: may have privacy issues. But may be favorable to organizational needs (organizational DIDs)
… ledger-based DIDs may also be limited because the underlying ledger may have limitations

Phil Archer: re: GDPR. It’s not just the did document, it also that during resolution, you have the IP address.
… in various standards documents, you are often at odds. You’re basically saying “don’t break the law”. But if you highlight the issues well, you can avoid some of the complexity of that question (legal questions are open ended by nature)
… is an issue and we need to be away of it

Markus Sabadello: DID resolution does not necessarily need a server, with IP addresses as Phil brought up

Arnaud Le Hors: member of EU Blockchain Forum. We should look at the recent URL.

Arnaud Le Hors: Blockchain and GDPR report: https://www.eublockchainforum.eu/reports/

Arnaud Le Hors: There are a lot of people specialized in this. We should reach out to them.

Joe Andrieu: This is an answer to Tobias
… One of the biggest advantage is auditability
… Some of the other methods don’t allow you to look up a DID and understand what changes a DID Document has gone through.

Drummond Reed: at the Sovrin foundation, we just concluded 9 months of work to take some govt work for VCs and square it with GDPR.
… TLDR: there is a blog post (which I’ll post). New documents with Sovrin’s approach to this. With a shoutout to IBM and their legal team.
… not a panacea, but about ten lawyers grappling with these issues. Some of the best answers in the space today.

Drummond Reed: invited by GDPR regulators to come back and share their insights.
… You have chains and DIDs, but then you also have the role those DIDs in various identity systems. But there are also ledgers designed for decentralized identity, including decentralized identifiers.
… that includes Veres One from Digital Bazaar as well as Hyperledger Indy.

6.2. Perspectives on DIDs - Unanchored

Brent Zundel: next up Unanchored DIDs

Ivan Herman: See starting slide for the presentation

Kenneth Ebert: talking about unanchored DIDs
… such as Peer DID
… It’s a DID, just not anchored to a ledger
… DIDs are about relationships
… anywise DID: unknowable parties, publicly resolvable
… n-wise DIDs, n enumerated parties, privately resolvable
… Peer DIDs look like a regular did with method name “peer”
… benefits: they are cheap, fast, scalable, secure
… May be useful when you don’t need public resolvability
… scalable as a function of the participants
… Just as secure as other methods (because of crypto)
… This helps with GDPR concerns for transactions that don’t need to be public. Reducing PII exposure.
… Doesn’t carry the baggage (political or technical) of ledgers (or any particular ledger)
… Graftable into another DID, such as one anchored on ledger
… challenges: the backing storage
… ledgers provide that for some ledger-based DIDs. with Peer DIDs, you have to keep track of that yourself.
… both parties must have that information synchronized.
… this becomes further complicated if multiple agents are involved.
… such as a mobile wallet and cloud wallet
… One approach is to make that a conflict-free replicated data type (CRDT)
… options for CRUD operations via protocol
… Three layers of support in Peer DID
… 1. Recognize it is a Peer DID
… 2. Accept static DID (no key rotation), or Give Static (no key rotation)
… 3. Dynamic (key rotation, etc.), accept & give Peer DIDs (with key rotation)
… That summarizes Peer DID effort.
… Started at RWOT in the spring. Interesting because of how it removes congestion on network

6.3. Public Key-based DIDs

Kenneth Ebert: a similar approach is Public-Key-based DIDs, pioneered by Digital Bazaar
… Looks similar to Peer DID. method name: “key”
… identifier is an ed25519 public key
… benefits are similar to Peer DIDs
… self-describing aspect is new, but other benefits are retained
… Challenges of public key did: there is no key rotation
… this makes them similar the layer 2 Peer DIDs.
… sparked a conversation to merge or consolidated Peer DIDs and key dids
… and/or how to add rotation the did:key
… An interesting approach to a minimalistic DID method

Drummond Reed: Yes

Kenneth Ebert: The power of the technology is there to support other use cases (ones not originally conceived)
… Questions?

Pamela Dingle: Pamela Dingle from Microsoft. Lots of adjectives: public, unanchored, and resolvable. What are the distinctions here?

Kenneth Ebert: unanchored doesn’t mean unresolvable
… it’s resolvable to the parties involved.

Pamela Dingle: are all unanchored DIDs private?

Brent Zundel: they may not be public, but they may only be resolvable within the trust framework in which they operate
… if you publish on a DLT, anyone can look it up.

Kenneth Ebert: the ledger DIDs more strongly guarantee visibility of current DID Documents and provenance of changes over time.

Drummond Reed: What Ken is describing right now with peer DIDs and key rotation has been called “microledgers”.

Daniel Burnett: apologies that we didn’t give a presentation on DID Documents. We should have. Perhaps we can cover it later today or tomorrow.
… I didn’t see anything about how Peer DIDs are created. What makes a Peer DID?

Kenneth Ebert: in the ABNF, there is a numalgo, which specifies how you convert a seed into an identifier
… also a encalgo which specifies how that number is encoded
… both are fairly straightforward in the current spec.
… in Peer DID it is an elliptic curve (also a different elliptic curve for did:key)

Manu Sporny: did:key only supporded the ed25519 algo, but could support others

Kenneth Ebert: ditto. peer dids are designed to be extensible

Markus Sabadello: we have a session tomorrow about DID resolution. Resolving it means you have a way to get from the ID to the DID document.
… did:key does that without any network interaction at all. But that is still resolution.

Kenneth Ebert: in peer did, the local storage is on the local agents
… which happens to replicate some of the complexity currently handled by ledgers in ledger-based DIDs
… so auditability, etc., must be encoded explicitly

Drummond Reed: as you compare ledger / non-ledger DID methods. There isn’t really a hard line. It’s more of a spectrum
… the insight was ah-hah, we can use blockchain to address certain needs in identifier management.
… but what we realized we are often solving more generic patterns for cryptographic provenance
… There is no right and wrong.
… being able to find the cryptographic material for a given identifier is huge.
… shout out to Kim Cameron’s Laws of Identity
… Kim is “thrilled” about this work as it operationalizes his laws. In particular, omnidirectional and directed parties. “Justifiable parties”
… Identifiers serve a range of purposes. Those that need omnidirectional use serve a particular need. The keys need to be widely verifiable. In contrast to peer dids where verification is only relevant to the two parties.
… Also new post from Phil Windley

Kenneth Ebert: definitely a spectrum.

Daniel Burnett: or not even on spectrum

Joe Andrieu: I just wanted to connect the spectrum conversations to the rubric we’ll be discussing tomorrow. There is no singular spectrum… there are trade offs and choices.
… In one dimension, you need a specific value… in another dimension, you need another value.

Ivan Herman: from the outside: we have a use case document. It should reflect this spectrum well.

Drummond Reed: +1 to the use cases covering the full spectrum of DID methods that we are talking about here.

Kenneth Ebert: the range of use cases is substantial

6.4. Perspectives on DIDs - Layer 2

Ivan Herman: See start of ION’s presentation

Daniel Buchner: Going to present a DIF project, ION, one instantiation of a protocol that is blockchain agnostic
… ION runs on bitcoin, but other instantiations of the sidetree protocol run elsewhere, such as ethereum
… goal was to address scaling for publicly resolvable DIDs
… ION’s DIDs are publicly resolvable
… Why?
… Three things
… 1 Decentralization
… 2 Scalability
… 3 Security
… these have been traditional challenges
… Scale of decentralized identity is huge.
… [graphic of iceberg with human identities above the water and IoT identities below]
… We set out to solve that need for billions and billions of IDs
… So what do you need for DPKI

Joe Andrieu: 1. global immutable, append only log

Joe Andrieu: 2. no central providers or authorities

Joe Andrieu: 3. censorship and tamper resistant

Daniel Buchner: 1. global immutable, append only log
… 2. no central providers or authorities
… 3. censorship and tamper resistant
… key realization: identity doesn’t suffer from the same double spend problem of cryptocurrencies

Drummond Reed: “Should not be trivially interdictable” <== quote from CSUWildcat about a key goal of Sidetree and the ION DID method

Daniel Buchner: so if you assume that identities are transferable, you can scale much better
… doesn’t mean you can’t lose them, but they are not “saleable”
… ION is a public permissioned, decentralized DID overlay network that runs on Bitcoin, and leverages a deterministic DPKI protocol, called Sidetree
… Assumptions:
… 1. No secondary consensus required
… 2. No conflicting states are allowed
… 3. IDs are not transferable between entities
… System overview. If node 1 is writing a batch. It anchors a hash into bitcoin. That hash is a multihash in IPFS
… Then node 2 is observing the target chain, looking for hashes matching the pattern.
… Then it goes to IPFS to download the batch
… Then node 2 applies that batch of operations on their own state
… by each node processing all of the transactions, in the same order, results in a shared state
… five files: anchor file, batch file, …
… If you have anchor files, you can achieve the trustlessness of the system

Mike jones: Kazue needs to give the restaurant a count by 1:00pm

Daniel Buchner: State convergence
… If you’re all familiar with vector clocks, ION basically uses BTC as a vector clock.
… Changes are registered in the clock, which maintains order
… The trust is in the incremental increments of state
… the blockchain is replacing that trust and acting as a global deterministic clock to order objects, to align things over time
… ION is massive scale.
… Tens of billions or hundreds of billions of DPKI ops per year
… aggregate tens of thousands of ops in a single BTC transaction
… this is an economic scale we have to get to
… Also, its permissionless. You don’t need permission to participate.
… anyone can run a node and see the same state and perform all of the operations, as long as you can write bitcoin transactions
… Flexible nodes. Unlock a blockchain, you don’t need the ENTIRE set of files. Just the anchor files are sufficient.
… So you can start up a node on a limited device and just make sure your anchor files are available to that device, and that will ensure data integrity.
… Building the network: we anticipate lots of full nodes, a few terabytes of highly available data.
… in Stage 2 we’ll get moderately sized entities (like an insurance company) who wants to maintain a set of data. This is like the early adopters of Lightning (BTC Level 2 network)

Joe Andrieu: in Stage 3, we see a mix of large and small operators, LOTS of them

Daniel Buchner: in Stage 3, we see a mix of large and small operators, LOTS of them
… How to get involved. Sidetree is developed at DIF. Open source, under apache2
… also ION Node also at DIF. Please check it out and join us.

Manu Sporny: two questions. use of bitcoin and IPFS
… I understand this is lightning like, with off-ledger transactions, that then get anchored on BTC later. Does this mean the same kind of consensus delay as BTC? ~60 min to have confidence?
… or are you using something different?

Daniel Buchner: there is an ability to shorten that timeframe.
… the hash is the initial state of the DID document.
… the peer did works like this.
… So alice creates the DID Document, then posts that
… Short form ion identity? and a long form identity (which is the base64 encoded state)
… this means you can provide the long form, which might not yet be anchored on BTC…
… and someone running a full node can see that this is a singular state
… For updates, you just need updates.
… because we aren’t worried about double spend. It isn’t about whether or not alice gave state to multiple parties, but rather what is the state that Alice intends at this point in time.

Manu Sporny: the other question was about IPFS. My expectation is that we are storing these large batch files to speed up distribution.
… and that you’d also need to state that. There is an incentive to multi-stake so you don’t lose history.
… Is that correct?

Daniel Buchner: that’s right.
… articles are posted asking who will pay for this, as if its a single data store hosted by a monolithic entity
… but people & organizations will pay to ensure they data they care about is hosting
… some organizations have ~1/2 billion identifiers active.
… so 40 terabytes to support humanities identifiers doesn’t seem like that much
… Further, any player can host their own anchor files and ENSURE that the assets are on the network

Joe Andrieu: This is more of a comment, nuance and context, based on conversation at IIW.
… System does not depend on non-transferrability…. it’s really caveat emptor… identities could be sold, but buyer should beware, because it’s not worth it.

Daniel Buchner: You think you bought it, but you didn’t…

Daniel Burnett: thank you Daniel.
… Microsoft has not joined the group yet.

Daniel Buchner: we will be joining and I look forward to working with you all

6.5. Perspectives on DIDs - Alternatives

Ivan Herman: See starting slide

Daniel Burnett: last presentation of the morning is on Alternatives

Manu Sporny: These are an eclectic bunch to illustrate how much variance there is in the ecosystem
… There are a number of characteristics of alternate DID methods
… typically fall into these categories
… 1. Based on deployed tech
… 2. Utilize existing large networks
… 3. May not be truly “decentralized”
… 4. Don’t use cryptocurrency
… 5. Bridge the old world to the new, making the adjacent possible possible.
… Adjacent possible: many technical innovations happened precisely because the innovation was close to an existing technology, making it easy to transition.
… e.g., the width of railroads are the same width of chariots, thanks to adjacent possible driving innovation adoption
… did:web a DID method for the web
… did:web:example.com/jdoe
… take a DID document and put it on any website.
… uses existing CA system (some see this as a positive)
… Cons: no revision control. You can’t audit them. Whoever controls the website controls the document.
… Another negative: it uses the same CA system
… next up did:git
… DID method for developers
… pros: blockchain like version control, digital signed transaction history, highly decentralized
… cons: undetectable “forking” possible, no single point of truth, high potential for DOS.
… main use case is to find a better way to do code signing.
… git currently supports PGP signed code
… next up. did:ipid
… based on IPFS
… IPFS is global, but based on DHT (distributed hash table)
… benefit is it is massively scalable, but can be lossy
… also cheap. You can host on your own machine.
… the network will replicate if it starts getting used
… downside: if you take your store offline and there are no clones on the DHT, then the DID Document goes away
… this mean you basically have to pay someone else to maintain it
… economics of IPFS long term are still largely unknown
… last one: did:proprietary
… These are scary to some folks. e.g., did:facebook, did:linkedin, etc.
… here the namespace is fully owned by a private corporation or the government
… The good thing is that these DIDs are extremely cheap to maintain. These entities often have proven capability to run large IT infrastructure
… the bad thing is that these are centralized and fundamentally under the control of entities that can deny access.
… someone is going to launch one of these within the year.
… There is an appendix on the did:git method. It’s in the slide deck. Recommended reading.
… In closing, there are plenty of ways to create a DID, with different tradeoffs.

Drummond Reed: did:git, the hyperledger project has three sub projects, Indy, Ursa, and Airies.
… Aries
… Hyperledger is an umbrella project at Linux foundation. Supported by developers funded by Linux foundation. Those developers saw an opportunity to solve the problem of solving code commits.
… This was encouraging to see. These guys figured it out on their own and led their own charge.
… There was some question about whether or not did:git was a DID method as intended.

Kenneth Ebert: in doing the research for this, I was stunned by the wide variety of DID methods and usage that have popped up.
… the tradeoffs and decisions that are being made are not what I thought
… but that’s great, because its shown me there are broader uses than we may have initially thought

Manu Sporny: we had to pass up some of the alternatives. there are 32 methods and we haven’t reviewed them all. But maybe 75% are.
… there’s a DID snail mail protocol

Pamela Dingle: with did:proprietary would that include did:sov, did:v1?

Manu Sporny: there is a question about governance
… in the proprietary methods, EVERYTHING is centralized
… if you look at the governance in Sovrin, there is no single for-profit entity in charge
… on a technical layer, some of these mean that operationally, there isn’t an administrator in the loop for CRUD operations
… that’s why the rubric is so important. because you may have different models of governance

Phil Archer: This discussion on proprietary DIDs sounds very interesting and potentially on target for GS1, which is a federated system of IDs

Kenneth Ebert: manu’s characterization is just descriptive, not categorical or limiting

Brent Zundel: in the perspectives we just went through, we had challenges figuring out how we package them

Markus Sabadello: in the decentralized conversation, I was on the more radical side.
… that we can’t call did:facebook decentralized! (my opinion)
… but maybe the most important part is the universal syntax
… so you get to decide what you want on the back-end. Your choice. whether decentralized or not.

Joe Andrieu: I just wanted to connect your question, Pam, to the rubric… some feedback from Scott David - rules, governance, enforcement…
… There are some weird depths that aren’t obvious at the categorical level here… for example, BTC’s registry and network ar ethe same thing, but if you’re using Ethereum smart contracts, that is your network… you have to figure out which layer you’re looking at.

Drummond Reed: want to reinforce this point of categorization.
… I’m stunned at the variety.
… the takeaway: we ended up putting our finger on the core problem: not just how you identify something, but how do you prove it.
… there’s a different way to look at all of these things. Governance is the lens. EVERY single method has its approach. Specified in the spec includes the governance.
… what we are talking about is governance of this layer of the Internet.
… With decentralization: we realized we are not the definitive authority. Others will decide.

Charles ‘chaals’ (McCathie) Nevile: [so the shallow thing to take away is that how you find a DID method spec is pretty centralisable…]

Drummond Reed: But SOMEONE has to decide. That’s the hard work.
… And that is our responsibility as we go through the next two years.

Daniel Burnett: still need scribes for tomorrow afternoon. please sign up!
… dinner folks have a suggestion. We’ll make a count. So listen.

Drummond Reed: Hats off to JoeAndrieu for a great job of scribing a very difficult session to capture.

7. Introductions

David Ezell: (note: the scribe will not try to keep up with all introductions.)

Daniel Burnett: Let’s enter our names as we talk

Daniel Burnett: Dan Burnett

Brent Zundel: Brent Zundel

Ivan Herman: ivan Herman

Drummond Reed: Drummond Reed

Markus Sabadello: Markus Sabadello

Kenneth Ebert: Ken_Ebert

Kenneth Ebert: Ken_Ebert

Drummond Reed: JoeAndrieu: “DIDs are a topological change in society at the same level of packet switching.” <== great quote

gkellogg: Gregg Kellogg

Joe Andrieu: Joe Andrieu

Kangchan Lee: Kangchan Lee

Drummond Reed: Thanks for correcting that Joe—I was trying to remember exactly what you said

Phil Archer: Phil Archer

Mike jones: Mike Jones - Microsoft

Jim Huang: Jim Huang, BiiLabs Co., Ltd. / National Cheng Kung University, Taiwan

ssstolk: Sander Stolk - Semmtech

Grant Noble: Grant Noble

David Ezell: David Ezell - Conexxus

Andrei Sambra: Andrei Sambra - AKASHA Foundation

Jay Kishigami: Jay Kishigami, AB

Drummond Reed: Arnaud is being modest—he is the new CHAIR of the Hyperledger Technical Steering Committee

Shigeru Fujimura: Shigeru Fujimura, NTT, Japan

Dave Raggett: Dave Raggett - W3C

8. Documenting Use Cases

Ivan Herman: See Starting slide

Joe Andrieu: previous CCG work on use cases will form the basis of our ongoing use case work.
… use cases are always useful, separate discussion of what is possible from the solution. How are humans going to use what we produce.
… one technique is “domain map” of about 20 use cases.
… “focal” use cases move past a one paragraph description, but provide enough detail to be useful. They also include a threat model (before the fact).
… good use cases - concrete, distinctive, illustrative (of technology), memorable, short.
… we want to focus on what you can do with DIDs that you can’t do without them.
… using new names - not the same names - make the use cases more memorable.
… Lessons from Verifiable Credentials - titles matter, use multiple levels of bredth (domain map, scenarios, focal use cases), collect inferred reqs, track coverage against features.
… Difficulties arise if coverage isn’t apparent.
… https://w3c-ccg.github.io/did-use-cases/
… (examine the VC use cases document)
… this document has essential top-level use cases for DIDs.
… (see section 3.0)
… 4. Feature Benefit Grid
… maps features to five categories.
… several features in the list are very interesting, e.g., “survives end-of-life” dealing with deployed systems moving past their useful life.
… these features deal with very long life of credentials.
… “registry agnostic” - not sure we have any coverage on this feature.
… 6. Feature Coverage
… top-level = corporate, educational, prescriptions, digital executor, single sign-on
… 7. Focal use cases
… 7.1 Decentralized Corporate Identifiers
… 7.2 Life-long, recipient-managed credentials (education)
… blockchains do have the ability to evolve cryptography technology.
… key rotation is a particular problem for very long lived credentials.
… 7.3 Prescriptions (healthcare)
… privacy is an important aspect of this use case.
… important in this one to keep it simple.
… 7.4 Digital Executor (law)
… existing systems don’t allow identifiers indicating authority to later identifiers, making it difficult for executors.
… 7.5 Single Sign-on
… important for remote access use cases.
… (back to the slides)

Daniel Burnett: question is “what should this group do, based on the examples from CCG just presented.”

Joe Andrieu: final questions - how do we move forward from the CCG document.

Manu Sporny: 1) looking at use cases (crowdsourced) - all lot that came out sounded more like VCs as opposed to DIDs. So group needs to make a conscious effort to differentiate. Make it clear that there is a broader ecosystem, and how DIDs fit in that ecosystem.
… 2) some things seem to be missing - haven’t talked about encryption, ephemeral key negotiation, object based capabilities, delegation use cases in general.

Ivan Herman: (missed it)

Arnaud Le Hors: the documents are more extensive than I expected.

Drummond Reed: Overall, I think this CCG use case document is very well done - readable and meaningful. To the question “should we start with the document” my answer is “yes.”

Tobias Looker: I think we need an enumeration of unique properties in each identifier.

Andrei Sambra: We need more clarity on which are “in” or “out” of scope.

Drummond Reed: Chairs: can I nominate Joe to head up driving this work?

Joe Andrieu: In our spec documents, we need to be normative. The use cases are less more casual in this regard.
… things “not in scope” are actually “OK.”

Brent Zundel: no DIDs for communication, and are we going to use the CCGs use cases document as the starting point.

Phil Archer: very good document. One issue - “example code” is not really good, whereas “pseudo code” might be OK.
… I hereby offer to help with the use case document.

Joe Andrieu: in the document, we didn’t always know how to create a VC.

Daniel Burnett: DRAFT PROPOSAL: The Working Group will adopt the CCG DID Use Cases document as the starting point for our group’s DID Use Cases and Requirements document.

Proposed resolution: The Working Group will adopt the CCG DID Use Cases document as the starting point for our group’s DID Use Cases and Requirements document. (Daniel Burnett)

Manu Sporny: +1

Daniel Burnett: +1

Phil Archer: +1

Andrei Sambra: +1

Ivan Herman: +1

Drummond Reed: +1

Joe Andrieu: +1

Jay Kishigami: +1

Grant Noble: +1

Brent Zundel: +1

David Ezell: +1

Dudley Collinson: +1

Kenneth Ebert: +1

Kangchan Lee: +1

Markus Sabadello: +1

Tobias Looker: +1

Brent Zundel: no objections

Resolution #1: The Working Group will adopt the CCG DID Use Cases document as the starting point for our group’s DID Use Cases and Requirements document.

David Ezell: volunteering - phil, joe, ken, deiu

David Ezell: Congratulations on using the community process as well as you have, that’s what it’s for, that’s great to see.

Drummond Reed: very nice job on this work.

Daniel Burnett: other questions (logistical) remain. We have an empty repo, and we can talk with the editors about how to get started.

Ivan Herman: process question - we can keep the issues from the old repo if desired. Do we want to do that?

Drummond Reed: I think it bears recording in the minutes that Joe’s business is appropriately called Legendary Requirements. I think it’s appropriately named—even at this stage, its one of the best use case documents I have read.

Kenneth Ebert: what are the schedule expectations?

Joe Andrieu: Expect a draft of presented content ASAP (2-3 months). The give it a rest and come back to it later.

Daniel Burnett: we’d like to see who else ends up contributing. We’d like to avoid inactive editors.

Drummond Reed: +1

Gregg Kellogg: repository is “DID-use cases.” Should it be set to “DID-ucr?” (for requirements)

Daniel Burnett: would rather not overthink it right now.

Brent Zundel: There are 5 open issues in the existing CCG repository.

Daniel Burnett: DRAFT PROPOSAL: The Working Group will move the CCG DID Use case issues into our DID Use Cases and Requirements repository.

Phil Archer: -1

Ivan Herman: 0

Manu Sporny: +1

Manu Sporny: (strong +1)

David Ezell: +1

Kenneth Ebert: what are the repercussions of bringing over the issues?

Brent Zundel: open issues need to be addressed. But we can decide.

Jim Huang: https://github.com/w3c-ccg/did-use-cases/issues

Manu Sporny: I’m a strong +1 for bringing over all issues to be sure we don’t lose the history.
… I’ve seen important information lost in some situations.

Daniel Burnett: no agreement yet. We’ll come back and try to decide.

David Ezell: (break)

masa-jcb: masa-jcb has joined #did

Daniel Burnett: DRAFT PROPOSAL: The Working Group will move the CCG DID Use case issues into our DID Use Cases and Requirements repository. This does not indicate support for any of the issues, and any issue can be closed at any time.

Daniel Burnett: I talked w/ a few people during the break, there is an alternate proposal.
… we have flexibility in how we address the issues.
… if the comment is way out of scope, we can defer/close – that comment may come around at any point.

gkellogg: Just in support of that, if you don’t move something over, you never record the fact that you deferred. Move it over and then flag/close.

Manu Sporny: +1 to that.

Proposed resolution: The Working Group will move the CCG DID Use case issues into our DID Use Cases and Requirements repository. This does not indicate support for any of the issues, and any issue can be closed at any time. (Brent Zundel)

Manu Sporny: +1

Drummond Reed: +1

Ivan Herman: +1

Phil Archer: +1

Manu Sporny: +1

Andrei Sambra: +1

Dudley Collinson: +1

Tobias Looker: +1

David Ezell: +1

Daniel Burnett: +1

Kenneth Ebert: +0

Resolution #2: The Working Group will move the CCG DID Use case issues into our DID Use Cases and Requirements repository. This does not indicate support for any of the issues, and any issue can be closed at any time.

arnaud: https://github.com/w3c-ccg/did-use-cases/issues

Brent Zundel: https://github.com/w3c-ccg/did-use-cases

9. Technical Direction

Daniel Burnett: The WG needs to decide how to start – should we adopt the CCG DID v0.13 Data Model and Syntaxes final report for the WG spec?

David Ezell: What does “official starting point mean?”

Daniel Burnett: What it means is that we’ll copy the document over - that will be before the FPWD. The doc that we’ll turn into a FPWD… it’ll be the first Editor’s Draft.

Joe Andrieu: What about licensing commitments on that?

Daniel Burnett: I would like to call on the CCG Chairs for a status update on the licensing commitments.

Joe Andrieu: https://www.w3.org/community/credentials/spec/174/commitments

Joe Andrieu: For the Final Specification Agreement, looks like we have all contributors we need providing IPR release.

Daniel Burnett: Everyone that joined CCG had to make individual commitment, so technically we should be covered by that. In addition to that, we have commitments from all substantial editors for that document.

Joe Andrieu: What about David Chadwick?
… That’s the only name that jumped out at me.

Daniel Burnett: Why are we talking about this now? This slipped through the cracks, licensing commitment… but we got it done.
… We can look up history and see what the commitments are…

Mike jones: As a process point, I’d suggest deferring until we know it’s IPR clean… I’ve been involved in other efforts including OpenID 2.0 where we had to proactively chase down substantial contributors.
… Doing that enables people to use a spec that’s not IPR tainted.

Daniel Burnett: Yes, thank you for explaining that – the Chairs are aware of the reasoning.

Drummond Reed: I did just look at the list, the request is being made of the CCG, not every member contributed to the spec.
… An enormous amount of work has gone into the spec, five years worth of work, I’d definitely like to propose that it be the starting point… it will save the WG from a lot of other work.

Phil Archer: I’m one of the people that is a member of the CCG, which is why I’ve contributed nothing and haven’t signed. Is there any issue w/ adopting this work? Any potential reason why we wouldn’t start with this document?

Daniel Burnett: There is nothing I’ve heard from anywhere that have raised concerns around the document or its content.

Phil Archer: Is there any reason why the data model itself isn’t fit for purpose.

Manu Sporny: we were very careful from the beginning with IPR content. All PRs were pulled in from companies who have signed the IPR. We need to check on David Chadwick

Brent Zundel: I am checking all substantive contributors to the spec right now.

Manu Sporny: a few months ago I did the same thing, with no problems at the time. Nothing special from an IPR perspective. We have commitments from all substantive contributors.
… DavidC would definitely sign the agreement if needed. We have all the top contributors.

Brent Zundel: I see no direct contributions from David Chadwick

Drummond Reed: +1 to Manu’s point about the editor’s not seeing any IPR issues

Manu Sporny: we have been very careful in the CCG watching the progress and process here. I say we pull in the doc now.

Ivan Herman: I try to be practical here, this whole IPR question comes up when we want to publish a FPWD. The only thing we’re talking about now is to take over the document as an Editor’s Draft… based on what I’m hearing here, the risk of getting into an IPR issue before FPWD is very small. I think we should go ahead and smooth out any IPR issues over the next few weeks… at this point, we don’t need to halt the process.

Daniel Burnett: +100 to ivan. This was going to be my point as well.

Drummond Reed: Back in December 2018, the CCG started a set of calls, six months worth of work to prepare it for this WG. It’s not a coincidence, we’ve been designing it to take this step. As an editor on this, we’ve been watching for IPR issues, don’t know of a single one.

Kangchan Lee: My personal opinion, I’d like to emphasize that the previous version is already spread and people in Korea are translating already… just look at W3C document, outside of W3C, they don’t care… there are so many people already using spec, if the WG changes its position now, it’ll be very confusing to the outside world.

Daniel Burnett: I agree, I don’t think anyone has spoken yet about changing the direction.
… Ivan made my point, as Chair, I see no risk to adopting this document as an Editor’s Draft… before we can publish as a FPWD, we need to make sure that it’s as clean as possible, we need to give a report as WG CHairs.
… We are struggling to find anything that would be an IPR issue… I think it would be a greater risk of not making that decision and wasting the rest of our F2F time and not adopting that spec change.

Brent Zundel: I looked at all 24 contributors, they have all either 1) agreed to the IPR policy, or 2) did not make a substantive contribution.

Markus Sabadello: As the third editor on the document, I only pulled in content from people that were CCG members or have signed IPR policy.

Andrei Sambra: We can mark lines we might be concerned about w/ an at risk IPR bubble.

Daniel Burnett: DRAFT PROPOSAL: The Working Group will adopt the CCG “Decentralized Identifiers (DIDs) v0.13 Data Model and Syntaxes” Final Report as the first editors’ draft of our Recommendation-track document.

Proposed resolution: The Working Group will adopt the CCG “Decentralized Identifiers (DIDs) v0.13 Data Model and Syntaxes” Final Report as the first editors’ draft of our Recommendation-track document. (Daniel Burnett)

Brent Zundel: Any objections to that?

Ivan Herman: +1

Daniel Burnett: +1

Phil Archer: +1

Tobias Looker: +1

Drummond Reed: +1

Kenneth Ebert: +1

Joe Andrieu: +1

Andrei Sambra: +1

Markus Sabadello: +1

Manu Sporny: +1

David Ezell: +1

Grant Noble: +1

Amy Guy: +1

Brent Zundel: +1

Resolution #3: The Working Group will adopt the CCG “Decentralized Identifiers (DIDs) v0.13 Data Model and Syntaxes” Final Report as the first editors’ draft of our Recommendation-track document.

Dudley Collinson: +1

Shigeru Fujimura: +1

Drummond Reed: Yeah!

Manu Sporny: Wooo!

Daniel Burnett: Thank you, as WG Chairs, this was the biggest decision, it determines what we do from now on.

10. Github Issues

Daniel Burnett: Brent is going to be leading this…

Joe Andrieu: https://github.com/w3c-ccg/did-spec/issues

Brent Zundel: There are 52 open issues, currently triaged by the CCG. Some have been tagged.
… Some are questions and clarifications, etc.
… There are 5 questions… some have been addressed. Questions about the spec. If I have X, can I do Y?
… 11 issues are tagged clarify, non-testable normative statements, requests for greater specificity, rephrasing, document scope, etc.
… 9 issues are discussion issues, bigger questions, probably disagreement, invitation to do bike shedding
… for example, is authentication the right mechanism for proving control of a DID… should colon separator or kebab-case for method-specific stuff?
… 17 issues are editorial, rewordings, fact checking, mime type for DIDs.
… 13 are tagged elsewhere… it means that these issues are not related to DID spec.

Amy Guy: brent, that’s right, belong on another spec/repo

Brent Zundel: Do we pull these in? If we pull them in, we need to verify the triage and tagging - do we pull them all, do we pick and choose?

Markus Sabadello: some of the “elsewhere” issues have to do with keys/signatures/proofs/etc. there are other specs and repos for addressing those topics.

Daniel Burnett: manu: please pull them all in

Manu Sporny: Pull them all in

Phil Archer: I was skeptical about the other stuff, but these ones are issues, we need to look at them.

Brent Zundel: Does anyone feel like we shouldn’t do that?

Drummond Reed: In that six months of work, dedicated weekly calls, the last month of that were about closing down issues, which we closed a lot of them… this is not just some junk pile.

Joe Andrieu: Support pulling all of them in, if we are going to do a triage, should we tag them as triage? Who is doing the triage?
… The Editors?

Brent Zundel: Another voice for pulling them in… we do need to pick editors.

Andrei Sambra: Comment regarding closed issues, equally important, we want to avoid repeating history… I’m not saying we should pull them over, add link to previous repo, might be an issue open/closed about it.

Amy Guy: PRs still open: https://github.com/w3c-ccg/did-spec/pulls
… Some of them were going to be picked up again for the next version

Drummond Reed: Great point, @rhiaro

Manu Sporny: General acknowledgement that rhiaro is correct.

Brent Zundel: What to do with these is separate from the issues… I’d like to decide on the “issues” issue before moving on to PRs.
… As far as the issues go, I’d like to do a proposal so we can move on from that.

Manu Sporny: Are we moving the entire repo over?
… Group wasn’t possibly planning on it….

Brent Zundel: DRAFT PROPOSAL: The Working Group will move the CCG DID Spec issues into our DID Spec repository.

Ivan Herman: I have to find out re. admin overhead for renaming the old repo. There are lots of things already in place in terms of tooling (hooks, etc.).

Amy Guy: we could copy the issues and archive the w3c-ccg repo instead of moving the repo?

Ivan Herman: I have to find out piece by piece what needs to be done. That is my only concern.

Manu Sporny: My concern is that the CCG (and other WGs) are going to ping-pong specs over the next 5 years.
… for the VCWG, we transferred control to the spec repos.

Ivan Herman: W3C would not be happy about transferring ownership at the end, for archiving reasons.
… in 3 years from now, the CG will either have access to the W3C repo or not. You can’t take it away again. Once it’s there is there.

Manu Sporny: I’m concerned about losing the history within the repo.

Ivan Herman: The CG has its own history. If you transfer ownership of the repo, you break the history specific to the CG.
… it’s similar for the JSON-LD WG.
… it would be simpler to use the new repo, to which we copy the documents and decide what to do about the issues.
… we might be over-complicating things.

Manu Sporny: I still disagree pretty strongly, but won’t stand in the way.

Ivan Herman: The W3C WG point of view, what happened in the CG is not relevant, don’t take it personally, but this document has a new life here…

Tobias Looker: If we elect for a new history, we need to bring everyone along, by preserving that history it becomes clear how people that have seen the spec can come along, it’s hard to follow.

Daniel Burnett: Was going to respond to Ivan’s point, I can see both sides to this pretty easily. There has been a change, W3C used to charter groups for 4+ years, start work from near nothing… now W3C is suggesting the exact opposite, incubate as long. Ivan, you are correct technically, there are people in this WG that are not in the CG… this is a W3C issue, with pressure, to tell people participating from the CG that “we’re starting over”, it’s a hard sell.

Ivan Herman: I didn’t mean this to offend anyone, there is a publication issue… there is no way to say previous document, it starts from scratch… that’s the first public WD.
… In practice, this is a new document

Manu Sporny: We could rebase, move all issues over, that would probably make most people happy.

Joe Andrieu: I think it’s a slight misnomer to say we’d lose the history… it’s still in the CCG repo, we’re not going to lose history in any case… we will lose the point at which the history happened… if we just fork/rebase, how is it evident that this was the date of everything changes.

Brent Zundel: +1 to not really using the history

Andrei Sambra: Who would support transferring the repo from one org to another…. how many person hours would be taken moving everything over manually?

Ivan Herman: Moving HTML5 from one place to another is zero effort… the issues have to be taken somewhere… the fact of transferring them is one click away.

Joe Andrieu: I think these are two different organizations… just tried to do this for another repo, and the transfer tool at Github won’t allow this to be done. If you have admin rights on both orgs, it’s easy to do.
… I had a hard time moving repos… built in tool didn’t work.

Brent Zundel: The issue is if we want the issues in our repo at all…
… Do we want these issues?

Manu Sporny: +1 that we want all the issues.

Brent Zundel: DRAFT PROPOSAL: The Working Group will move the CCG DID Spec issues into our DID Spec repository.

Brent Zundel: DRAFT PROPOSAL: The Working Group will move the open CCG DID Spec issues into our DID Spec repository.

Pamela Dingle: A procedural question, if we move questions from people that are not WG members, is that an issue?

Ivan Herman: It’s not an issue.

Proposed resolution: The Working Group will move the open CCG DID Spec issues into our DID Spec repository. (Brent Zundel)

Joe Andrieu: +1

Drummond Reed: +1

Ivan Herman: +1

Phil Archer: +1

Manu Sporny: +1

Kenneth Ebert: +1

Brent Zundel: +1

Daniel Burnett: +1

Kangchan Lee: +1

Tobias Looker: +1

Andrei Sambra: +1

Dudley Collinson: +1

Amy Guy: +1

Grant Noble: +1

Markus Sabadello: +1

Yancy Ribbens: +1

David Ezell: +1

Resolution #4: The Working Group will move the open CCG DID Spec issues into our DID Spec repository.

Ivan Herman: You don’t refer to closed issues…
… Gregg is elsewhere, but it’s a problem that we never met in the JSON-LD WG… it was absolutely no problem.

Amy Guy: crossreferencing between issues right, not between the html doc and the issues..?

Ivan Herman: We did hit problems when transferring issues… what Gregg did was to open issues in the new repo, copying and referring back to the old one… that’s how we handled it… but that being put aside, referring back to closed issues, we never had that.

Amy Guy: surely if all the issues are copied across we can refer to the copies in the new repo though?

Daniel Burnett: manu: in the VCWG group we did have an issue and did have to point to closed issues. In JSON-LD it wasn’t as contentious. You often refer to old PRs as well.

Daniel Burnett: … this is a heavy load on editors over a long time vs. a short load on ivan that maybe we can help with.

Daniel Burnett: … would rather have the editors help you

Joe Andrieu: The tool I ended up using, I lost all provenance of who created issues… dates and all information is lost… concerned about that if we don’t move the repo.

Mike Jones: I went through this moving FIDO stuff over to W3C… I do support using the CG document as a starting point, but none of the decisions made by the CG are binding on the new WG, so I think it’s inappropriate to try to keep the two in sync, I’d start w/ a fresh copy, refer to issues from the CG w/ the full link. It has to do with the WG’s autonomy…

Phil Archer: Can we move on?

Andrei Sambra: Please note that labels and milestones won’t be transferred, and issue transfer only works if done within the same org or by the same owner.

Daniel Burnett: The Chairs wanted to see if there was new input, this is about whether or not we preserve history… we are gaining more info.

Daniel Burnett: q

Daniel Burnett: We are leaning toward stating that the WG is a new thing w/ a new start…

Mike jones: You can tell the CG that their spec is preserved, that their contributions are preserved and not muddied by stuff from a WG being interspersed by CG contributions. By not intermixing them, the contributions of the CG will remain clear in perpetuity.

Joe Andrieu: note Deiu’s comment: <deiu> Please note that labels and milestones won’t be transferred, and issue transfer only works if done within the same org or by the same owner.

Brent Zundel: Dan said - just because new transfer functionality … previous way that work was moved over, history is preserved and timing is clear. You know when WG took over processing, where to look for which pieces of information.

Daniel Burnett: The discussion here is about history - the world will see two documents, what happens? There are times when you want to get the sense of the WG, and there are times when we need to move on.
… We create new issues to point to old ones, to start history anew.
… I know that manu strongly disagrees with this… and we’ll hear about it.

Manu Sporny: I appreciate both positions, but I think you said it best when you said this is about preserving history. There is a large community that is not in this room. The general concern is that W3C’s position is that you incubate stuff in a CG and then transition to a WG. I’m hearing the opposite in the room, where we’re distancing ourselves from th

Andrei Sambra: e CG. It also means the WG can go back and revisit all decisions made by the CG. W3C membership is trying to do it both ways, but allowing WGs to completely change specs imported from CG.

Daniel Burnett: I agree with you and we’re going to hear from jeff_

Jeff Jaffee: Fully support manu’s perspective that we need to embrace the contributions of the CGs and certainly everyone that participated in the CGs, they should get credit, hope they get credit, no question that there needs to be that level of continuity.
… I also think that WG should be able to look at every decision made by CG because CGs operate w/o structure… there isn’t proper horizontal review, to bind WG that has formal process responsibilities to CG that doens’t have those responsibilities. We need to give WG power to make their own decisions.

Daniel Burnett: W3C has put itself in a tight position by shortening WGs w/ explanation that work can be done in a CG before hand… it’s hard to have your cake and eat it too.
… We have a WG here and we need to make our own decisions. This is a tough one, this is a discussion isn’t best now… it’s worth looking into what options we have in github. Our major decision about accepting spec and issues is done, we can start work on issues/specs/changes… we don’t have a way to do it yet before they end up in a repo, but from a chair perspective, most difficult items have been made today.
… I’d like to come back to this discussion topic on how this work shows up in Github until tomorrow. Between now and tomorrow, we can discuss this in dinner.

David Ezell: Just a quick question, as we discuss this tonight, in either case, if it’s a W3C repo, CG isn’t allowed to open issues?

Daniel Burnett: Anyone can raise issues.
… They are not WG members, but they can open issues… If you have multiple repos, what happens when issues are raised on multiple repos.

Kenneth Ebert: The decisions required for PRs… do we need to defer that?

Manu Sporny: brent pulls up existing PRs.

Ivan Herman: These should be treated differently from normal issues…

Manu Sporny: Chairs prepare a proposal…

Daniel Burnett: DRAFT PROPOSAL: The Working Group wants to keep all of the current CCG DID spec PRs that are actively in progress. Whether this occurs by copying, moving, or recreating is TBD.

Daniel Burnett: DRAFT PROPOSAL: The Working Group will keep all of the current CCG DID spec PRs that are actively in progress. Whether this occurs by copying, moving, or recreating is TBD.

Manu Sporny: +1

Markus Sabadello: +1

Amy Guy: +1

Andrei Sambra: +1

Yancy Ribbens: +1

Proposed resolution: The Working Group will keep all of the current CCG DID spec PRs that are actively in progress. Whether this occurs by copying, moving, or recreating is TBD. (Daniel Burnett)

Manu Sporny: +1

Amy Guy: +1

Ivan Herman: +1

Phil Archer: +1

Daniel Burnett: +1

Grant Noble: +1

Dudley Collinson: +1

Manu Sporny: +1

Yancy Ribbens: +1

Andrei Sambra: +1

Kenneth Ebert: +1

Brent Zundel: +1

David Ezell: +1

Drummond Reed: +1

Markus Sabadello: +1

Resolution #5: The Working Group will keep all of the current CCG DID spec PRs that are actively in progress. Whether this occurs by copying, moving, or recreating is TBD.

Tobias Looker: +1

Manu Sporny: Exhausted cheering and laughing.

Daniel Burnett: Anything else before we adjourn?
… This was a good meeting, I know the last two hours were exhausting… but that wasn’t that terrible, it was a good call.

11. Resolutions