DID WG Topic Call on Herd Privacy and the Appendix — Minutes

Date: 2021-01-14

Attendees

Present: Amy Guy, Ivan Herman, Manu Sporny, Dave Longley, Markus Sabadello, Christopher Allen, Joe Andrieu, Ted Thibodeau Jr., Orie Steele, Adrian Gropper, Kaliya Young, Daniel Hardman, Grant Noble, Jonathan Holt, Daniel Burnett, Drummond Reed, Daniel Buchner

Regrets: Brent Zundel

Guests:

Chair: Ivan Herman

Scribe(s): Amy Guy

1. Herd Privacy

See github issue #539.

Ivan Herman: See Drummond’s slides.

Manu Sporny: we can review joe’s position, then discuss a fallback consensus position.

Christopher Allen: I thought i can recap history or talk about pre-DIDs while we’re waiting for Drummond.
… this is not just a DID thing.
… this is an ongoing problem that the entire internet design community is dealing with.

Daniel Hardman: I’m aware of the herd privacy topic and I’m pretty sure I’d say anything drummond would say.

Joe Andrieu: I think herd privacy is vital to the DID Core spec, and we need to update it to address herd privacy while ensuring that DID method implementers are free to innovate.
… herd privacy means you should not be able to discern the nature of the subject by comparing did core features of dids, did urls and did documents.
… Herd privacy is vital to the DID Core specification. DID Core shall be updated to better address herd privacy while attempting to ensure DID Method implementers are free to innovate. Herd privacy means that one should not be able to discern the nature of the Subject by comparing the DID Core features of DIDs, DID-URLs, or DID Documents. DID Core features that impact herd privacy MUST justify their functionality through exceptional ben[CUT].

Dave Longley: +1 generally to Joe.

Daniel Hardman: the first part feels comfortable, the second part needs some nuance.
… herd privacy ought to mean you can’t tell anything about the DID subject.
… I think it would be fine to know a particular DID relates to a document or a iot device.
… herd privacy as it relates to things as it relates to things other than individuals is a little bit iffy.
… I’m not convinced that it’s vital for nonhumans.

Orie Steele: to note two points related the concept of herd privacy being fundamental.
… I’m aware of an intention to use the DID identifier idchar string to identify software packages as a distinct subset from people.
… this is work that microsoft folks are interested in, a registry for different types of identifiers.
… the first use case they’ve talked about is software packages as distinct from did subjects that might be users.
… microsoft is talking about that, they are already working on things related to that.
… you should know about that use case.
… It’d be awesome to hear from the about their intention for registries of types of dids for ion.
… they’ve thought about this a good amount.
… I’ve argued a lot about this topic.
… One thing about registries we should be aware of is you don’t get to control how the registry is used in the future.
… especially in social media, culture changes over time.
… eg. master for the main branch in git was acceptable before, is no longer acceptable now.
… we should be capable about making unenforceable statements in did core.
… we are not in control of the future or english language.

Dave Longley: I think it’s important to note is that any DID Document that contains “type” information, etc. – it does not contribute to “the herd” – because it can be separated from it..

Manu Sporny: I feel like I understand mostly where people are coming from.
… What changes to the spec are we talking about?.
… the current thing under consideration is suggesting that we move resource dereferencing out of the spec into a resolver parameter.
… I think Joe is saying let’s take resource=true out of the core spec and if people want that they can register it in the registries and the way to do it is through a DID resolver parameter of some kind.
… that’s one concrete spec change I can think of.
… everything else feels non-normative.
… any other changes contemplating suggesting anyone?

Christopher Allen: I’m coming from a history of great intentions that result in regrets and there’s a lot of people in ietf that have turned around and said we need to be radical.
… we didn’t do it good enough.
… and consider myself in that category.
… a thing I love about DIDs is that it really truly abstracted a part of the bootstrap.
… given I need an identifier that isn’t controlled by others, but I need to be able to prove control.
… anything beyond that ought to be a different level.
… yes I might ask the resolver to get me more information, it ought to be going to the endpoint and doing a protocol but that’s a different layer of the stack than DID is.
… DID fundamentally is about being able to prove control over an identifier.
… I’m more radical, I’d probably rip more out of DID core.
… but i really am trying to protect people.
… I’m doing DID onion and you should know with did onion whether there’s a person behind it, securing git archives and stuff and things that aren’t people, but when I’m done you won’t know at the DID level what’s what or who’s what or if it is a who.
… you’ll just be able to know that the identifier has a controller.
… and everything else will be another layer.

Adrian Gropper: to daniel’s point, and I think drummond’s, I don’t believe that DIDs for things and documents where those things and documents are associated with people are not part of herd privacy.
… I disagree with what I think I heard drummond and daniel say.
… And to the point just made, I would put everything behind service endpoints.
… I would see that DID core should not introduce any properties or parameters other than those involved in controlling verification, and everything else would have to go behind a service endpoint of oen kind or another.

Drummond Reed: I have never said that DIDs for certain types of things do not need herd privacy..

Joe Andrieu: one of the reasons for this call is that I’m fed up of arguing with drummond and having concern for the privacy of individuals dismissed because of features for things that aren’t individuals.
… it’s premature to itemise all of the things in the spec that need adjustment. resource=true is one of them. It’s on me to go through and do a deep dive.
… but that’s not worth doing if the group doesn’t support a shared definition of herd privacy.

Drummond Reed: I am upset with Joe using the term that I’ve been dismissing privacy.
… I do not want this to be about this reaction.
… I have a very straightforward position on this issue which I’ve shared.

Manu Sporny: Agree — we should stay away from tying people to positions. And discuss the ideas on their own..

Drummond Reed: which is I’m a huge supporter of herd privacy for the context in which it’s needed.
… I know the contention on the table is that it’s needed for all DIDs.
… and I want to point out that that is not true.
… if that were true we would have to agree that there’s only oen context for all DIDs, which is anonymity or pseudonymity and that would ignore use cases that don’t involve those.
… so it’s counter productive for the spec and for our goals to insist that herd privacy must apply to 100% of DIDs. It may be 99% of DIDs, that’s fine.
… it’s going to be a mistake for us to say it’s going to apply to 100%.
… and we can talk about the specific cases.

Daniel Buchner: Microsoft must herd with other corporations to ensure that no one knows our main DID is related to Microsoft the company.
We wouldn’t want it getting out that we have a lot of trusted things tied to our DID! clutches pearls.

Ted Thibodeau Jr.: If the herd is all DIDs and DID Subjects, across all DID Methods, then the herd is large, and some herd privacy might be possible.
If each DID Method has its own herd (separating, perhaps, IoT devices from documents/information-resources from humans; and possibly those humans who care about herd privacy from those who don’t [yet, now, etc.]), then some herds will be large and may bestow some inherent herd privacy, but other herds will be small and bestow less, if any, inherent herd privacy.
If the only DID Subjects who do whatever heavy lifting is needed to use a DID Method that tries to preserve herd privacy are the ones who need that privacy, they have already lost it.
Anonymity and pseudonymity must be the default, and still allow for nymity.

Orie Steele: “each did method” is a herd!
“obviously did:github” is only for users of github…. “did:onion” for tor hidden services….

Manu Sporny: +1 to what Ted just said.

Amy Guy: +1 TallTed.

Ted Thibodeau Jr.: names can be used in the anonymous sphere without disrupting the anonymity of those who prefer not to assert some known identity.
… we have to do the anonymising, it’s the only way that gets us there.

Dave Longley: I was about to say something very similar to what ted said.
… every time we have more information added to a DID doc that information is not random, you’re creating new herds.
… every time you add more information like that, you separate an existing herd into the set of information that have this new non random piece of data and the set that does not.
… it’s important for people to understand that you keep reducing the size of the herd whenever you do this.
… you create separate herds that may not be large enough to provide the protection necessary.

Manu Sporny: a concrete question I have for joe and christopher, it feels like we’re all on the same page with respect to trying to protect people when it comes to herd privacy.
… the main point of discussion or disagreement is what endangers herd privacy.
… I’ve heard that this resource=true param endangers herd privacy.
… I don’t necessarily understand how.
… what’s different wrt this feature that other features don’t have.
… so for example, I think we could say any extra piece of information that you add to a DID doc besides the base key materials stuff endangers herd privacy.
… we may be able to have consensus to say that in the spec.
… but what specifically about resource=true is the issue?
… is it this is just one example among many and we’re nipping it in the bud and asserting it here?
… or is there any inherent thing that’s different about resource=true from the key material and the service endpoints?

Orie Steele: if adding properties other than key material to a did document endangers herd privacy…. why did we spend months adding arbitrary extensibility to did documents?.

Joe Andrieu: to manu’s question, it reveals the nature of the subject.
… the cryptographic material does not do that.
… to drummond’s point that is is all about me trying to get herd privacy to apply to all dids.
… that’s not true. I want it to apply to all DID Core features.
… DID methods must be able to innovate, and of course they will do things that are going to create new herds.
… but that’s their choice.
… we have an extensibility method that embraces that.
… please don’t say it’s all about trying to make all did methods apply with my ideas.

Drummond Reed: I acknowledge what Joe said, thanks.

Dave Longley: Orie, I think Joe just responded to that – we can’t stop extensibility, we say how to do it, in fact, so there is interoperability. However, Joe’s argument is to not build certain things into DID core so it’s not something every method needs to support or is coerced to support.

Christopher Allen: I have no problem with there being some type of feature where you can request is this a resource=true. I feel like resource=true is a verifiable credential.
… a self defined, I sign this, I’m saying I’m a resource.
… all these things are at another layer.
… right after united nations id2020 when we did grand compromises on these architectures, we really said we need to separate out identifiers from names and all the other things.
… if we can let that one layer be as safe as possible and allow for methods and other types of things to be able to extend it.
… then that’s the great compromise.
… I would say I should have pushed more back then that even method type stuff ought to be at a slightly different layer, and I didn’t push that hard for that.
… I’m a little more radical, I’d like to cut out more.
… I’m not saying we don’t want to offer these features, I just want to make it at a different layer.
… Names and other identification things that are beyond the control of the identifier.
… this really is a decentralized identifier standard.

Daniel Buchner: use cases [use cases] [[use cases]].
… I don’t know the nuances of resource=true.
… one thing we’re dogfooding right now.
… you could put a nonhuman type inside of the method, because that was something that didn’t exist in the DID core spec, you can do that within the method so you can query by type.
… we’re doing software packages.
… today we own your github, npm, we do want to disrupt ourselves, one idea is to have a DID to stand for a software package, and to be able to index those in ion.
… we don’t have to echo the types out any further.
… I can index by type, find that type of thing, get that URL, and present the same interface that npm would but you don’t have to be owned by us!.
… as long as the use cases are efficient and don’t need a second VDR, these are expensive to run.. we need a ledger to deal with these sorts of thing.
… That’s one use case example.
… I want to make sure it’s not affected.
… service endpoints and typing can be internal to the method, but we need those sorts of things.

Markus Sabadello: comment about DID methods.
… each method is its own herd.
… methods are primarily about how control is established.
… how DIDs are created.
… DID methods should not be about what the IDD subject is and what the DID identifies.

Christopher Allen: +1 to methods about how control is established!.

Markus Sabadello: I think it would a be a big mistake for a did method that can only identify things, only identify github users.
… and extensions are not necessarily done only by DID methods.
… if someone wanted to invent a type property or parameter, that’s not necessarily limited to a method.

Manu Sporny: questions for each side.
… I don’t see how resource=true violates herd privacy, I’ve tried to understand and I don’t get it.
… you still don’t know if it’s an iot device or a person or a chair.
… the reason I’m making a point of this is we need to understand where the line is in the spec.
… I don’t think it’s being well defined.
… if we can talk about why resource=true is an issue and separate that form just adding any other params.
… it could be that what joe and christopher are arguing for is anything beyond how to establish control shouldn’t go in the core spec except for services, that would be something.
… there’s nothing for me to latch onto as an editor to make a judgement call.
… to ask folks on the other side of the point,.
… I don’t think anyone is saying we’re not going to address the use case.
… there will be something to the effect of resource=true, the only question is is it in the core spec or the registry, and what language will we write around that.
… if it comes to it we would move it to the registry, would that trigger a formal objection from anyone?.

Joe Andrieu: q.

Ted Thibodeau Jr.: If I resolve & dereference every DID I encounter and can see “these DIDs say resource=true, and those don’t” then I can focus further observations and correlative efforts on the latter.

Daniel Buchner: I need at least Service Endpoints, for them to be type-extendable. If you leave the type of the DID to Method-land, that’s fine, but you will then have even more clear ‘winners’ even faster when it comes to Methods.
the Method that embraces the best typing structure will have a HUGE advantage.
And if you want to hand that advantage to those of us who want to do that, so be it.
but do understand the game theoretical result of that decision.

Drummond Reed: christopher said something I find helpful. We’re talking about layering.
… it’s important for us to distinguish between DIDs and DID URLs.

Ivan Herman: oh yes.

Drummond Reed: that distinction is so important.
… we may not remember when were wondered what to call URLs.
… my point is DID URLs, it’s a little bit like we’re talking about domain names and we’re going to cast requirements on all the URIs on which domain names are just roots.
… we can say herd privacy does not apply to everything that has a URI, there are many things you need to use a URI for that doesn’t require herd privacy.
… the resource=true parameter turns a DID into a DID URL.
… that DID URL has a specific use.
… the indy community has an immediate, they’re planning on using that param in their DID method. it’s not a layer violation because the resource will be at layer 1, the resource will be in the VDR.
… there is no higher layer involved there.
… all you’re doing is taking the DID, which all by itself the did doc wouldn’t indicate anything by itself, but if you’ve now turned it into a DID URL because you want to do something specific, you’re going to know that that DID URL if you … if I use a DID for an individual, even a DID that has herd privacy by itself from the DID Doc, the usage of the system. many will be violating herd privacy.
… the case for the resource=true param is that it is a particular kind of DID URL which is when the resource is an information resource stored on the VDR, that should be available to any DID method that wants to use it.

Orie Steele: In ION, resource=true is implemented as leading byte prefix…. for “resource type”.

Manu Sporny: Orie, is it a multicodec value?.

Daniel Buchner: DPM FTW!.

Daniel Buchner: NPM, too centralized, boooo!.

Daniel Buchner: Sure, and you can have the underlying DID use a blinded authority scheme for its keys and commitments.

Drummond Reed: I think it is a wonderful idea to have DID methods that are designed explicitly to maximize herd privacy.

Drummond Reed: @manu - I’m happy to explain why I believe resource = true should be in DID Core.

Manu Sporny: @drummond – not the question :) – would you object to it being in did spec registries?.

Daniel Buchner: I don’t care if consumers of DID Docs have to go hit a SE inside the DID Doc.

Christopher Allen: I want to respond to daniel’s thing of having this universal way of differentiating this is a software file.
… I happen to be also working on securing software packages use case.
… the problem is people who are authors, contributors to code, you have organisations that are contributors, you have the actual code itself which evolves over time, based on the authority and verification of the various parties.
… I’m very explicitly with the did:onion, noncorrelation, at the DID level you don’t know anything at that point.
… there’s real concern, you shouldn’t know that this is a person, org or thing at that level.
… you need to go to the endpoint for that thing and request the verifiable claims that is where it says “I’m a resource” or “organisation” or “contributor” which could be denied.
… because at that point, if it happens too soon it can be a denial of service.
… I can go i’m gonna deny that particular level.
… I have knowledge that i don’t want these other people to share.
… I don’t think it’s required to be at that level.
… there is some risk.
… this goes back to an early rwot use case which was the amira use case where you have a software engineer who was working on anti violence software.
… and feels like they could become a target.
… of people that object.
… in DID onion and the code around it we’re keeping that very explicit.
… the whole DID URL thing has been controversial for a while.
… if it’s separate from an identifier in a VC there are additional params that ell a resolver to do a shortcut to get these things so I just make one request.
… I end up with this as a resource.
… I don’t have a problem with that, the resolver can do more than just prove control.
… it can walk through the steps on behalf of the user.
… but that means we’ve made some poor choices by having so much of the DID URL spec in the Core.
… it should be more in deferred to the resolver spec.
… where I draw the line is when there is something in the DID Doc.
… I’m okay if resolvers can offer other services.
… but if it’s in the DID doc that’s where I draw my line.

Daniel Buchner: is this just about automating that at the Resolver layer?
if so, for me, that’s not a deal breaker.

Joe Andrieu: slightly different answer to dbuc.
… I think methods are where you should be innovating these things.
… if microsoft wants to do this, more power to them.
… the notion that certain groups are already expecting this feature is exactly why it’s important that we vet all the features in DID core to make sure they are useful for every method.
… they will be adopted by people who aren’t here for these conversations.
… how resource=true violates herd privacy, the only use case presented are when dids represent a resource.
… it is for discerning human resources from digital resources.

Adrian Gropper: [??] from my perspective the efficiency of the process is not the issue at the DID Core level.
… moving everything behind the service endpoint should be where DID Core puts the demarkation point.
… and then we should be working on more efficient auth methods if that is where the bottleneck shows up.

Dave Longley: to say why allowing resource=true causes trouble for herd privacy: it separates one herd into two… one that is known to be for digital resources, and the other that is unknown (but smaller in size, not including those things that are known to be digital resources).

Manu Sporny: resource=true I’m not hearing.. I heard joe when he said that the use case that was presented was to make distinct human resources from nonhuman resources, yes that was presented and that clearly cuts it between two things we don’t want to cut it between.
… but I don’t think that’s actually the use case.
… you can have a human actor put resource=true just as well as you can a digital resource or an iot resource.
… I don’t think the actual use cases make that distinction.
… i still don’t see the difference.
… I didn’t hear an answer to my question that would anyone object if we put resource=true in the Registries.
… the people that want it would still be able to use it.
… that seems to be the compromise position.
… if we go on the route we’re on right now we’ll see objections.
… we’re going to have to decide whether to take it out.
… it’ll be clear we don’t have consensus to keep it in.
… the only way it ends up staying in the spec is if we get consensus and it doesn’t seem like we are converging.
… who is going to object if we put it in the Registries?.
… if there are objections from that side, we’ll have to see what has the fewest objections.
… I don’t see people changing their position on the call.
… I see people continuing the current position.
… we’re headed towards what’s going to get the least number of objections.
… It’s important to hear clear answers from joe as to why this is any different from any other feature, and from drummond or anyone are you going to formally object if it’s in the registries and then why.

Ted Thibodeau Jr.:

All DID Methods must include resource=true on the surface of all DID Documents, eliminating its utility, but preserving herd privacy.

If I resolve & dereference every DID I encounter and can see without decrypting anything “these DIDs say resource=true, and those don’t”, then I can focus further observations and correlative efforts on the sub-group I care about.

If everything that doesn’t care about herd privacy turns it off, they radically shrink the size of the “privacy” herd, radically reducing that herd privacy, potentially to zero.

Bad actors (including national entities working for their good, which may not be universal) will request all sorts of things through all sorts of disguises and anything that is on the “visible” surface changes the shape available for attack.

Pieces of this are similarly possible with TLS/SSL re TCP/IP traffic, which (lacking VPN) does expose the endpoints of those connections which can be an exposure point. See the analysis of American Revolutionary postal correspondence that discovered the network of conspirators for an example.

Daniel Buchner: types being generalized in the sense of there being a concept in the top level DID spec is good. There are drawbacks that come with it. If it’s generalized across the methods they can interoperate. If it doesn’t happen that’s cool, but different methods might pick different types.
… with service endpoints in the DID doc, I can still make what i want to make.
… my question about this resource=true, what would this being there or not being there imperil about a use case like that?.
… is there something it does?.
… we might only need service endpoints and typing at some layer? am I wrong?.

Grant Noble: the DID method I’m working on is great for long term DIDs that should not be controlled by other entities, and humans who want maximum privacy.
… we pick options that maximize herd privacy.
… if it didn’t break anything we’d set resource=true and if that screws up anyone else’s library, tell me how it’s going to break my experience.
… if it doesn’t help herd privacy, I’m going to pick the most private option.

Ted Thibodeau Jr.: Camouflage is great for herd privacy..

Joe Andrieu: I feel like this was ramrodded in and doesn’t solve the underlying use case.
… there’s a willingness on behalf of the chairs and editors to put any feature in because somebody wants it.
… if there isn’t a good use case that isn’t privacy impacting it shouldn’t be in the document.
… we don’t need it.
… and of the reasons is there was a conflation by brent between resolution and dereferencing.
… method specs are already able to define how we dereference.

Manu Sporny: Nope, disagree with what Joe is saying – this wasn’t ramrodded – we merge things per our process..

Daniel Buchner: Drummond: can you tell me where this being in/out breaks the use case of finding a typed DID in a registry, then following a typed service endpoint to a resource?.

Joe Andrieu: you can take a DID, resolve to a DID doc, and dereference according to the method, and get a resource.
… because it addresses resources in a VDR..

Daniel Buchner: I feel like I am agreeing with Joe, and it kinda feels weird.

Daniel Buchner: ;).

Drummond Reed: I strongly disagree with what joe just said.
… there are obviously ways to doing it. The number one reason to have resource=true in DID core is so that any method that wants to make resources available directly out of VDR has a way of doing it.
… is evernym going to object if that ends up in the registries? probably not.
… but I would consider it a disservice to the adoption of DIDs an dDID URLs if don’t point out a standard way to return a resource and a standard param that any DID method can use to do that.
… the DID itself and associated DID doc for herd privacy, when you add the parameter resource=true and any DID method can add anything they want, DIDs are the root of DID URLs which will have millions of uses.
… all we’re saying is there’s one use of a parameter that will allow you to return a resource from a VDR.
… I believe the universality of the value of that parameter or any kind of resource you might want to return, is the reason for utility’s sake to put that in DID Core.

Daniel Buchner: Drummond: could this be standardized via the Resolution spec?
Perhaps I just don’t get it, I might plead ignorance here.

Ivan Herman: when I looked through the slides, there was the reference to this long appendix which seems to be also hanging on the same discussion.

Drummond Reed: @Ivan - I think the appendix topic is mostly about a separate issue, not herd privacy, so it may be that it warrants another special topic call.

Manu Sporny: thank you drummond, that is helpful to know evernym is not going to object..
… I’m just stating my opinion, not as an editor.
… It’s heartening to hear everyone is more or less on the same page, just disagreeing about details. I know some of you don’t think they are details.
… I don’t know if we have enough to write a definition of herd privacy right now, but feels like we’re all going for the same thing.

Daniel Buchner: Type makes sense, but I don’t get this prop, to be honest.

Manu Sporny: The challenge I have with this entire discussion, and the same thing with type, this is a criticism of the arguments to not put this in did core, if these are useful features people are going to use them anyway.
… I think we should write about it in the spec, but that this keeps coming up and things like type and resource=true and these other things get kicked out of the spec is not going to do anything to prevent people from using it.
… the only thing that is going to prevent that is if there are compelling arguments made for why you should not use these features.
… I still don’t know as a person needing to implement the spec what a dangerous feature is and what isn’t when it comes to herd privacy.
… all I know is that adding more things hurts herd privacy.
… next steps here are calling for consensus to keep tin the spec.
… I expect people will push back on that.
… and the fallback position is to put it in DID spec registries, and it’s going to change any implementer decision.
… the people that wanted it are going to use it anyway.
… so we haven’t accomplished anything other than move the text from one place to another.
… that’s my concern.

Daniel Buchner: This feels like DID Outer Solar System.

Manu Sporny: dbuc, the Kupier Belt of DIDs..

Daniel Buchner: DID Sun Core: Keys, Endpoints - DID Rocky Planet Methods: Typing, indexing - DID Outer Rim Resolution Middleware: resource fetching and advanced transforms.

Drummond Reed: I agree with Manu. I believe we’ve actually weakened the DID Core Specification by removing a universally useful feature..

Dave Longley: all of this comes down to philosophy around what goes into DID core and what doesn’t.
… a lot of what manu said is true about no matter what we do we’re not going to prevent behaviour. but nobody is arguing that.
… no spec can stop people from doing this.
… what this is about is whatever features we put into DID core we’re announcing that this is something your DID methdo should support, and this is the right way to do it.
… anything we put in DID core is encouraging certain sets of features to be implemented by people who want to particpate in this ecosystem.

Joe Andrieu: q.

Dave Longley: If there are sets of things that people feel like will cause problems with privacy and security, we have a place to put those sorts of features, and that is in the registries.
… it doesn’t have to go in core to encourage or coerce all did method authors to support these sorts of features.
… we have the mechanisms we need, we can push things to the registries when they aren’t common features that everyone feels comfortable with.
… if we can adopt that policy we can get through this and have a solution.

Ivan Herman: how do the editors feel? do they have something to go away with, or not?.

Christopher Allen: I think it is more than resource=true. We need to define the principle..

Joe Andrieu: this call was not to be about resource=true.
… there’s a fundamental to get agreement on. What does it mean to have herd privacy? I’m sad we didn’t get that.

Jonathan Holt: +1 JoeAndrieu, I think this needs a lot more discussion.

Manu Sporny: two proposals for each point of view. I’m trying to focus on resource=true as something concrete.
… any modifications to either of those?.

Ted Thibodeau Jr.: looks more like straw poll than proposals?.

Grant Noble: Digital Contract Design has applied for W3C membership, and if a vote is taken would like to vote..

Christopher Allen: I think resource=true is a red herring of a larger problem.

Daniel Buchner: 0 on both - I am too ignorant on this topic to vote.

Proposed resolution: Keep resource=true in the DID Core specification.. (Manu Sporny)

Drummond Reed: +1.

Daniel Buchner: 0 - I am too ignorant on this topic.

Grant Noble: -1.

Dave Longley: -1.

Ivan Herman: 0.

Orie Steele: -1.

Joe Andrieu: -1.

Manu Sporny: -0.25.

Amy Guy: -0.5.

Ted Thibodeau Jr.: -0.5.

Markus Sabadello: 0.

Jonathan Holt: -0.5 i to am ignorant.

Ivan Herman: I have the impression that this will not make it.

Proposed resolution: Move resource=true from DID Core to the DID Spec Registries (as an extension). (Manu Sporny)

Daniel Buchner: 0.

Dave Longley: +1.

Grant Noble: 0.

Orie Steele: +1.

Drummond Reed: 0.

Ivan Herman: 1.

Manu Sporny: +0.75.

Joe Andrieu: 0.

Amy Guy: +0.5.

Christopher Allen: +0.5.

Ted Thibodeau Jr.: +0.5.

Markus Sabadello: +0.5.

Jonathan Holt: 0 i to am ignorant.

Resolution #1: Move resource=true from DID Core to the DID Spec Registries (as an extension).

Manu Sporny: we’ll need to talk again, editors.
… in the Registries folks that want it can do what they want.

Markus Sabadello: Does this solve JoeAndrieu ‘s, agropper___ ‘s and ChristopherA ‘s concerns?.

Christopher Allen: Markus, it does not.
I like your definition earlier is that it is about control.

Dave Longley: i think if there were more decentralized registry technologies out there … a lot of these issues would go away … because people could post what they wanted over there using VCs… and DIDs could be left alone to do what they do best..

Christopher Allen: +1 to dlongley.

Ivan Herman: closing remark: I would like to see where this full discussion leads as far as the whole spec is concerned. I have heard several times that resource=true is one specific thing that triggers this discussion.
… We have to drive the document towards CR and that worries me.
… I would like to see specific change proposals if we have one to move ahead.
… thank you everyone for coming..

2. Resolutions

Resolution #1: Move resource=true from DID Core to the DID Spec Registries (as an extension)..