DID Working Group Telco -- 16 Sep 2019

<ChristopherA> trackbot, start telcon

<ChristopherA> trackbot, status?

<manu> s/Yancy Ribbens/Yancy_Ribbens/

<drummond> There is a group working on audio now

<brent> present

<brent> present?

<ivan_> scribejs, set dsr Dave Raggett

<chaals> scribe: chaals

introductions

burnburn: please volunteer to scribe. The chairs already volunteered.

<ivan_> sribejs, set Arnaud Arnaud Le Hors

burnburn: 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.

<rhiaro> slides: https://docs.google.com/presentation/d/1ESS_6TuU7iHcAKkSB_py2zY5NJUKggs_uRDfEdl41HE/

burnburn: 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?

[Kazue volunteers]

<ivan_> scribejs, set Travis Travis Leithead

scribe: 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.

Process presentation

scribe: If you would like to add an agendum to the meeting, you can edit the slides - the relevant one is https://docs.google.com/presentation/d/1ESS_6TuU7iHcAKkSB_py2zY5NJUKggs_uRDfEdl41HE/edit#slide=id.g2a8b040676_0_58

Process

<ivan_> Dan's presentation

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

<Jc-Refinitiv> Thanks

s/thanks//

mission and goals.

scribe: Reminder, DID == Decentralised Identifier.

what is in scope

<inserted> SubTopic: Scope

Brent: 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 decentralised *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 adddress for DIDs, but that's it.

process of developing a spec. (Note that in the diagram, PR == Proposed Recommendation, whereas normally it will often mean pull request

<drummond> Brent the stand-up comedian: "Wait until we try to raise some PR by filing a PR for our first PR"

scribe: 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.

Once we get to Recommendation, it's stabilised, and beyond minor errata, we would need a new Working Group to make a major change.

Ivan: 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.

Burnburn: 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: We have 4 deliverables to produce.

deliverables.

scribe: 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: 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.

PhilA: 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: Hopefully we can take a lot of that, but we are here to formally decide on it.

Burnburn: We will talk about Rubric tomorrow.

subtopic: W3C Notes

burnburn: 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.

timeline plan

scribe: 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

scribe: So we probably want to get to what we think is Candidate Recommendation in November 2020.

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

scribe: 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: How often will the group be meeting, to move this forward?

Burnburn: 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: 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.

burnburn: 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.

Ken: Is this why we want the test suite early?

Brent: 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.

<ivan_> scribejs, gregg Gregg Kellogg

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

<ivan_> guest+ gkellog

Gregg: 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.

<ivan_> scribejs, gkellog Gregg Kellogg

Gregg: Same thing with examples - update them as you make changes to the spec.
... Strongly support getting the test suite work done up front.

<drummond> +1 to having the test suite stay close to the spec, and especially as soon as we get close to feature freeze

burnburn: 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: could you give us brief information on liaisons we need to keep up?

burnburn: don't think we have any official ones. There is Decentralised Identity Foundation.
... we are happy to talk to other organisations as they become relevant. Note that most other SDOs are talking about identity not identifiers

<manu> scribe+ manu

<manu> chaals: W3C internal horizontal review, do you have that?

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

<manu> ak chaals

<ivan_> guest+ Chunming

<Zakim> chaals, you wanted to talk about internal liaison / horizontal review.

<ivan_> scribejs, Chunming Chinming Hu

Drummond: Because there has been visibility of DIDs, there are other SDOs who want to know what is happening and where it is up to.

<ivan_> scribejs, set Chunming Chinming Hu

Drummond: e.g. ITU, OASIS are interested in the progress of this.

PhilA: I represent a centralised Identifier SDO - GS1, and will be effectively a liaison.

RongChen: We have an implementation already.

<drummond> What DID method is it?

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

<Zakim> dezell, you wanted to ask for strategy on "no new features"

<drummond> 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

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

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

<peacekeeper> current work items of the Credentials Community Group: https://github.com/w3c-ccg/community/blob/master/work_items.md

<brent> raise a PR to add yours or contact ivan_

Burnburn: 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.

<Zakim> manu, you wanted to note why we didn't list all these liasons...

Burnburn: 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: 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: Is there a liaison with the DIF?

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

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

<peacekeeper> DIF working group on Identifiers & Discovery: http://identity.foundation/working-groups/identifiers-names-discovery.html

Drummond: 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...

IRC tooling.

Ivan: 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.

burnburn: You can also say "q+ to …" and when you are acknowledged, you will get a reminder of the "…"

<Zakim> brent, you wanted to give an example of using this

[typing "/msg zakim, help" will get you more than you wanted to know about the things you can do…]

History of DIDs

<ivan_> subtopic: Brief history of DID

slides start here.

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

[IIW == Internet Identity Workshop, a conference that happens twice a year]

<ivan_> guest+ arnaud

scribe: 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 decentralised 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 Seccurity contract on Decentralised 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...

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

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

further slides - where did the terminology come from?

Drummond: Thanks to Manu, Dave and others for bringing this to W3C.

<yancy> yes audio is back

Drummond: Decentralisation 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> they are in the deck

<brent> https://docs.google.com/presentation/d/1ESS_6TuU7iHcAKkSB_py2zY5NJUKggs_uRDfEdl41HE/edit?pli=1#slide=id.g60978c4f6c_18_0

<ken> q_

Drummond: 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.

<JoeAndrieu> p28

what URNs and DIDs look like

<brent> the link i posted takes you to the first slide in his section

scribe: DIDs don't support unicode, which makes them easy to process

[chaals: so long as your keyboard is in latin]

some current usage information

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

<burn> gkellogg 'resulting document' is a vague term. We will need to explain resolution vs dereferencing to answer.

Drummond: 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

<Zakim> burn, you wanted to mention tie with Verifiable Credentials

<brent> https://www.w3.org/TR/vc-data-model/

<brent> data model spec

burnburn: 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

<Zakim> manu, you wanted to possibly elaborate on dan's point :)

that allow proof of control, which turned out to be pretty magical

<drummond> +1 to avoiding lock-in being a major reason de

Manu: 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

put into it.

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

<Zakim> JoeAndrieu, you wanted to challenge permanent

<drummond> +1 to data portability being a major driver

JoeAndrieu: resolvability will be something we discuss today, and some DID methods that are not globally resolvable, which is an important nuance to note.

<Zakim> gkellogg, you wanted to ask if dids resolve differ try for different uses, if the resulting document is guaranteed to be the same

JoeAndrieu: 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> +1 to Joe's points about the nuances of both persistence and resolvability

<burn> +1

<burn> We don't want to give the impression of a permanent identifier without understanding that this is NOT identity

Gregg: 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 decentralised 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?

Ken: Emphasise we are not building identities, they are identifiers. You canwrap different identities in them with different use cases and characteristics. So this is a foundaton piece, not the full package of everything.

Drummond: The idea of decentralisation 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 tehy are doing it in a cerntralised way. Note that a couple of the biggest Cert Authorities are heavily involved in this work and see it as important to their work.

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

PhilA: 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> I strongly agree with PhilA about the point that many other identifiers provide 2 or 3 of the four core properties of DIDs.

burnburn: 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.

[break]

<JoeAndrieu> scribe: JoeAndrieu

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

<ivan> Subtopic: Perspectives on DIDs - Ledger-Based

peacekeeper: ... 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> Markus's presentation starting point

peacekeeper: 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.

<burn> q

peacekeeper: 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.

[I missed some details about the 3rd option]

peacekeeper: 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: the string is the public key for Veres One

peacekeeper: 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

peacekeeper: 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

<Zakim> manu, you wanted to note that we need to pay attention to GDPR and how it affects DID Methods in ths group...

manu: 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: 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.

ken: Are ledger-based DIDs the most predominant kind?
... what % in the registry are of that kind?

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

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

peacekeeper: 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

phila: 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

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

arnaud: member of EU Blockchain Forum. We should look at the recent URL.
... There are a lot of people specialized in this. We should reach out to them.

<manu> JoeAndrieu: This is an answer to Tobias

<ivan> scribe+ manu

<manu> JoeAndrieu: One of the biggest advantage is auditability

<Arnaud> Blockchain and GDPR report: https://www.eublockchainforum.eu/reports/

<manu> JoeAndrieu: 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: 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.

<brent> acj JoeAndrieu

<Zakim> JoeAndrieu, you wanted to talk about auditability of ledger-DIDs

drummond: 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.

<ivan> Subtopic: Perspectives on DIDs - Unanchored

brent: next up Unanchored DIDs

<ivan> starting slide for the presentation

ken: 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

<ivan> Subtopic: Public Key-based DIDs

ken: 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> Yes

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

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

ken: unanchored doesn't mean unresolvable
... it's resolvable to the parties involved.

pamela: are all unanchored DIDs private?

<ivan> guests+ pamela

brent: 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.

<ivan> scribejs, set pamela Pamela Dingle

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

<drummond> What Ken is describing right now with peer DIDs and key rotation has been called "microledgers".

burn: apologies that we didn't give a presentation on DID Documents. We should have. Perhaps we can cover it later today or tomorrow.

<Zakim> burn, you wanted to ask how Peer DIDs are created

burn: I didn't see anything about how Peer DIDs are created. What makes a Peer DID?

ken: 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 ellipitic curve for did:key)

manu: did:key only suppored the ed25519 algo, but could support others

ken: ditto. peer dids are designed to be extensible

peacekeeper: 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.

ken: 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: 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

ken: definitely a spectrum.

burn: or not even on specturm

<Zakim> JoeAndrieu, you wanted to highlight rubric

<manu> JoeAndrieu: 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.

<manu> JoeAndrieu: In one dimension, you need a specific value... in another dimension, you need another value.

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

<drummond> +1 to the use cases covering the full spectrum of DID methods that we are talking about here.

ken: the range of use cases is substantial

<ivan> Subtopic: Perspectives on DIDs - Layer 2

<ivan> scribejs, set csuwildcat Daniel Buchner

<JoeAndrieu_> my old nick got blasted.

<JoeAndrieu_> scribe: JoeAndrieu_

csuwildcat: 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

<ivan> guests+ csuwildcat

csuwildcat: 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

1. global immutable, append only log

2. no central providers or authorities

3. censorship and tamper resistant

csuwildcat: 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> "Should not be trivially interdictable" <== quote from CSUWildcat about a key goal of Sidetree and the ION DID method

<Kazue> I have dinner details in the google doc

csuwildcat: 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 legverages 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

<ivan> start of ION's presentation

csuwildcat: 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

<selfissued> Kazue needs to give the restaurant a count by 1:00pm

csuwildcat: 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 terrabytes 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)

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

csuwildcat: 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.

<Zakim> manu, you wanted to ask if ion is limited by Bitcoin consensus times for batches? to ask if data needs to be staked on IPFS?

manu: two questions. use of bitcoin and IPFS
... I understand this is lightning like, with off-ledger transactions, that then get ancored 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?

csuwildcat: 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: 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?

csuwildcat: 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 terrabytes 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

<manu> JoeAndrieu_: This is more of a comment, nuance and context, based on conversation at IIW.

<manu> JoeAndrieu_: 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.

<manu> DanielB: You think you bought it, but you didn't...

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

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

<ivan> subtopic: Perspectives on DIDs - Alternatives

burn: last presentation of the morning is on Alternatives

<ivan> starting slide

manu: These are an eclectic bunch to illustrate how much variance there is in the ecosystem

<ivan> scribe+ dezell

manu: 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: 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.

ken: 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: 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: with did:proprietary would that include did:sov, did:v1?

manu: 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

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

ken: manu's characterization is just descriptive, not categorical or limiting

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

peacekeeper: 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.

<Zakim> JoeAndrieu_, you wanted to mention governance questions in rubric

<manu> JoeAndrieu_: I just wanted to connect your question, Pam, to the rubric... some feedback from Scott David - rules, governance, enforcement...

<manu> JoeAndrieu_: 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.

<Zakim> drummond, you wanted to talk about governance

drummond: 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.

<chaals> [so the shallow thing to take away is that how you find a DID method spec is pretty centralisable…]

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

burn: still need scribes for tomorrow afternoon. please sign up!
... dinner folks have a suggestion. We'll make a count. So listen.

<drummond> Hats off to JoeAndrieu for a great job of scribing a very difficult session to capture.

kazue: we can get a room of 25 people in JR Kyushu Hotel Blossom Fukoaka
... fixed course: lots of yummy stuff. Very typical Japanese
... sitting tatami style will provide a nice Japanese experience.
... 5000 yen in cash. Will ask if we can individually pay with credit cards.
... need final #s. They can support vegetarian.

<ivan> scribe- chaals

burn: details are in the slide deck

<ivan> scribe- JoeAndrieu_

<brent> Present

Introductions

<dezell> (note: the scribe will not try to keep up with all introductions.)

<burn> Let's enter our names as we talk

<burn> Dan Burnett

<brent> Brent Zundel

<ivan_> ivan Herman

<drummond> Drummond Reed

<peacekeeper> Markus Sabadello

<ken_> Ken_Ebert

<drummond> JoeAndrieu: "DIDs are a topological change in society at the same level of packet switching." <== great quote

<gkellogg> Gregg Kellogg

<JoeAndrieu> Joe Andrieu

<Kangchan> Kangchan Lee

<drummond> Thanks for correcting that Joe—I was trying to remember exactly what you said

<phila> Phil Archer

<selfissued> Mike Jones - Microsoft

<jserv--> Jim Huang, BiiLabs Co., Ltd. / National Cheng Kung University, Taiwan

<ssstolk> Sander Stolk - Semmtech

<grantnoble> Grant Noble

<dezell> David Ezell - Conexxus

<deiu> Andrei Sambra - AKASHA Foundation

<jay> Jay Kishigami, AB

<drummond> Arnaud is being modest—he is the new CHAIR of the Hyperledger Technical Steering Committee

<Fuji> Shigeru Fujimura, NTT, Japan

<dsr> Dave Raggett - W3C

Documenting Use Cases

<ivan_> Starting slide

<dezell> JoeAndrieu: previous CCG work on use cases will form the basis of our ongoing use case work.

<dezell> ...: use cases are always useful, separate discussion of what is possible from the solution. How are humans going to use what we produce.

<dezell> ... one technique is "domain map" of about 20 use cases.

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

<dezell> ... good use cases - concrete, distinctive, illustrative (of technology), memorable, short.

<dezell> s/\.:/:

<dezell> ... we want to focus on what you can do with DIDs that you can't do without them.

<dezell> ... using new names - not the same names - make the use cases more memorable.

<dezell> ... Lessons from Verifiable Credentials - titles matter, use multiple levels of bredth (domain map, scenarios, focal use cases), collect inferred reqs, track coverage against features.

<dezell> ... Difficulties arise if coverage isn't apparent.

<dezell> ... https://w3c-ccg.github.io/did-use-cases/

<dezell> ... (examine the VC use cases document)

<dezell> ... this document has essential top-level use cases for DIDs.

<dezell> ... (see section 3.0)

<dezell> ... 4. Feature Benefit Grid

<dezell> ... maps features to five categories.

<dezell> ... several features in the list are very inteesting, e.g., "survives end-of-life" dealing with deployed systems moving past their useful life.

<dezell> ... these features deal with very long life of credentials.

<dezell> ... "registry agnostic" - not sure we have any coverage on this feature.

<dezell> ... 6. Feature Coverage

<dezell> ... top-level = corporate, educational, prescriptions, digital executor, single sign-on

<dezell> ... 7. Focal use cases

<dezell> ... 7.1 Decentralized Corporate Identifiers

<dezell> ... 7.2 Life-long, receipient-managed credentials (education)

<dezell> ... blockchains do have the ability to evolve cryptography technology.

<dezell> ... key rotation is a particular problem for very long lived credentials.

<dezell> ... 7.3 Prescriptions (healthcare)

<dezell> ... privacy is an important aspect of this use case.

<dezell> ... important in this one to keep it simple.

<dezell> ... 7.4 Digital Executor (law)

<dezell> ... existing systems don't allow identifiers indicating authority to later identifiers, making it difficult for executors.

<dezell> ... 7.5 Single Sign-on

<dezell> ... important for remote access use cases.

<dezell> ... (back to the slides)

<dezell> burn: question is "what should this group do, based on the examples from CCG just presented."

<dezell> JoeAndrieu: final questions - how do we move forward from the CCG document.

<dezell> (move to the queue.)

<Zakim> manu, you wanted to wonder about encryption, authorization capabilities, and delegation -- later, but important to track. and to wonder how many of these are verifiable credential

<tplooker> p+

<dezell> manu: 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.

<dezell> ... 2) some things seem to be missing - haven't talked about encryption, ephemeral key negotiation, object based capabilities, delegation use cases in general.

<dezell> ivan_: (missed it)

<dezell> Arnaud: the documents are more extensive than I expected.

<dezell> drummond: 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."

<dezell> tplooker: I think we need an enumeration of unique properties in each identifier.

<Zakim> deiu, you wanted to ask about doing a triage for in-scope use cases

<dezell> deiu: We need more clarity on which are "in" or "out" of scope.

<drummond> Chairs: can I nominate Joe to head up driving this work?

<dezell> JoeAndrieu: In our spec documents, we need to be normative. The use cases are less more casual in this regard.

<dezell> ... things "not in scope" are actually "OK."

<Zakim> brent, you wanted to talk about DID Comms

<dezell> brent: no DIDs for communication, and are we going to use the CCGs use cases document as the starting point.

<dezell> phila: very good document. One issue - "example code" is not really good, whereas "pseudo code" might be OK.

<dezell> ... I hearby offer to help with the use case document.

<dezell> JoeAndrieu: in the document, we didn't always know how to create a VC.

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

<burn> PROPOSED: 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.

<manu> +1

<burn> +1

<phila> +1

<deiu> +1

<dezell> brent: Proposed: "The working group will adopt the CCG use cases document as the starting point for the DIDs WG use cases document."

<ivan_> +1

<drummond> +1

<JoeAndrieu> +1

<jay> +1

<grantnoble> +1

<brent> +1

<dezell> +1

<Dudley> +1

<ken_> +1

<Kangchan> +1

<peacekeeper> +1

<tplooker> +1

<dezell> brent: no objections

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.

<dezell> volunteering - phil, joe, ken, deiu

<manu> s/drumond, deiu/deiu/

<manu> dezell: Congratulations on using the community process as well as you have, that's what it's for, that's great to see.

<dezell> drummond: very nice job on this work.

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

<dezell> ivan_: process question - we can keep the issues from the old repo if desired. Do we want to do that?

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

<dezell> ken: what are the schedule expectations?

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

<dezell> burn: we'd like to see who else ends up contributing. We'd like to avoid inactive editors.

<drummond> +1

<dezell> gkellogg: repository is "DID-use cases." Should it be set to "DID-ucr?" (for requirements)

<dezell> burn: would rather not overthink it right now.

<dezell> brent: There are 5 open issues in the existing CCG repository.

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

<phila> -1

<ivan_> 0

<manu> +1

<manu> (strong +1)

<dezell> +1

<dezell> ken: what are the repercussions of bringing over the issues?

<dezell> brent: open issues need to be addressed. But we can decide.

<jserv--> https://github.com/w3c-ccg/did-use-cases/issues

<dezell> manu: I'm a strong +1 for bringing over >all< issues to be sure we don't lose the history.

<dezell> ... I've seen important information lost in some situations.

<dezell> burn: no agreement yet. We'll come back and try to decide.

<dezell> (break)

<manu> scribe: manu

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

burn: I talked w/ a few people during the break, there is an alternate proposal.

<dezell> burn: we have flexibility in how we address the issues.

burn: if the commenter 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: +1 to that.

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

<drummond> +1

<ivan_> +1

<phila> +1

manu: +1

<deiu> +1

<Dudley> +1

<tplooker> +1

<dezell> +1

<burn> +1

<ken> +0

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.

<Arnaud> https://github.com/w3c-ccg/did-use-cases/issues

<brent> https://github.com/w3c-ccg/did-use-cases

Technical Direction

<brent> ACTION: Ivan to move the CCG DID Use case issues into our DID Use Cases and Requirements repository.

burn: 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?

dezell: What does "official starting point mean?"

<Zakim> JoeAndrieu, you wanted to ask about licensing commitments

burn: 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.

JoeAndrieu: What about licensing commitments on that?

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

General laughing...

<JoeAndrieu> https://www.w3.org/community/credentials/spec/174/commitments

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

burn: 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.

JoeAndrieu: What about David Chadwick?
... That's the only name that jumped out at me.

burn: 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...

selfissued: 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.

burn: Yes, thank you for explaining that -- the Chairs are aware of the reasoning.

drummond: 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.

<Zakim> phila, you wanted to ask about the data model

phila: 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?

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

phila: Is there any reason why the data model itself isn't fit for purpose.

<burn> manu: 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

<burn> brent: I am checking all substantive contributors to the spec right now.

<burn> manu: 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.

<burn> ... DavidC would definitely sign the agreement if needed. We have all the top contributors.

<burn> brent: I see no direct contributions from David Chadwick

<drummond> +1 to Manu's point about the editor's not seeing any IPR issues

<burn> manu: we have been very careful in the CCG watching the progress and process here. I say we pull in the doc now.

ivan_: 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.

<burn> +100 to ivan. This was going to be my point as well.

drummond: 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.

<Zakim> burn, you wanted to say that as chair I see no risk to adopting as editor's draft

Kangchan: 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.

burn: 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: I looked at all 24 contributors, they have all either 1) agreed to the IPR policy, or 2) did not make a substantive contribution.

<Zakim> deiu, you wanted to suggest we mark those lines as "at risk"

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

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

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

<burn> PROPOSED: 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.

brent: Any objections to that?

<ivan_> +1

<burn> +1

<phila> +1

<tplooker> +1

<drummond> +1

<ken> +1

<JoeAndrieu> +1

<deiu> +1

<peacekeeper> +1

manu: +1

<dezell> +1

<grantnoble> +1

<rhiaro> +1

<brent> +1

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.

<Dudley> +1

<Fuji> +1

<drummond> Yeah!

manu: Wooo!

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

Github Issues

burn: Brent is going to be leading this...

<JoeAndrieu> https://github.com/w3c-ccg/did-spec/issues

brent: 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.

<rhiaro> brent, that's right, belong on another spec/repo

brent: 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?

<peacekeeper> some of the "elsewhere" issues have to do with keys/signatures/proofs/etc. there are other specs and repos for addressing those topics.

<burn> manu: please pull them all in

manu: Pull them all in

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

brent: Does anyone feel like we shouldn't do that?

drummond: 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.

JoeAndrieu: 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: Another voice for pulling them in... we do need to pick editors.

deiu: 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.

<Zakim> rhiaro, you wanted to say don't forget a few deferred PRs

<rhiaro> PRs still open: https://github.com/w3c-ccg/did-spec/pulls

<rhiaro> Some of them were going to be picked up again for the next version

<drummond> Great point, @rhiaro

General acknowledgement that rhiaro is correct.

brent: 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: Are we moving the entire repo over?

Group wasn't possibly planning on it....

<brent> DRAFT PROPOSAL: The Working Group will move the CCG DID Spec issues into our DID Spec repository.

<deiu> scribenick: deiu

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

<rhiaro> we could copy the issues and archive the w3c-ccg repo instead of moving the repo?

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

manu: 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_: 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: I'm concerned about losing the history within the repo.

ivan_: 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: I still disagree pretty strongly, but won't stand in the way.

<manu> ivan: The W3C WG point of view, what happened in the CG is irrelevant, don't take it personally, but this document has a new life here...

<manu> tplooker: 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.

<manu> burn: 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.

<manu> ivan: 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.

<manu> ivan: In practice, this is a new document

<Zakim> JoeAndrieu, you wanted to mention history v provenance

<manu> manu: We could rebase, move all issues over, that would probably make most people happy.

<Zakim> manu, you wanted to ask if CCG can continue to work on DID spec in parallel? Or point to WG version?

<manu> JoeAndrieu: 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> +1 to not really using the history

<Zakim> deiu, you wanted to ask for a poll to see what support there is for forking

<manu> deiu: Who would support transferring the repo from one org to another.... how many person hours would be taken moving everything over manually?

<manu> ivan: 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.

<manu> JoeAndrieu: 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.

<manu> JoeAndrieu: I had a hard time moving repos... built in tool didn't work.

<Zakim> manu, you wanted to say we tag/commit message.

<manu> brent: The issue is if we want the issues in our repo at all...

<manu> brent: Do we want these issues?

<manu> manu: +1 that we want all the issues.

<brent> DRAFT PROPOSAL: The Working Group will move the CCG DID Spec issues into our DID Spec repository.

<brent> DRAFT PROPOSAL: The Working Group will move the open CCG DID Spec issues into our DID Spec repository.

<manu> pamela: A procedural question, if we move questions from people that are not WG members, is that an issue?

<manu> ivan: It's not an issue.

<brent> PROPOSED: The Working Group will move the open CCG DID Spec issues into our DID Spec repository.

<JoeAndrieu> +1

<drummond> +1

<ivan_> +1

<phila> +1

<manu> +1

<ken> +1

<brent> +1

<burn> +1

<Kangchan> +1

<tplooker> +1

<Dudley> +1

<rhiaro> +1

<grantnoble> +1

<peacekeeper> +1

<yancy> +1

<dezell> +1

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

<Zakim> manu, you wanted to ask the same question of closed issues? Mostly because it's going to put a burden on Editors to refer to things by complete URLs.

<manu> ivan: You don't refer to closed issues...

<manu> ivan: Gregg is elsewhere, but it's a problem that we never met in the JSON-LD WG... it was absolutely no problem.

<rhiaro> crossreferencing between issues right, not between the html doc and the issues..?

<manu> ivan: 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 handle it... but that being put aside, referring back to closed issues, we never had that.

<Zakim> manu, you wanted to note that you do

<rhiaro> surely if all the issues are copied across we can refer to the copies in the new repo though?

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

<burn> ... this is a heavy load on editors over a long time vs. a short load on ivan that maybe we can help with.

<burn> ... would rather have the editors help you

<manu> JoeAndrieu: 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.

<manu> selfissued: 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...

<Zakim> phila, you wanted to politely scream

<manu> phila: Can we move on?

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.

<manu> burn: The Chairs wanted to see if there was new input, this is about whether or not we preserve history... we are gaining more info.

<burn> q

<manu> burn: We are leaning toward stating that the WG is a new thing w/ a new start...

<manu> selfissued: 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.

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

<manu> brent: 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.

<manu> burn: 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.

<manu> burn: We create new issues to point to old ones, to start history anew.

<manu> burn: I know that manu strongly disagrees with this... and we'll hear about it.

manu: 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

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.

burn: I agree with you and we're going to hear from jeff_

<manu> jeff: 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.

<burn> This was the point I made earlier that W3C has put itself in a tight position here by shortening WGs with the explanation that they can be shorter because most of the work should be done in the CG

<manu> jeff: 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.

<manu> burn: 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.

<manu> burn: 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.

<Zakim> jeff_, you wanted to comment on WG re-looking at CG decisions

<manu> burn: 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.

<Zakim> dezell, you wanted to ask one question

<manu> dezell: 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?

<manu> burn: Anyone can raise issues.

<manu> burn: They are not WG members, but they can open issues... If you have multiple repos, what happens when issues are raised on multiple repos.

<manu> ken: The decisions required for PRs... do we need to defer that?

<manu> brent pulls up existing PRs.

<manu> ivan: These should be treated differently from normal issues...

<manu> Chairs prepare a proposal...

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

<burn> 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> +1

<peacekeeper> +1

<rhiaro> +1

<yancy> +1

<burn> PROPOSED: 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> +1

<rhiaro> +1

<ivan_> +1

<phila> +1

<burn> +1

<grantnoble> +1

<Dudley> +1

<manu> manu: +1

<yancy> +1

<ken> +1

<brent> +1

<dezell> +1

<drummond> +1

<peacekeeper> +1

RESOLUTION: 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.

<tplooker_> +1

<manu> Exhausted cheering and laughing.

<manu> burn: Anything else before we adjourn?

<manu> burn: This was a good meeting, I know the last two hours were exhausting... but that wasn't that terrible, it was a good call.

- DRAFT -

DID Working Group Telco

16 Sep 2019

Attendees

Contents

introductions

Process presentation

Process

IRC tooling.

History of DIDs

Introductions

Documenting Use Cases

Technical Direction

Github Issues

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output