Drummond Reed: This is the second of a series of calls on the DID Spec... ✪
Drummond Reed: Manu and Dave weren't able to be on the call last week - our goal here is to close on the DID spec, this proposal is the next stage of discussion. ✪
Drummond Reed: Last CG call made it seem like these are competing proposals, but that's not the case, it's just a continuation of the conversation. ✪
Drummond Reed: We have six items we could get to consensus on with folks that were on the call last time, there are two items that are new-ish don't have consensus ✪
Drummond Reed: Haven't had much time to move those thigns forward - interested in sync'ing w/ Manu, Dave, and anyone else that hasn't been a part of this yet to talk about first six things. ✪
Manu Sporny: It's a post-Rebooting version which I actually got PRs in on. Hopefully over the next couple of weeks I'll get that finalized so we can layer this work on top of that. Steady stream of PRs from now on. [scribe assist by Dave Longley] ✪
Drummond Reed: Let's talk through the issues in order, questions, answers, ideally come to some sort of agreement on it. ✪
Drummond Reed: This is what we talked about at TPAC - JSON-LD is great but there are people that want other serialization formats as well. ✪
Drummond Reed: Proposal is that we have a requirement in the spec that a processor can process just the JSON w/o the JSON-LD so that the two formats are compatible. You're already doing this w/ the other specs. ✪
Chris Webber: We're doing this in ActivityPub, but we need to make sure you can go both ways - plain JSON also needs to be parsed as JSON-LD - it can be expanded into a graph and all terms are defined, new properties in the context... this is not hard to do in general... even w/ apps using naieve JSON tooling. Mastadon is using ActivityPub - they're not using JSON-LD tooling except when they're using LD Signatures, so it's nice because you can uphold both properties at the same time. ✪
Chris Webber: I'd like to make sure we hold up what is suggested - any JSON-LD document must be able to be treated by naieve JSON-LD tooling, but also the reverse. ✪
Drummond Reed: Ok, so if you are doing JSON-LD parsing, do you need to fetch the context and validate the JSON-LD document? ✪
Dave Longley: The only time you need to get the context is when you're transforming, normalizing, etc. If you're not doing that, you don't need to do that. ✪
Chris Webber: What's nice is that method implementers can make it readable by plain JSON and parseable by JSON-LD, method implementers need to be careful, but you can degrade from there... use JSON native tooling... that's fine, or if you pull in as JSON-LD. ✪
Markus Sabadello: What about JWS as signatures? Wouldn't you just use LD Signatures in all cases? ✪
Dave Longley: That's an open question, don't know who wants to use JWS? ✪
Christian Lundkvist: We're using JWS now - for attestations. ✪
Christian Lundkvist: We did some discussion that it's unclear if the DID Document itself needs to be signed as it is fetched out of the resolver, or if it's enough that a signature is present out of band but validated in the resolver itself, and then returned in whatever data format is supported. ✪
Dave Longley: I have a couple of comments - whether or not a signature is present is up to a combination of the DID Method, the resolver, and the application that's using it. ✪
Dave Longley: LD Signatures has a signature suite that is compatible with JWS... you still need to canonicalize. ✪
Sam Smith: We can't enforce canonicalization in JSON. ✪
Sam Smith: Any time you have a JSON document that embeds a signature and you reserialize - JSON doesn't have a canonical serialization, you'd have to include the part of the document signed in base 64 ✪
Dave Longley: The canonicalization algorithm used is on the JSON-LD data - whatever whitespace, as long as data semantics change, you can use JSON-LD to conver to RDF. ✪
Manu Sporny: Let me jump in really quickly. There's going to be a very severe mismatch between what Sam is saying and what we're saying because we don't have a history. [scribe assist by Dave Longley] ✪
Manu Sporny: We know about all of the shortcomings of the JOSE stack and the normalization issues. And many of those things are what led us to create the Linked Data stuff. We have 8-9+ year history working with this canonicalization, etc. Our comments aren't coming from a naive standpoint. I agree with what you're saying Sam about there being no JSON canonical form. [scribe assist by Dave Longley] ✪
Manu Sporny: When you sign with JOSE you do base64 encode it. We understand that. We know about that issue. So this concept of mixing JSON and JWS and the DID documents... I'm concerned about it. [scribe assist by Dave Longley] ✪
Manu Sporny: But that's kind of somebody else's problem. Our ledger picks JSON-LD and Linked Data Signatures for a variety of reasons because we think the end result is simpler than using plain JSON + JWS JOSE stack, etc. If someone else wants to use JSON and JWS stack etc, they have to figure that out. [scribe assist by Dave Longley] ✪
Sam Smith: I heard we should just stick with LDS and that's all that's supported. [scribe assist by Dave Longley] ✪
Manu Sporny: No, not saying that. This work started out with JOSE and we hit brick walls, we switched to LDS. We've been there. [scribe assist by Dave Longley] ✪
Sam Smith: I don't say JOSE is the answer either. Having a base64 field that is signed is something that will work in general as opposed to requiring the full JOSE stack to manage everything. [scribe assist by Dave Longley] ✪
Sam Smith: One of the problems with JOSE is that you can specify all the signatures with all the parameters, there are security holes. [scribe assist by Dave Longley] ✪
Sam Smith: It might be a strawman to say there are only LDS and JOSE as choices. [scribe assist by Dave Longley] ✪
Manu Sporny: We're not saying that. We're saying we have a fairly good understanding of the shortcoming of JOSE JWS and you can do it that way if you want, that's allowable. If you want to use LDS you can do that. [scribe assist by Dave Longley] ✪
Sam Smith: We went from we want to have DID docs to both using JSON tooling and JSON-LD tooling and then you need JSON-LD tooling for the signature. [scribe assist by Dave Longley] ✪
Manu Sporny: Yeah, I agree. We have to be careful though for every new thing we add here. There's a tremendous amount of complexity for each of these things, particularly for security audits. [scribe assist by Dave Longley] ✪
Sam Smith: The standard protocol practice is to attach the signature after the serialization. Whereas in LDS you are embedding the signature in the Linked Data, requires canonicalization. You can't build a LD master schema where the signatures are part of your schema. [scribe assist by Dave Longley] ✪
Chris Webber: I've been working w/ Mastadon... seeing how they use naive JSOn tooling ✪
Chris Webber: If you end up base64 encoding and signing, you can't embed. ✪
Sam Smith: You can, but you can embed and base64 and embed. ✪
Sam Smith: You don't have a bare document that's exploded and exposed and canonicalized/re-sign... ✪
Chris Webber: Even in their case, they use naieve tooling, but they do use LD signatures stuff... dev that uses it doesn't know about LD signatures - but does use the libraries. Even though you're using LD tooling, you can have a naieve tooling mindset. ✪
Sam Smith: Except that if the Linked Data tooling is doing lookups, in a data intensive app - that's expensive. ✪
Dave Longley: You can cache data, that's not an issue in production, you don't do lookups in that case. I don't think anyone is saying use ONLY LD Signatures. ✪
Dave Longley: We say "here are the specs on how to do X" -- we point folks at that. ✪
Sam Smith: I think that's a great thing - we may want to make it easy for people to migrate from standard JSON format to LD format. ✪
Dave Longley: I think Chris' perspective is - it's just another version of JWS and a magic signature gets attached to your document, you made a call, a signature appeared, that's another way to look at LD Signatures - you don't need to bring in the mental model of signatures. ✪
Nathan George: Yes, you get this JSON data and you use whatever library to deal w/ the signatures... as different tech and signatures evolve, we want the central data model to keep working. ✪
Drummond Reed: This keeps coming up - Jason Law said signatures are optional... data integrity - ties in w/ point #2, if you don't validate DID Document against target ledger, you're raising other security issues. ✪
Drummond Reed: You don't always have the DID when you register the DID Document... one possible approach here is to simplify DID spec to say signatures are covered in another document. ✪
Manu Sporny: I wanted to go back to the format independence question. If someone wants to do JSON and JWS/JWT that's fine. But someone is going to have to write and maintain those sets of specifications. Who is volunteering to do that? That's the first question. If we want that serialization to get through the W3C standardization process then at least two ledgers will need to implement that to get it through W3C rec process. [scribe assist by Dave Longley] ✪
Manu Sporny: I'd like to know who is going to be doing JSON+JWS (non-LDS version). [scribe assist by Dave Longley] ✪
Markus Sabadello: Two code bases or two ledgers? [scribe assist by Dave Longley] ✪
Manu Sporny: That's an interesting question. Not sure. [scribe assist by Dave Longley] ✪
Markus Sabadello: What if there are two resolvers? One in Java and one in another language? [scribe assist by Dave Longley] ✪
Dave Longley: This is getting to my point about the purpose of DID documents and proving interop, etc. [scribe assist by Dave Longley] ✪
Manu Sporny: I didn't hear anyone pipe up and say they will use JWS. [scribe assist by Dave Longley] ✪
Manu Sporny: Christian? [scribe assist by Dave Longley] ✪
Christian Lundkvist: Probably? We are currently using plain JSON and JWS for most of our stuff. [scribe assist by Dave Longley] ✪
Drummond Reed: Is there is a deeper question to ask... what methods represented on the call plan to produce signed DID documents vs. unsigned? [scribe assist by Dave Longley] ✪
Manu Sporny: I'd phrase it differently, at some point there has to be some kind of cryptographic proof. The other concern that we have ... let me jump back. We could assert that there is no signature on a DID document, or say it's optional I mean, and that's fine across every DID method we're looking at. [scribe assist by Dave Longley] ✪
Manu Sporny: I think that's totally fine. Even in the Veres One ledger the signature is not on the DID document itself it's on an event that comes into the ledger. [scribe assist by Dave Longley] ✪
Manu Sporny: When you fetch the DID document there's a wrapping signature there. [scribe assist by Dave Longley] ✪
Manu Sporny: The whole argument around JWS is moot and then we could potentially stop talking about it. [scribe assist by Dave Longley] ✪
Manu Sporny: The more options we give people the more things others will have to do... if people want JSON, JSON-LD, JWS, LDS, methodX, methodY, and so on -- you're pulling in more libraries. [scribe assist by Dave Longley] ✪
Manu Sporny: The people pushing JSON-LD and LDS have a strong reason for doing so. Is the JSON and JWS stuff really buying people much? Saying things are optional and so on leads to extra security and operational costs. [scribe assist by Dave Longley] ✪
Drummond Reed: Ok, with each of these, will try to see if we have consensus ✪
Drummond Reed: There are hypothesis I'm going to ask about. ✪
Drummond Reed: It sounds like there is agreement that spec can say format is JSON-LD, but can be used as naive JSON. ✪
Drummond Reed: Second thing, signatures in DID docs are optional. ✪
Drummond Reed: Each DID Method could specify whether signatures are valid - or DID Spec can say you can attach signatures to document. ✪
Drummond Reed: Folks at table willing to specify, here is how you do JWS signature, they can do that, and we're done. ✪
Dave Longley: I'm going to try to rewind - signatures being optional - general concern that there might be some confusion over purpose of a DID Document and determining what the data model will look like, what serialization will look like - create a common format for what is returned by resolver. ✪
Dave Longley: You improve interop by having resolvers return same DID docs - I'm thinking of this in terms of apps that want to use DIDs, regardless of what method is being used by those DIDs... when we talk about signatures - DID Document that's returned, authenticity is checked by resolver, or trust resolver in some way. ✪
Dave Longley: "The purpose of a DID document is to return a standard set of metadata associated with a DID". [scribe assist by Drummond Reed] ✪
Dave Longley: There are trade-offs in these cases - common tooling, resolver can potentially be a lot simpler. ✪
Drummond Reed: To remember what I want to say when the queue gets to me: should we look at DID resolution as a two-step process. ✪
Sam Smith: The simplest common protocol for http is to add a Signature header ✪
Drummond Reed: Also, to talk about Dave's point about a common purpose of DIDs and DID docs. ✪
Dave Longley: That does depend on some common method for retrieving things from these ledgers. That's going to cause resolvers to become heavyweight... build apps that have embedded resolvers, that work across multiple DID methods - it's important for us to figure out if there is a common protocol to retrieve things from a variety of ledgers... how do we create resolvers that can pull from different ledgers, we want interop between different DID Methods... there may be apps that do care about that, but for apps that don't, we want to support that. ✪
Sam Smith: The signature header signs the body of the response ✪
Dave Longley: It's important to understand consequences ✪
Nathan George: This gets to the same point that Dave made... where we get into trouble w/ variation of signature scheme, not tight binding to identifier, data model... we get around this in DID spec by making so many things optional. ✪
Nathan George: We can push much of this into method spec... but where we talk about Verifiable Credentials - data model / signature block interact - this is going to be an ongoing issue as we try to deal w/ context where we don't depend on LD data model... signature scheme may not be able to depend on context ✪
Nathan George: We can resolve on the DID spec, but on VC spec, it'll become a real issue. ✪
Drummond Reed: Core purpose of DIDs and DID Documents and DID Methods... I don't think there is debate about this, but we should focus. ✪
Drummond Reed: I'm going to put a hypothesis out there... react to it. ✪
Drummond Reed: Agree w/ Dave Longley - you need to get back a standard set of metadata ✪
Drummond Reed: Common data that you want - associated set of keys, associated service endpoints. ✪
Sam Smith: @Kimhd the linked document does not seem to describe and attached signature block? ✪
Drummond Reed: A way to associate them when necessary ✪
Drummond Reed: That's the one thing that DID Docs need to do... very basic layer for many things we don't anticipate. ✪
Drummond Reed: I see a pattern here - start to think of resolution as a two step process - client to resolver and resolver to method. ✪
Drummond Reed: Metadata that client needs back and verifiacation that client needs - resolver is not technically required. ✪
Drummond Reed: Resolver needs to implement method to talk to target system... then perform whatever verification is necessary - that's where DID checking comes in... that becomes much easier to focus on core metadata... instead of focusing on core verification. ✪
Chris Webber: I agree with Drummond, for good reason, a lot of us are focused on the low level... but hopefully we're handing this off to developers. ✪
Chris Webber: Their big question is "I'm not going to download a full node", we're probably going to end up more DNS like - resolvers that people connect to... how do you trust just one resolver? ✪
Chris Webber: Maybe we should have some general protocol to run over HTTP - so common - implementers are not going to be interested in running that... maybe best path is to make sure there really are the economics are returning a DID Document are such that people will want to run resolvers. ✪
Christian Lundkvist: Most of the DID Methods that we are discussing probably don't even need the signature on the DID Document - a lot of the discussion is moot - however, the discussion might be shifted to talk more about Verifiable Claims, which is not the purpose of this discussion, but there is a question of whether or not Verifiable Credentials is a JSON-LD document. ✪
Dave Longley: There's a W3C working group for that :) ✪
Christian Lundkvist: I'm not sure if DID Resolver needs to spit out a DID Document w/ a signature on it - the onus on verifying that there is a cryptographically strong link between DID and DID Document falls on the resolver. ✪
Dave Longley: If it falls on the resolver then we're going to need to have another piece (a "client" for the resolver) that actual applications use, they will not be running full nodes, etc. ✪
Drummond Reed: What Christian is saying is what I was trying to say, which is that the resolver can implement the verification step, and that can be method specific, and then return a "plain" DID document. ✪
Markus Sabadello: Some comments on lightweight and heavyweight - Drummond said something about two-phase or two-part resolution architecture... logic that you need is lightweight, you could run it on a local machine... sometimes you need a full node (more heavyweight) ✪
Markus Sabadello: BTCR DID, you can resolve it in 3 different ways... ✪
Dave Longley: If "sometimes" you want a full node -- either people won't use them or we need another piece in the architecture to make those DID methods more tenable. ✪
Markus Sabadello: Some ledgers return a DID Document itself - Veres One is very lightweight, for example... but you can't do that w/ other methods that are more heavyweight. ✪
Markus Sabadello: There will be different setups/configs - not much value in having signature in DID Doocument itself, how do you setup the components, how close is resolver to source of truth, how do you trust resolver -- those questions are important. ✪
Manu Sporny: The conversation we're having is good but meandering a bit. I want to close out the format independence thing with a specific proposal. I think we all agree that we want format independence. There's an abstract data model, services, keys and identifiers as concepts in there. [scribe assist by Dave Longley] ✪
Manu Sporny: JSON/JSON-LD may be used there as a format for it. [scribe assist by Dave Longley] ✪
Manu Sporny: It sounds like signatures are optional. Does that close out option 1? [scribe assist by Dave Longley] ✪
Drummond Reed: I think there's a third thing. Will we in the DID spec still specify standard signatures that we can recommend? [scribe assist by Dave Longley] ✪
Drummond Reed: That methods can refer to. [scribe assist by Dave Longley] ✪
Manu Sporny: When it comes to W3C and how it does stuff like that, you tend to give some examples. You split into core data model where you say "here's how you express the data model as JSON/JSON-LD in examples" and you leave other serializations to external specs. You don't prevent other serializations from happening. That's perfectly reasonable, some people go more academic than that and say you should just talk about the data model full stop. Go to other specs [scribe assist by Dave Longley] ✪
Drummond Reed: I think we're there. [scribe assist by Dave Longley] ✪
Dave Longley: Regarding resolvers - Markus said that some resolvers might need full node, others you'll only need lightweight... DID Methods that require full method in resolver will only be used by mechanisms that ... don't want that to happen, don't want full nodes to be left out where DID is... they just want to use DIDs... run lightweight resolver for anything... ✪
Dave Longley: Get the DID Document, do something with it. ✪
Dave Longley: We need another layer in the architecture here - we need a protocol -- we might want to push more complex stuff into ledger nodes... embed lightweight clients/resolvers... ✪
Chris Webber: If you got paid something like filecoin to provide DIDs ✪
Chris Webber: There may be motivation to provide all these DIDs ✪
Christian Lundkvist: Strongly disagree about putting DID resolution in blockchain nodes ✪
Dave Longley: For example, if all DID Methods -- lightweight protocol on HTTP... applications want to use any data across DID method, implement HTTP GET - don't want to reopen #1, but a piece of that might be that resolvers then place signatures on DID Document that come back and that's part of authenticatoin method, trust resolver, trust authentication that came back - sigs appear on DID Docs as they come back from resolvers... run a full node for this - people aren't going to do that for lots of apps. ✪
Markus Sabadello: Agree with dlongley that resolvers can be run as a cloud service ✪
Drummond Reed: Resolvers adding signatures? From the resolver itself? ✪
Dave Longley: To accept users ... we want interop - we're missing critical peice of architecture, push stuff into ledgers or resolvers are services. ✪
Chris Webber: But +1 we need a way that people can use resolvers, and we need a way to have general-cross-interoperability ✪
Mike Lodder: Then we need to be able to verify the resolver results ✪
Dave Longley: We want to push complexity to DID Methods, not resolvers. ✪
Drummond Reed: For two steps - client / app talking to resolver - lightweight protocol there - Markus made the point, multiple configurations - because of the crypto involved, where the verification takes place - DID Spec, defines conformance targets. ✪
Drummond Reed: Say "here are the different configurations" ✪
Drummond Reed: Can work w/ Markus - you cover those so you are defining ways to resolve a DID, and refer to conformance targets... if you talk to resolver, that's how X is done, if you're adding signature, that's how Y is done - I don't think anyone is saying we should do it all at ledger/client ... all 3 are possibilities. ✪
Drummond Reed: We can put that back out as topic - define different configs - conformance targets for implementers of spec and we need to do it in the spec. DID Docs / Methods and resolution - tackle that in context of definitions. ✪
Christian Lundkvist: If you have DID Method, it's only valid if you run a full node? ✪
Dave Longley: Perhaps we want a DID resolution spec instead -- where DID methods would define a mapping to a common protocol ✪
Dave Longley: And not mention this in the DID spec (other than to say "look over here for interoperable DID resolution") ✪
Mike Lodder: This distinction seems more important to a library implementation, rather than the method spec itself ✪
Drummond Reed: Resolvers that have different capabilities - client, DID Method can talk directly to target system - resolver, resolver is local... resolver is in cloud... resolver in cloud but light client - all of these configurations - there is a standard set of options. ✪
Dave Longley: We're going to end up creating a centralized point of failure if we do that -- markus. ✪
Dave Longley: Everyone is going to want to use a monolithic resolution service ✪
Drummond Reed: The reason we need to define those config options is so a DID Method spec - for pattern A, this is how you do that, for pattern B, this is how you do it - method spec don't have to recreate wheel. ✪
Drummond Reed: We did a simpler version of this for XRDS ✪
Markus Sabadello: I think we can define common interface for talking to resolver ✪
Dave Longley: I want us to be aware of making resolution too heavyweight - we might create a single point of failure... might recreate a problem. Don't want us to get totally derailed. ✪
Manu Sporny: I originally put myself on the queue to say exactly that. DID resolution sounds like a full on sprint and we need to walk and maybe run. [scribe assist by Dave Longley] ✪
Manu Sporny: If we could have the rest of the folks in the group pull us back to the items we're talking about -- because meandering conversations don't help on spec text. [scribe assist by Dave Longley] ✪
Topic: Optional ID Property for the DID
Drummond Reed: +1 To making sure to focus on the spec using cloud-based resolvers does not reintroduce centralization. ✪
Manu Sporny: Yes, I disagree with having the ID be optional. Playing off a number of things I heard on the call today. One of the purposes of the DID document is to provide a common piece of data an application can use regardless of the DID method that's behind it. The closer the DID docs look between multiple systems, the easier it is for the ecosystem to use them. [scribe assist by Dave Longley] ✪
Drummond Reed: Ah-ha! Light bulb. If we specify a two-step resolution process, then the DID doc CAN require the DID. ✪
Manu Sporny: Let's make it look almost identical, that's a design goal even if we can't fully actualize it. [scribe assist by Dave Longley] ✪
Manu Sporny: Making it optional is because there's an "emergent" value that is the ID. [scribe assist by Dave Longley] ✪
Manu Sporny: I'm thinking about BTC-R there's this initial bootstrapping process and you don't know the ID until it's created after the fact. But would you ever have an application ask a resolver for something ... it has an ID it's asking for. [scribe assist by Dave Longley] ✪
Manu Sporny: So you would expect the DID doc to have the ID in it when it resolves. [scribe assist by Dave Longley] ✪
Manu Sporny: I can't think of any DID method where it's optional. [scribe assist by Dave Longley] ✪
Daniel Buchner: Composition of merkle root hash and [missed details while listening] [scribe assist by Dave Longley] ✪
Manu Sporny: But you can add the ID later. [scribe assist by Dave Longley] ✪
Daniel Buchner: But the payload may be signed. [scribe assist by Dave Longley] ✪
Dave Longley: (And adding the ID could affect the validity) ✪
Dave Longley: Cwebber2: It's completely reasonable that you could have an emergent document so you can't have ID when you generate it, but you can always tack on the ID when you hand it over to the user. Even if there was no way to have the ID until you do all the generation. ✪
Drummond Reed: I agree with Manu's point that the resolver will ALWAYS have the DID, regardless of whether it is emergent. This is why a two-step resolution process makes sense. ✪
Dave Longley: ?: If you're trying to validate this, maybe or maybe not, but if you're trying to ensure that hashes match up -- removing the ID to check things would have to be known to the client. ✪
Dave Longley: Cwebber2: I don't see any reason why that wouldn't be possible [to include those instructions to remove the ID before doing validity checks]. ✪
Dave Longley: Yes, we need to think about this in terms of resolution more than in terms of DID methods! ✪
Drummond Reed: This further enforces concept of two-step resolution process - you don't have to stick in another component, two step can be implemented directly by a client... two steps are separating execution of method, and whatever is returned. ✪
Drummond Reed: Here's a common metadata that needs to be returned, here's what needs to be returned by target system - I think we can all agree on that - DIDs are emergent property, Sam's got use cases aroudn that - that's cool, that can happen in step 1... but step 2 is where the DID Method thing comes in. ✪
Drummond Reed: Getting back to point - app can make its own security decisions on what resolver it trusts for what verification... or needs to talk to full node, or resolver - resolver code is in me - I'll trust it... ✪
Dave Longley: Completely agree with that - We don't care what DID Methods do, but DID DOcuments are what pops out and that's what we're trying to standardize. ✪
Dave Longley: These are the checks I did, there are a variety of thigns we can do that - what's going on w/ DID Methods, etc. We care about same DID Document pops out on other side - includes whatever information is necessary. ✪
Drummond Reed: Resolver could add signature? You said that earlier. ✪
Dave Longley: It could be, there might be a variety of ways to do that. ✪
Drummond Reed: Some might have thought of signature on DID Document coming from resolver, some from ledger... we want everything to create similar documents. ✪
Sam Smith: One of the suggestions was that there be an ID field that has the DID, but the DID might not be the actual DID, but the type or algorithm to generate the DID. ✪
Sam Smith: I'm fine w/ supporting the concept that we're talking about final document that's resolved, not some interim version. ✪
Dave Longley: The "mapping" from however things are stored by a particular DID method to how you get to the "resolved" DID document is up to the method... but it does need to say it ✪
Drummond Reed: What is the best way to continue discussion of next 3 items? ✪
Sam Smith: How do we update the hardening proposal? ✪
Drummond Reed: Add change suggestions to docs, try not to use only comments. ✪
Dave Longley: Use the suggest feature, easier to find stuff. ✪