DID WG (Virtual) F2F Meeting, 1st Day — Minutes

Date: 2020-11-02

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Daniel Burnett, Shigeya Suzuki, Brent Zundel, Dave Longley, Justin Richer, Michael Jones, Amy Guy, Kaliya Young, Kristina Yasuda, Markus Sabadello, Dmitri Zagidulin, Geunhyung Kim, Manu Sporny, Joe Andrieu, Adrian Gropper, Jonathan Holt, Drummond Reed, Juan Caballero, Phil Archer, Orie Steele, Leonard Tan, Wang Haiguang

Regrets:

Guests: Jeff Jaffe, Tomoaki Mizushima, Mizushima, Jean-Yves Rossi, daisuke, fujiia, Jay Kishigami, Duy-Tung Luu, Kazuaki Arai, Masa Mashita, Shigeru Fujimura, Takashi Minamii, Tetsuya Kono, Tomoyaki Mizushima

Chair: Daniel Burnett, Brent Zundel

Scribe(s): Manu Sporny, Markus Sabadello, Amy Guy

Content:

Ivan Herman: Slide deck: https://tinyurl.com/yyc5fu63

1. agenda recap, meeting planning

Joe Andrieu: See slide

Brent Zundel: For the agenda today… we’re going to start out w/ going over CR
… or rather the process to CR and the process overall
… Then we’re going to dive into preventing privacy violating properties… discussion around type and more.
… Please volunteer to scribe, we need scribes.
… The goal of the DID WG is to standardize the DID URI scheme, data model, syntax of DID documents
… DID Core is our recommendation-track specification
… we’re hoping to get through big issues this week
… We also have Notes as deliverables (DID Use Cases, Decentralized Characteristics Rubric)
… Other deliverables are the registries, test suites
… Reminder: WD do not imply consensus
… A Candidate Recommendation needs to be feature-complete, wide review, and it needs to specify implementation requirements for exiting CR
… To exit CR, there must not have been substantive changes
… A Proposed Recommendation (PR) is a sanity check where hopefully nothing major happens
… Then W3C votes on making it a Recommendation
… We entered FPWD, we are working toward CR. Original goal for first CR was November this year.
… At this point it’s highly unlikely we will achieve that goal. We will discuss reconfiguring our timeline
… We’re not in trouble, but let’s work hard.
… We entered “feature freeze” in July (rather than May)
… We wrote December 2020 for CR1. This will give us enough time for implementation, and to see if we need a second CR by March.
… If we can hit this timeline, then we have the time we need for implementation, review, and to reach Recommendation.
… This meeting has 3 primary goals: 1. Get everyone on the same page what work remains for CR, 2. Resolve major outstanding issues (topics from the last few months - Abstract Data Model, and privacy concerns)
… These are the topics we really want to resolve
… We also have around 60 open issues, this is way too many. We want to resolve 25% during this F2F.

2. introductions

Brent Zundel: I’d like to open up for introductions
… Everybody please introduce themselves, say something about yourself

Ivan Herman: When you are a guest, please write your name in IRC!

Brent Zundel: ivan please introduce.

Ivan Herman: I am staff contact for this Working Group, it’s my job to be interested :-)

Daniel Burnett: I am co-chair with Brent of this Working Group, I am ED of the Enterprise Ethereum Alliance. Started working in W3C in 1999.
… Started working on DID in the early days, it’s a real joy to see things move forward.

Juan Caballero: i am juan caballero, researcher, here on behalf of Spruce ID. not active on github so will try to take up as little time as possible.
… I’m just here as a guest se well, just observing.

Brent Zundel: jeff please introduce.

Jeff Jaffe: I am CEO at W3C. I’m just here to observe.

Phil Archer: Phil Archer from GS1, we do the barcodes, very involved in supply chain industries. We’re very interested in DIDs and VCs to support this process.

Adrian Gropper: Adrian Gropper, invited expert on privacy. I am very excited to be working on use cases as they relate to the DID spec. Working on HIE of one to be standard compliant.

daisuke: I am working at Japanese broadcasting (?) corporation. I am interested in decentralized architecture, including DIDs and VCs.

Dave Longley: I am CTO of Digital Bazaar. I have been working on DIDs and other standards for a decades, these power our technologies at Digital Bazaar.

Dmitri Zagidulin: Software engineer at Digital Bazaar. Secure Data Store Working Group. Co-editor of did:web and did:key methods.

fujiia: It’s my first time joining this meeting for research purposes.

Drummond Reed: @Dmitri - can you say more about the renaming of SDS?

Geunhyung Kim: I am Geun Hyung Kim, I represent a company in South Korea (Gooroomee Co., Ltd), I am for the first time in this meeting. I am interested in DID specifications. I want to apply them in several applications that require decentralized identity.

Jay Kishigami: I am interested in DID and VC, I expect a good discussion here. In Japan it’s midnight so I can’t promise to stay up until the end of the meeting.

Joe Andrieu: President of Legendary Requirements, Invited expert, leadership of RWoT, former co-char of CCG. I am interested in greater freedom and more privacy for individuals.

Jonathan Holt: Certified physician, at Stanford. I was involved in standards for a long time. Involved in DID and VCs in the last 3 years as invited expert, and CMO of Consensys Health. I have worked on the CBOR section and CDDL.

Justin Richer: I’m involved in DIDs on behalf of one of my clients. I worked on OpenID Connect and OAuth, UMA, various extensions. Looking at next-generation protocols such as GNAP. I’m here in the DID space because there are some interesting problems and technologies. I keep an eye on how things fit together.

Drummond Reed: One of the co-editors of the specification. Chief Trust Officer at Evernym, also at Sovrin and Trust-over-IP. From Seattle.

Justin Richer: and I had a fantastic egg sandwich on a biscuit this morning, my daughter and I made the buscuits by hand last night

Orie Steele: I will have to drop for a quick call, but I’m Orie, I’m co-editor of the did spec registries, and I work on DIDs and VCs in the context of global supply chains.

Jean-Yves Rossi: Happy to meet again friends from W3C, even if it’s only online. Very happy to come back to the discussion on DIDs. We have invested time in ID management, we are now associated members of FIDO Alliance. We are very happy to be back in this process.

Kaliya Young: My name is Kaliya Young, my handle is “identitywoman”. I am an expert in this field and co-founded the Internet Identity Workshop 15 years ago. One problem in the beginning was how do people own their own identifiers? In this WG I work part-time for a startup called Wireline.

Kristina Yasuda: My name is Kristina, I work at the identity standards team at Microsoft. I am based in Tokyo so usually read notes. I’m excited to join this virtual F2F. It’s nice to see many people from Japan, there are many interesting use cases here.

Leonard Tan: We work on a key management solution. We are mostly known for cryptocurrency wallets. We are interested in how we can implement DIDs.

Duy-Tung Luu: In my company there is a project with OpenID, I am here to learn about DID.

Manu Sporny: I am Manu Sporny, CEO of Digital Bazaar, co-editor in this specification as well as other specs in W3C. I am involved for many of the same reasons as others, to do great good in the world, as long as we get it right. I appreciate everyone being here.

Markus Sabadello: markus_sabadello from Vienna, Danube Tech, co-editor of the spec.

Masa Mashita: We are very keen on the use cases of DIDs in the financial industries.

Michael Jones: I am Mike Jones, I work on identity standards at Microsoft, I have worked on JWT, OAuth, FIDO, etc. I try to keep things simple enough so that developers actually implement them.

Amy Guy: In-browser Zoom and my mic do not get along. I’m Amy Guy, working with Digital Bazaar. Previous history with decentralised social web stuff. Preferred breakfast is last night’s leftovers, especially if spicy.

Shigeru Fujimura: I am observer of this meeting. I am a representative of a Japanese telecommunication company. I am interested in collaboration between DID and Web of Things.

Manu Sporny: On a side note… I feel like we have a massive blind spot wrt. Asia-Pacific interest in the space and probably need to figure out what just happened!?

Shigeya Suzuki: I am an alumni of W3C, I’m associate director of a blockchain lab. I see there is a possibility for DIDs as a global identity standard, I look forward to the discussion.

Daniel Burnett: indeed, Manu. Surprising but pleasant (and important to understand)

Takashi Minamii: From a Japanese credit card company. In W3C I was in Web Payment, now I join as an observer to catch up on DID and VC.

Kazuaki Arai: Sorry for the sound problem. I’m Kazuaki from Japanese payment company called JCB. I’m working on the area of digital identity and security. This is my first time in TPAC, and happy to be here!

Manu Sporny: Agreed – thrilled to have all the APAC folks here.

Tetsuya Kono: It’s my first time to attend the WG, I’m very excited, thank you.

Tomoyaki Mizushima: I am observer at these meeting. I usually join WoT Working Group, so now I decide to join these meetings.

Wang Haiguang: I am a senior researcher in Huawei, my office is in Singapore, I do research on trust, I am a newcomer in this group. I have contributed to IEEE. I have been following the discussions in the DID spec since last year.

Brent Zundel: I am Brent Zundel, I work with Evernym, we have been heavily involved with DIDs and VCs from the beginning. My day job is crypto engineer, I play with math. I am also co-chair of the DID WG.
… Thank you all for being here. Over to my co-chair to walk through steps to CR.

3. steps to CR

Ivan Herman: See slides

Daniel Burnett: Thank you everyone for joining. We are pleasantly surprised by the substantial attendance from Asia.
… Let’s find out if we can find better ways to accommodate you.
… This will be interesting for many of you, maybe challenging. We are in deep deep details.
… The group would like to get to CR, this is a target for most groups when they get close.
… We were hoping to get to it in this meeting, but we still have a number of issues we need to get through.
… It’s very important to understand what it means to get to CR.
… Now it’s appropriate to go over the complete list of requirements.
… The official document is the process document (Process 2020)
… There is often additional information and detail in other places (Pubrules, and W3C Guide).
… Editors used to have to check list of requirements for the spec manually. But a number of years ago W3C folks wrote the automated Pubrules checker which goes through your proposed document.
… brent and I went over those documents and listed all the requirements.
… The two general requirements are on the current slide (14): 1. The document is considered complete and fit for purpose, no further refinement to the text is expected. A CR is well-written, detailed, self-consistent.
… The key point here is: The document is “complete”. It is “ready” to become a Recommendation.
… Of course without implementation experience, the standard is useless. The purpose of the CR phase is to gather implementation experience, which can result in changes to the spec
… The group may have misunderstood something, there may be gaps; this may require another CR.
… We tried to allow time in the schedule for two CRs. This doesn’t mean we want this one to be a “trial”, but the reality is don’t get everything right the first time.
… The first CR publication after approval of a Transition Request is a CR Snapshot.

Jeff Jaffe: I agree that the Process document can be confusing, it’s meant to cover all details. We also have a document “Process for busy people” which 1/4 the size.
… It’s a simplified version of Process 2020.

Daniel Burnett: The process can be tricky when you make significant changes.
… Here is a list of of requirements (showing Slide 15)
… The two most important items have asterisks *

Manu Sporny: It’s important to also mention that many of the people at DIF and the CCG are also in this group on a regular basis.

Daniel Burnett: * Complete Wide Review, this is not very precisely defined, the intent is to ensure that a broad section of potential stakeholders have an opportunity (are encouraged) to review the specification and give feedback.
… This happens in your domain, e.g. we asked the W3C CCG and DIF, who are the groups that are most closely connected to this work.
… Wide Review also includes something called Horizontal review (review by groups within W3C).
… After workin on many specs, I can say that W3C’s Horizontal Review is one of those things that make specifications as good as they are.
… E.g. Accessibility reviews made HTML really good.
… We are expecting someone from the TAG to join us during this F2F.

Jonathan Holt: Wayne, Adrian, and I were working on a security review. If we don’t get any feedback, does it actually mean there are no security and privacy concerns? Given the nature of our document, is there a formal process for doing a security audit of our document. We had a bunch of ethical and moral dilemmas about the use of our document in the futures.

Daniel Burnett: W3C does not require and does not have a process for formal reviews. However, individual groups (either by own initiative, or encouragement) may decide to do that. It depends on the specifics of the specs, and the checks the group and W3C think are needed.
… When the Security and Privacy review document is complete and sent to the groups, we will see where it goes from there.
… With regard to our spec… Those of you who are observing, we have spent substantial time discussing privacy, many of use care deeply about this time.
… We have spent very significant time on privacy. Our next topic is a privacy topic. We will continue spending time on it as needed.

Manu Sporny: Agree with everything. In addition, a number of companies that are building solutions are actively undergoing reviews with regard to privacy. E.g. it’s known that the U.S. DHS Privacy Office is looking into this.
… Privacy and security is deeply of interest of the group. We are getting multiple reviews from multiple angles, even though not everyone in the group may have visibility into this occurring.

Daniel Burnett: * The major item for CR is to complete the work. We need to formally address all issues raised about the document. This doesn’t necessarily mean that all issues must be accepted or agreed with. We need to seriously review and respond to issues.
… This is another thing that makes W3C specifications good. We are not allowed to ignore issues. It’s a requirement that we officially address and mark every issue.
… manu did this work for the VC spec.
… That’s why during this F2F we want to address 25% of the issues, to “unstick” ourselves
… We’re also required to document all new features since the previous publication. There are class 3 and class 4 changes.
… We need to publicly document such changes. It’s optional to document editorial changes.
… We use ECHIDNA to publish. Every time with commit, a new Working Draft is published.
… We will likely join a diff document since the FPWD.
… We also have an opportunity to identity features in the spec as “at-risk”.

Drummond Reed: Does anyone have links to definitions of “class 3” and “class 4” changes?

Dave Longley: drummond, https://www.w3.org/2020/Process-20200915/#correction-classes

Daniel Burnett: If there is lack of sufficient implementation experience, we may have to remove a feature. This is a substantive change that requires a new CR. If we believe there is a risk that a feature gets removed because of that, then those features can be marked “as risk”.
… This is how we can let the world know that this is a substantive change that could occur.
… We have to document what it means to have “sufficient implementation experience”. A common approach is to require two independent implementations.
… We usually try to get the strongest result we can.
… If you cannot get two demonstrate implementation, you can’t call it a “standard”. The goal is that independent parties can read the spec and implement it in an interoperable way.
… We need to specify a deadline for comments, must be at least 28 days after publication.
… It’s a really short time for implementations.
… All this needs to be done before we can request publication.

Jonathan Holt: What’s a “feature”?

Daniel Burnett: This can be defined differently by different groups.
… Most groups define this as something that can be implemented in a way that’s independent of other pieces.
… E.g. You remove it, and the rest of the spec still “works”.
… We do a formal Transition Request for the CR. We must document any formal objections.
… We are expected to document what has changes since the previous step.
… We report on the requirements and how they have been met.
… We report on changes in dependencies with other groups, and information about implementations
… It is common to require a formal review meeting with the Director, to ensure we meet all publication requirements.
… Once we have approval, it’s 1-2 weeks to publication. It’s reasonable to assume a month, since the Transition Request.
… Any questions about this walk-through of the requirements for CR?

Manu Sporny: Process question on CR. I was not aware of the CR Snapshot thing. My expectation is that everything else is still in place. E.g. we need to go through another CR if we have a substantial change.

Daniel Burnett: We were told about this in an Advisory Committee meeting. This process is backwards compatible. If we want we can do the same traditional process. The problem is that this is not what the Process document says.

Brent Zundel: I second what burn said. We were told that we are all on Process 2020 since it’s all backwards compatible. The brief summary is that we can go the CR Draft route (what we anticipated)… If we go the Snapshot route, it enables us to do the IPR step in CR rather than PR (that’s the primary difference).

Ivan Herman: Let’s put IPR aside for a moment, then the difference is only in names. We can update the CR via ECHIDNA except when the changes are relatively significant (judgement call). We can go back to the Director when we want a “well-announced CR to the world”.
… Aside from the the new process, there is also a new IPR policy. At the moment, this WG is still in the old IPR regime. The biggest change is whether we think that we want to have IPR protection on CRs or not.
… The WG has to decide this
… If the IPR in this WG is not a major point of discussion, then this is not relevant to us. If we want IPR protection for CR already, then we need to move to the new IPR policy.

Daniel Burnett: We do have time scheduled specifically for the new IPR in our agenda.

Manu Sporny: burn you had mentioned marking sections as “at-risk”.
… Can we mark those sections as “this section may change”, so that we don’t have to go through CR again if it changes?
… Does this language allow us to not move through CR again if the change is substantive?

Daniel Burnett: My reading is that the process regarding such changes hasn’t changed. I think it’s likely to be okay as long as you are precise enough about the nature of the change.
… I agree with what brent said. We should be able to do this our normal way, unless we want a CR Snapshot for IPR reasons. I don’t think we need to concern ourselves with this right now. We will talk about it. This is largely going to be something the Editors and Chairs will have to do. The process is basically the same.
… We will continue to learn as W3C refines its descriptions

Jonathan Holt: What is a feature… What if that feature is e.g. the Abstract Data Model. If we can’t get agreement on this, will we drop such a core fundamental piece?

Manu Sporny: If that happens, we’re toast :-(
Manu Sporny: or rather, we won’t go into CR if we’re in that position :)

Daniel Burnett: Agree with manu, we won’t go into CR if we’re in that position.
… There is a director, but there isn’t a king. The Working Group decides what counts as a sufficient specification. If there is no Abstract Data Model and nothing to replace it, then there specification is not sufficient and we will keep working on it.
… After the break we will talk about privacy violating properties. (This used to be the “type” topic).
… We will leave this Zoom room open. We will show a slide that will have a link to a breakout room. Please be back here, ready to begin, at the top of the hour.

Drummond Reed: Very very fun!

Daniel Burnett: Thanks everyone, enjoy your break, we will talk in about 34 min

4. Avoiding Privacy-Violating Properties

Ivan Herman: See slides

Drummond Reed: welcome back everyone
… this session was originally two sessions and we decided to devote both to this outstanding privacy related issues
… it may not take us 90 mins, but it may.. we have several important decisions to make
… as we go through this I have specific text, either in the spec now or proposed, I think it would be valuable for us to look at together
… nothing very long
… hopefully we’ll make some decisions
… This session is motivated because we believe after the last few meetings that there is strong consensus that privacy is a paramount consideration for our spec
… and that we are proposing a general principle that we can apply throughout which is that DID method specifications and DID controllers that control what goes into a DID doc should not use privacy violating properties in publicly available DID docs
… cook on that for a second.
… The proposed structure for this session is to discuss this overall privacy stance
… and then if we have general agreement on that, seek consensus on proposed wording of a PR that amy submitted that would capture that clearly
… and then decide on the action items for completing that
… and getting it in for CR
… That’s the assignment for this section. That’s a very important decision
… will close the discussion around the type property because we’re now saying this involves any property in this area
… Since we’re on the topic, let’s talk about the other open privacy issues, there are several
… if there’s time we’ll look at wording we have in the spec or proposed wording and see if we can decide on that
… if we get all that done in 90 mins I’ll be very happy
… That’s how we propose to move forward

4.1. Privacy-Violating Properties

Ivan Herman: See slides

Drummond Reed: Now part one: privacy violating properties
… let’s be specific about what we propose this means for the open issue around the proposed type property
… First it means we would not specify a type property in did core
… or for that matter any other property that could be a privacy violating property
… the second point we discussed on our last wg call, DID docs use an open world data model
… which means a DID method spec or a DID controller that controls what goes into the DID doc
… they can add other properties as they desire
… this motivated us to say the issue we’re addressing is larger than just the type property
… it applies to any privacy violating property
… that’s a strong term, “privacy violating”
… we’re using that to call out that properties that might seem innocent can still turn into privacy violations if used in certain ways, and thus are best avoided
… so the last point is that amy has proposed language in PR #444
… we’ll see on the next slide, it includes some enhancements by brent and wordsmithing I added on the next slide, not exactly what’s in that PR
… this is what i suggest we review

Adrian Gropper: a very quick question - in the context of what we’re doing here, are we assuming governments for example or other verifiers will simply keep or publish a white list of acceptable did methods
… the fact that the open world model will be dealt with in terms of privacy and accessibility, in this way, want to get a sense from the group whether that’s our assumption going forward?

Drummond Reed: that’s a very interesting question
… if I may, i want others to volunteer their answers, I’d like to break mine into two parts
… one.. will governments publish whitelists of acceptable DID methods?
… i believe they either will or they will point to industry defined or consortia defined lists
… there will be a distinction.. those allow lists may not just be about privacy, but about security, reliability considerations
… whatever might determine DID methods are okay
… part two is that doesn’t by itself constrain a DID controller from adding properties to a DID doc

Dave Longley: yes, consumers of DIDs will absolutely make choices around which DID methods they accept

Drummond Reed: depending on.. a DID method may not allow that but if a DID method does allow that you have a second consideration of what a DID controller would do not constrained by the DID method

Dave Longley: In short we should expect consumers of DIDs to make choices around which DID methods they accept, that’s really the only way it can work

Drummond Reed: agreed
… I’ll pause for 60 seconds [so you can read this]
… this is proposed text in a PR from amy, I was not clear where… was this proposed for the privacy considerations section?

Amy Guy: yes privacy considerations section

Jonathan Holt: to raise the push back as far as a allow/deny list for DID methods… I think there are DID methods out there such as IPID which don’t rely on a specific verifiable data registry
… all about how you implement that representation of the DID doc, not necessarily the underlying VDR
… I’d be careful about choice of words
… this goes back to the early days of the internet… [he] described this mentality of people thought they could own parts of the internet
… here theres’ going to be a grey area of what is a DID method, what is a particular VDR of a blockchain technology
… to delineate that, it’s too early

Juan Caballero: For the purposes of the record, the “he” describing the early days of the internet in Jonathon Holt’s comment is Robert Khan: https://en.wikipedia.org/wiki/Bob_Kahn

Ivan Herman: See Proposal for the privacy consideration section.

Drummond Reed: are there any questions about what this is saying or clarifications anyone would need?

Daniel Burnett: comment that would be invalidated… in the last sentence I think you mean SHOULD only be used for expressing cryptographic material.. not just should
… but amy made the comment that this is a non normative section so it’s quesitonable whether the SHOULD is appropriate

Drummond Reed: my reaction is we should add only and the should can become a lowercase should

Dave Longley: “To minimize these risks, all properties in a DID document ought to only be for expressing cryptographic material, endpoints, or verification methods related to using the DID.”

Manu Sporny: along those lines, “is expected to be”
… overall great text
… I think it captures the discussion we’ve been having for months fairly well

Daniel Burnett: yes, +1 from me for the text as well

Manu Sporny: I did read ahead a bit and there are multiple times that normative language is in this guidence, but tha’ts the only thing, that’s easy we can change it

Dave Longley: +1 to the text

Manu Sporny: assume the shoulds and musts are going to go away but the guidence will be there
… this is the expectation of what implementers will do

Dmitri Zagidulin: I want to add that, I like the language proposed, want to highlight the cryptographic material, services, verification methods part - and claim that service endpoints can and will fingerprint
… and identify the DID subject

Manu Sporny: some service endpoints

Dmitri Zagidulin: so we have a DID, it has a single service endpoint that says smartfridgegateway over here
… fingerprints it as an iot device and not a person

Dave Longley: yes, service endpoints are tricky and could identify the type of subject/be intrinsically privacy violating – as we have been discussing in numerous places

Dmitri Zagidulin: and there will be certain service endpoints that are clearly for people
… the service endpoints discussion is kind of bound to this

Dave Longley: whereas cryptographic material is necessarily random

Drummond Reed: we will get to that

Brent Zundel: +1 to additional language for services

Drummond Reed: there is another privacy considerations subsection we’ll get to that talks about that
… when we’re done with this whole discsusion we’ll probably end up with input that we’ll use to modify or add to several privacy sections

Adrian Gropper: @Dmitri that’s why mediaitors will exist

Dmitri Zagidulin: @agropper - I agree. in which case, we may want to call out mediators explicitly, in that language

Adrian Gropper: @dmitriz That’s why I think some specific service endpoints should be discussed in the core spec in some way

Joe Andrieu: I love the work, thank you drummond and chairs for putting this together
… I want to second what dmitri said
… do we have any further definition planned for what it means to be a public DID document?
… public and private are not really absolutes

Drummond Reed: great question
… I don’t know as we have defined it explicitly, should we do that?

Joe Andrieu: just note it’ll be tricky and we should put some time in it

Dave Longley: could base a definition on a lack/presence of access control

Joe Andrieu: we should put a stake in the ground

Drummond Reed: I agree to help with that

Brent Zundel: I recall during the service endpoint conversations, we had a resolution for describing the span of possible privacy.. there’s a span of possible privacy values from public to private.. we had already agreed that language should go in

Brent Zundel: pertinent resolutions here: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-09-24-did-topic

Brent Zundel: Resolution #1: The ability for a controller to optionally state at least one service endpoint in the DID Document increases their control and agency Resolution #2: Add concrete examples to the Privacy Considerations section to demonstrate how service endpoints might account for varying levels of privacy requirements. Resolution #3: Add privacy guidance that establishes that there is a privacy spectrum and publication strategies along that privacy spec[CUT]

Manu Sporny: looking ahead to make sure this doesn’t block us, we should have general agreement that defining what public and private is is an editorial rather than normative issues and shouldn’t hold things up
… does anyone disagree with that?
… if this is the only thing we need to define and we say it’s editorial then we have a clean path forward for this section

Drummond Reed: wonderful

Dmitri Zagidulin: @manu - what does that mean for this slide / this 10.x Avoid … Properties section?

Drummond Reed: anyone else have any questions or concerns around this text?

Manu Sporny: Note - no one objectioned that public/private definition is editorial.

Drummond Reed: the action item is… for amy to update the PR , there were some besides brent’s some wording suggestions we may want after this session to look at together
… I’ll help
… then that PR iwll be ready
… that’s all I have, anything else?

Jonathan Holt: we can pat ourselves on the back and say we’ve added strong language in the non-normative section of the DID core spec saying you shouldn’t be adding this information into the DId document but that doesn’t stop people from doing
… what’s the worst case scenario? have we thought through potential harm of people using this information or inferring the type of thing?

Ivan Herman: my comment is purely administrative, this is the result of a month long discussion so I think we should take a formal resolution on record that this is the way we go

Brent Zundel: thanks ivan I agree

Ivan Herman: see resolution slide.

Adrian Gropper: I want to build on jonathan’s most recent comment
… my comment about allowing listing by government verifiers for example
… can we, might we, say something about the fact that a method could enforce certain things that an individual controller might want to do
… is that, because jonathan and others raised the issue that wide world model, the method may not be in control of what individual controllers add to a DID doc

Jonathan Holt: +1 thank you!

Adrian Gropper: so again.. I’m not so well versed on the mechanics of how this works, but it seems jonathan’s point could be addressed as part of this action item, this suggestion in DID core

Joe Andrieu: why not add this as a normative section?

Ivan Herman: how do we test?

Manu Sporny: normative sections need to be testable, we’d have to express it in code and I believe we don’t think we can express this in code

Joe Andrieu: good answer

Adrian Gropper: +1

Drummond Reed: +1

Proposed resolution: Adopt the language on slide 23 to add a section on “Avoiding Privacy-Violating Properties in Public DID Documents” to DID Core. See slide (Manu Sporny)

Ivan Herman: +1

Drummond Reed: +1

Manu Sporny: +1

Dmitri Zagidulin: +1 (although I think Slide 23 is not strong enough about warning about service endpoints)

Dave Longley: +1

Amy Guy: +1

Shigeya Suzuki: +1

Daniel Burnett: +1

Markus Sabadello: +1

Brent Zundel: +1

Dave Longley: (agree with dmitri)

Jean-Yves Rossi: +1

Jonathan Holt: 0, don’t think it hits at the potential harm

Joe Andrieu: +1 (w/ service endpoint and public doc desiridata)

Kaliya Young: +1

Drummond Reed: we’re going to add other text about service endpoints. In favour of making sure the service endpoint point is made very clearly

Dmitri Zagidulin: @jonathan_holt - I agree that it doesn’t hit at the potential harm. It’s better than the current state, though.

Brent Zundel: if anyone has a -1 now’s the time to get it in

Juan Caballero: +1 (curious to hear more about this public doc desiridata)

Brent Zundel: (I also agree with Dmitri, but we already have resolutions that I think address service endpoints)

Resolution #1: Adopt the language on slide 23 to add a section on “Avoiding Privacy-Violating Properties in Public DID Documents” to DID Core. See slide

Brent Zundel: reminder when proposals are put forward only WG participants should be responding

Jonathan Holt: about how to implement this in the question I have is if it is testable
… that this is absent from the DID doc
… if there’s a way of testing the DID doc to check type is not present. Does that change things? Could that be normative?

Dave Longley: something else related to this, covered a bit in the spec, we talk about how DID methods can palce additional restrictions on what can be present in a DID doc, what the DID method would accept
… we could mention that DID methods are able to restrict properties in DID docs to support only verification methods so that no intrinsically personal data would be expressed

Markus Sabadello: +1 to dlongley

Dave Longley: so DID consumers could make a choice about methods they prefer for a use case

Adrian Gropper: @jonathan_holt that would require a way to examine how a controller specifies a service endpoint

Manu Sporny: about the testable question - we’re not saying it’s completely and utterly illegal to use type, but that it’s dangerous and you should be careful, there are some use cases that are okay
… if the test suite threw an error for the existence of type we would get a number of objections
… it’s a should not, not a must not
… I think that’s what our consensus is, everyone agrees it’s dangerous
… and we can’t really talk about other properties we don’t know about yet, specifically only type

Drummond Reed: +1 to Manu’s points

Ivan Herman: there is what manu said, but beyond that, it’s not only the type property. it’s on property x which in certain contexts may be problematic
… so we can’t create a test without having the whole context of the specific property

Adrian Gropper: +1 @ivan

Brent Zundel: we could test for a type property but then it’s possible someone might use humanType or… there are we would never be able to normatively reject every possible property that could be used to identify people or types of people or stuff like that
… for that reason it’s not quite testable

Jonathan Holt: in the verifiable credentials WG we talked about this idea of a policy with the credential
… we might want to explore this
… yes it may be present but then it allows you to have a rubric of assessing the did document for presence or absence
… in my policy it says you must be a type and that type has to be human. In other situations i explicitly do not want to kno wthe type
… satoshi nakomoto may be a person or a nation state, that was the power that enabled bitcoin blockchain to be successful..

Drummond Reed: I declare us done with part 1
… good discussion, thank you everyone

4.2. Other Privacy Issues

Ivan Herman: See slides

Drummond Reed: part two is other privacy issues
… I read all of the text in privacy considerations section
… I believe these are the three others we need to talk about
… I have slides prepared for discussions and wording on at least two of the three
… I want to stop and ask is there anyone on the WG who clearly knows of another privacy related issue that we haven’t covered that’s not on this list we should talk about in the next 54 minutes?

Jonathan Holt: maybe under the PII… biometrics is still in the did spec as a verification method. maybe sufficient to place it in its own category

Adrian Gropper: Notarization might be a separate category

Drummond Reed: adding it..

Adrian Gropper: I have raised the issue of notarisation, namely the [??] principle, that some DIDs will want to have some kind of backdoor or a way of introducing a court order
… or moving from an anonymous identifier or pseudonymous identifier
… that’s a first order privacy issue

Drummond Reed: let’s see if we can get to these
… good to have a list. Any others?

Jonathan Holt: to build off, we had fleshed out this idea of a publicly discoverable DID doc and what data allows that to be identifiable
… the correlation risk of those verifiable credentails
… the examples I’ve used before is VCs for vaccinations
… if a doctor signs my vaccination no big deal, but I have to present it to my kid’s kindergarten, but who it was signed by you can see I was stationed at a particular airforce base, that has the potential for correlation in a publicly discoverable DID doc

Drummond Reed: what i have prepared is discussions around these first three, very important to have
… let’s see if we can get through those
… the first one is PII in DID docs
… we already have text: see slide.
… I reviewed this text, is it still accurate and does it need to be revised based on what we’re discussing?
… I highlighted one thing we will be discussion in the next issue
… I’ll pause here for a minute. This is copied text out of section 10.1 of Privacy Considerations
… Comments on the highlighted final sentence, please hold off on those
… [GDPR related]

Manu Sporny: +1, language in 10.1 is good, still relevant.

Drummond Reed: this is the guidance that exists currently about service endpoints and possible fingerprinting
… what is the feedback about the adequacy of this text
… does it need revisions?

Kristina Yasuda: having this text would not guarantee European institutions would agree ‘no personal data is written to an immutable distributed ledger’

Dmitri Zagidulin: I wanted to bring up the point of service endpoint types
… I think the current language warns about URLs but not the types which are even more likely to type the subject as a human etc

Drummond Reed: taking notes
… is that a PR you’re willing to help with text on?

Dmitri Zagidulin: depends on the outcome of this discussion and service endpoints
… maybe the PR should be abandoning service endpoints, or requiring only one anonymous one. I’d want to help but what specifically depends on the conversation

Drummond Reed: I believe there was a separate resolution already taken about service endpoints

Ivan Herman: possibly minor… the slide says “service endpoints under the control of the DID subject” - should it be subject or controller?

Drummond Reed: I think it should be the DID controller

Joe Andrieu: good catch by ivan
… That’s also true for the second DID subject should be controller
… you could have a DID method where not all DIDs or all DID documents are publicly available, but it’s still critical that those that are contain no personal data
… It’s a common pattern now to implement off-chain DIDs that can somehow migrate on chain
… would like to clear up that language to apply to those cases

Drummond Reed: that might be a pattern we want to separately call out in privacy considerations

Joe Andrieu: all for that

Drummond Reed: text we should update on this and we should add a separate thing about migration of DID docs

Joe Andrieu: sure

Adrian Gropper: this was already mentioned in passing.. we need to do the service endpoints at least how we’re going to deal normatively described service endpoints before we use the term service endpoints in this way
… for instance, a different term for mediators was used, I would suggest we need to do the service endpoints first and then we can come back to the wording of this

Jean-Yves Rossi: I’d like to underline the meaning and implications of the words ‘personal data’ under the interpretation of the European [??] justice which is important in the EU
… any data that can be linked with somebody is personal data
… the number on your plastic payment card is personal
… any payment you make with this will be considered as personal data

Joe Andrieu: +1 to shift from “PII” to “personal data”

Jean-Yves Rossi: even if this number can be only linked with your name through the bank who is under constraints of provisional secret

Drummond Reed: Note: there is a definition on the next slide

Jean-Yves Rossi: so if there is any technical mean to make a link between somebody and some data it is personal data

Adrian Gropper: +1 to shift to personal data

Jean-Yves Rossi: so I think that reading the slide it’s not really relevant to think about getting rid of personal data because everything in the DID will be personal data
… I think that what will be the most relevant is not having or not personal data
… everything is personal data
… but giving control to the entity to be able to check data and to ask for data to be deleted or erased and being ensured that the purpose with which data is managed is accurate
… is proportional to the goal and so on

Kristina Yasuda: +1 to jyrossi’s warning

Jean-Yves Rossi: I want to give this warning about the idea that we can get rid of GDPR constraints just blurring the name of the people behind
… if there is any technical way to make a link between data and an entity then it’s personal data under GDPR interpretation

Brent Zundel: +1 to jyrossi

Drummond Reed: that’s an important point and one we are about to go deeply into
… I have the complete definition of personal data here
… I’d like to hold off directly talking about that, we have a very specific issue to talk about
… This larger point, the definition of personal data
… from the GDPR
… w3c specs are global, they’re not written for any specific jurisdiction, but they need to take into account the requirements and regulations for jurisdictions all over the world
… GDPR is one of th elading data protection regulations in the world, applies to all European citizens
… it is a very broad definition of personal data
… governance work that I’ve been involved with we spent a year working on issues related to DIDs and this definition of personal data

Adrian Gropper: Any DID can be anonymous by default as long as a notary or mediator is used when pseudonimity is needed. Is this so?

Drummond Reed: The larger question is it can be very difficult to, if our definition is to say ah no personal data in a did document, does that logically take us to th epoint of saying individuals cannot have publicly available DID documents? Must there be some requirement that if it’s public and for an individual they must be the DID controller?
… this is before we even get into immutable ledgers

Adrian Gropper: is it testable to look at a DID as being presumably anonymous? in the same way that a bitcoin address is anonymous?

Juan Caballero: pseudonymous?

Adrian Gropper: as long as there is nothing in the DID document other than mention of a mediator or a notary both of which would then need to be used in order to correlate or turn it into a pseudonymous or other identifier
… is that a true statement and a reasonable way to deal with the GDPR issue?

Jean-Yves Rossi: if you have secret files by some secret nation state actor and it would comply with what you require because nobody but them has access to such data
… but in the EU it is under control of GDPR and you have a right ot get information about this
… you have a right that no decision about you could be decided through for instance automatic treatment without allowing you to get access to such data
… it’s not only if you make things anonymous to public that you comply with GDPR
… GPDR is about data management
… you have to manage data, personal data, and the meaning of personal data is as large as possible
… any time you can make a link between data and somebody it is personal data
… GDPR is about personal data management and control
… it’s not about making personal data deeply not personal

Kristina Yasuda: +1 to user control rather than defining what is personal data and what is not - if DID controller is same with DID subject and chooses to put PII into a publicly available DID that is not a privacy violation I assume?

Jean-Yves Rossi: pseudonymity is not a way to get rid of compliance with GDPR

Drummond Reed: heard from multiple attorneys, the fact that a DID is pseudonymous or the DID doc doesn’t contain. if it contains a public key associated with the individual it is personal data under GDPR

Markus Sabadello: two aspects that are sometimes mentioned regarding GDPR and privacy
… one aspect is encrypted data in DID docs, we have a section about that in the core spec
… but it is a warning saying don’t do that because encryption is not safe in the long term
… especially when we want persistence and immutability, not advised to have encrypted data
… the second aspect is that of authorization in DID resolution comes up rarely but sometimes
… when you resolve a DId to a DID document, not aware of anyone implementing that
… very complex topic

Brent Zundel: with that definition, isn’t any DID Document for a human DID Subject PII, regardless of its properties?

Kaliya Young: so how do people actually do something in digital space as independent actors. So much of GDPR and privacy law is coming from a frame where the individual has no agency in anything, because it the OECD privacy principles arose originally out of US context in the early 1970’s when people were being subscribed to catalogues with out their awareness or consent - none of it was written with the idea people would have computers and agency like[CUT]

Drummond Reed: before we go onto the larger deeper issue of GDPR, any other comments or feedback or key thoughts that folks have about the text here we currently have?

Brent Zundel: [chair hat off] based on the conversation we’ve just had it seems as though at least according to GDPR that any DID with a human DID subject is PII
… any DID doc for a human DID subject is PII
… it’s not just DID method specs written for public VDRs
… it’s all DID docs with human subjects contain personal data
… and therefore shouldn’t be written to VDRs or immutable storage

Ivan Herman: See slide for PII.

Drummond Reed: that last piece about writing them to immutable data storage that is the highlighted issue at the end
… I don’t think it’s an issue, for a person and the information in there like public key being personal, as long as it’s treated as personal data under GDPR or PII under other data protection regulations, the knot is in the written to immutable ledger

Dave Longley: not to be super pedantic but if you can’t identify a person directly or indirectly it’s not personal data. Doesn’t necessarily make for useful DID docs
… but the ‘therefore’ in brent’s sentence does not necessarily apply
… just because it MAY be personal data that it cannot be written to a ledger, that’s an unsolved legal question
… we don’t know what the consequences of that are

Drummond Reed: It is true that if the DID and DID document cannot be associated with a natural person.

Drummond Reed: the point being made is if the DID and DID document cannot be associated with a natural person then your’e correct it does not meet the definition of personal data under GDPR
… there are ways, cryptographic and otherwise, that you could have a person with a DID doc that is maintaining that separation such that it’s not technically feasible, there is a test for how hard you have to work, if it’s reasonably hard then it’s considered not associated and therefore not personal data

Juan Caballero: but it’s like encryption — just because someone can’t be correlated today… doesn’t mean you aren’t liable if it becomes retroactively possible later…

Jonathan Holt: reading the slide, personal data etc an identification number etc etc cultural or identity of a natural person… using type associates that identifier to a natural person and that’s an issue of GDPR

Adrian Gropper: I’d like to propose potential solution - DID documents which are linked to public ledgers need to be dealt with the same way we deal with bitcoin or ethereum as public ledgers
… it is out of scope for us to make an implication as to what is associated with a particular key address in bitcoin or a particular DID when that DID is linked to a public ledger
… and ask therefore whether being that strict, because you can’t be any stricter, it’s a very strict interpretation of self sovereign identity relative to the way bitcoin is self sovereign, we all know that correlation systems exist and are being used by law enforcement to decode bitcoin addresses into personal information
… I propose could we adopt this linkeage or this analogy to solve the GDPR problem?
… and others

Drummond Reed: great question
… on that note let’s move to that specific problem
… what you heard from adrian is a potential solution, there are a couple of others
… the final sentence really triggers, when I read it we have to discuss this, because of this question of if the DId and DID doc is associated with a natural person and it’s written to an immutable ledger then there is a very well known tension
… there are papers about this issue
… what do you do about the right of erasure?
… can that actually be affected
… if that’s the heart of that, I want to make sure we have a good discussion of the different options

Manu Sporny: Looking at the options on slide 32 – -1 for #1, -1 for #2, +1 to #3.

Drummond Reed: we should capture what adrian was suggestion to resolve this

Joe Andrieu: I think the term DID subject itself is part of the problem here
… I don’t know if we can fix it
… I’ve voiced this perspective to several members of our community
… what DIDs really do is provide proof of control, a way to independently verify that someone has access to a secret
… it may not be persistent with any given DID subject
… the illusion we have painted that a DID refers to someone is part of the problem

Kaliya Young: +1

Joe Andrieu: although that’s useful in a given context to have a consistent name

Brent Zundel: +1

Joe Andrieu: doesn’t mean the name is the same person in different context
… we have a fallacy around the DID subject I want to poke some holes at

Drummond Reed: it is the next topic and it is specifically because it could be a potential solution. It’s a whole topic unto itself
… it’s important.. in order for that DID to be disassociated from that individual… they would need to be the DID controller.. or as long as they could affect the right of erasure.. that would be one option

Dave Longley: there are also exceptions to that around public interest for example
… the ability to have a DID that cannot be taken away from you could be in the public interest

Drummond Reed: super good point

Ivan Herman: that’s something GDPR allows?

Dave Longley: yes

Drummond Reed: there are exceptions to the different rights
… there’s a paper that discusses exceptions that could be argued apply to the Sovrin blockchain that is immutable

Drummond Reed: Link to the Sovrin Foundation white paper on the question of DIDs and immutable ledgers: https://sovrin.org/data-protection/

Dave Longley: +1 to Joe as well

Manu Sporny: very strong +1 to what Joe said
… taking a step back a bit and looking at this holisticly
… the law takes time to catch up to what we’re doing right now
… GDPR was written in a world that did not necessarily conceive the tech that we’re working on

Dave Longley: +1 to manu — law has to catch up to this technology

Manu Sporny: while there have been each one of us has legal council that have been looking at this in fundamentally the narrative back from them is look there has been no definitive ruling on any of this stuff
… it’s uncharted territory, we can guess but not say for sure
… what we say in the spec will have an effect on future interpretations
… that is why what Joe is saying is very important

Dave Longley: it wasn’t written to address this tech — this tech is intended to help with self-sovereignty in a way that wasn’t conceived of in the law (which is also intended to help with self-sovereignty)

Manu Sporny: there have been this misunderstanding with the spec that once you create a DID it is always bound to the same individual over the lifetime of that individual
… it’s simply not true
… Just like you can say ‘mom’ it does not mean the same thing in different contexts
… a DID can be handed off between different individuals, private corp to public corp
… you can’t say definitively that a DID applies to an individual
… it maybe true at a point in time
… but that can change very quickly
… we should say something about this in the DId spec, that we did understand the ramifications of GDPR and we did design the spec to be as privacy protecting as possible
… and took GDPR into full account
… and make the point that these things are not identifying a single individual, they can be transient things and can be used in a way that fundamentally supports GDPR
… the whole reason GDPR is out there is to give people more control over their data
… we’re building technologies to do that
… it would be terrible for GPDR to be used to prevent one of the fundamental goals of GDPR, to have more control over their data

Juan Caballero: Fun fact: by some measures, GDPR turns 10 years old on wednesday https://ofthewedge.com/2020/11/01/the-gdpr-was-the-most-lobbied-law-in-eu-history-dsa-hold-my-beer/

Drummond Reed: persistence is something we’re discussing, there’s a specific proposal I’d love to get feedback on
… I agree with manu, we can and should craft a specific subsection of the privacy considerations section addressing this issue
… I’d be happy to get experts that I’ve worked with on this to help us craft that text
… I believe manu is correct, we will actually be able to influence regulatory decisions about this
… the one point I want to make that’s made in that paper is that if the DID subject is an individual and they’re the DID controller they effectively by control of the keys for the DID doc have an effective right of erasure
… they can essentially terminate the DID doc and in doing so declare the dissociation and that is an effective right of erasure
… that combined with the fact that it supports the core goals of GDPR is a very powerful stance

Adrian Gropper: I want to disagree with drummond there. if a DID doc is publicly indexed by crawlers of the internet the fact that you as a controller can delete it makes no difference at all. it has already been crawled
… and is now out of your control
… I don’t think what drummond just said is useful, regardless of what the lawyers say

Joe Andrieu: it may help if we had stronger language specifically around the pattern with VCs. Proof of control is the only way you can identify that the subject is part of the interaction

Manu Sporny: That’s an excellent point as well Joe – we should make that point too

Joe Andrieu: removing that proof of control by changing your keys is effectively a redaction, including on public ledgers

Dave Longley: +1

Drummond Reed: In my head i had associated DIDs as these are effectively URNs
… a persistence identifier that is assigned once and never changes ever
… I had put DIDs in that bucket
… and Joe pointed out the very nature and design of DIDs is the DID controller controls what the DID identifies and therefore in practice a DID is only as persistence as a controller chooses
… and the underlying DID method is able to support
… so joe changed my mind
… I found the language about persistence, in section 3.1.
… it is a note
… please take a second to read it. I’m going to propose completely different text, except for the last sentence

Manu Sporny: +1 to rewording persistence in this way

Brent Zundel: +1 to revising the language around persistence.

Manu Sporny: Yep, text on slide 33 is wrong :)

Dave Longley: -1 to the text on that slide, happy to see new language

Manu Sporny: it’s not meant to be bound exclusively and permanently to on and only one subject

Manu Sporny: it can be repurposed

Daniel Burnett: Agree Manu

Daniel Burnett: Bad Drummond

Drummond Reed: if i was responsible for this text it was probably 3 years ago
… now let’s look at new language (see slide on new proposed language on persistence)

Manu Sporny: We should remove the normative stuff — not testable.
Manu Sporny: but other than that, great text!

Joe Andrieu: one language that came out of conversations with christopher allen and trying to disect what we mean by this
… we came up with the phrase “cant’ be taken away”
… I don’t know if it’s the right language, but the intent

Dave Longley: +1 that’s the original intent “can’t be taken away” (and the very very original language)

Joe Andrieu: less important that the DID is persistent, but that your provider can’t take it away

Brent Zundel: +1 to Joe

Joe Andrieu: which in some context feels like persistence

Juan Caballero: If a controller deactivates a DID, can the ledger still be queried historically? Doesn’t that kind of undercut the effectiveness of that erasure?

Joe Andrieu: We need to figure out the name of the rubric
… because the current editors don’t call it that and we’ve moved beyond decentralisation, so that’s another conversation

Daniel Burnett: “Control cannot be taken away from the DID controller without the controller’s permission’

Drummond Reed: I wanted to get something that captures the key points
… the technical accuracy that it is the DID controller
… I love the point of can’t be taken away, like that phrase
… DID architecture designed to support the ability for it to be permanently bound, the DID controller.. we can make that language closer to can’t be taken away or add language

Brent Zundel: +1 to “can’t be taken away” over “permanently bound”

Drummond Reed: I’d love to get a simple proposal out of this that this language is approximately, that we agree there should be a PR to revise the language
… along these lines

Adrian Gropper: +1 to this new language

Joe Andrieu: I’m not a fan of the term persistence. There’ something here about identifiers being specific to context
… with techniques such as VCs you can accumulate contexts with which you can convince yourself there’s a consistent set of properties
… it’s that contextuality I’m not seeing here

Brent Zundel: anyone have recommendations for changes to manu’s proposal?

Drummond Reed: +1

Proposed resolution: Adopt the language on slide 34 as a starting point for a PR that establishes new language around Persistence. See slide (Manu Sporny)

Adrian Gropper: +1

Ivan Herman: +1

Drummond Reed: 1

Shigeya Suzuki: +1

Daniel Burnett: +1

Joe Andrieu: +1

Brent Zundel: +1

Manu Sporny: +1

Dave Longley: +1

Dmitri Zagidulin: +1

Jean-Yves Rossi: +1

Amy Guy: +1

Jonathan Holt: 0

Markus Sabadello: +1

Juan Caballero: *1

Juan Caballero: != 1

Brent Zundel: not seeing any objections

Resolution #2: Adopt the language on slide 34 as a starting point for a PR that establishes new language around Persistence. See slide

Drummond Reed: we got as far as I could have hoped to with these issues
… I’ve been noting action items
… I’d say the important part of completing our work around privacy, besides the PRs, is then attending to the other ones that got brought up
… around biometrics, notarization
… we’ll take that as action items to keep working on those
… thanks, we made a lot of progress here

Manu Sporny: +1, yes, thank you Drummond - very helpful!

Daniel Burnett: Thank you, thank you

Brent Zundel: I think we do have a lot of consensus in the group around privacy, we all care deeply about it
… this was a great first meeting
… especially those of you up so late!
… we will be meeting again tomorrow, two hours later than the start time was today
… noon eastern time
… see you tomorrow!

5. Resolutions