00:23:00 <gannan> gannan has joined #did
01:46:09 <Zakim> Zakim has left #did
01:46:26 <gkellogg> gkellogg has joined #did
01:58:24 <gannan> gannan has joined #did
02:05:55 <gkellogg> gkellogg has joined #did
22:53:50 <RRSAgent> RRSAgent has joined #did
22:53:50 <RRSAgent> logging to https://www.w3.org/2019/11/26-did-irc
22:54:06 <brent> rrsagent draft minutes
22:54:17 <brent> rrsagent, draft minutes
22:54:17 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/26-did-minutes.html brent
22:54:36 <brent> rrsagent, make logs public
22:55:32 <brent> Meeting: Decentralized Identifier Working Group
22:55:47 <brent> Chair: Brent Zundel
22:56:38 <brent> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2019Nov/0042.html
22:58:18 <grantnoble> grantnoble has joined #did
22:59:21 <brent> Topic: Agenda review, Introductions, Reintroductions
22:59:25 <jonathan_holt> jonathan_holt has joined #did
23:00:36 <Orie> Orie has joined #did
23:00:45 <daniel> daniel has joined #did
23:00:46 <Orie> present+
23:00:50 <daniel> Need to add an item to the agenda
23:01:07 <manu> present+
23:01:11 <daniel> https://github.com/w3c/did-core/pull/84
23:01:15 <jonathan_holt> present+
23:01:20 <daniel> https://github.com/w3c/did-core/issues/70
23:01:22 <brent> present+
23:01:30 <daniel> Should be a quick consensus confirm
23:01:34 <markus_sabadello> markus_sabadello has joined #did
23:01:50 <daniel> there was already 0 opposition during all discussion and the PR should be clean
23:02:09 <markus_sabadello> present+
23:02:18 <daniel> present+
23:03:47 <drummond> drummond has joined #did
23:03:51 <drummond> present+
23:03:52 <TallTed> present+
23:03:55 <selfissued> selfissued has joined #did
23:04:01 <drummond> scribe+
23:04:07 <selfissued> present+
23:04:14 <tplooker> tplooker has joined #did
23:04:23 <tplooker> present +
23:04:26 <grantnoble> present+
23:04:34 <drummond> First up: agenda review and intros/reintros
23:04:42 <kimhd> kimhd has joined #did
23:04:48 <tplooker> present+
23:05:09 <kimhd> present+
23:05:26 <kimhd>  /me a lot of dan* b*s
23:05:57 <manu> s/\ \/me a lot of dan\* b\*s//
23:06:16 <manu> rrsagent, draft minutes
23:06:16 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/26-did-minutes.html manu
23:06:20 <drummond> Agenda first up will be annoucements, then status update on key formats, then horizontal review, then PR 84 and issue 70, then continue DID metadata
23:06:32 <drummond> then if time, matric parameters
23:06:41 <drummond> matric /s matrix
23:06:44 <jonathan_holt> call in details?
23:07:12 <drummond> Call in details are in agenda email that has webex stuff in it
23:07:30 <kdenhartog> kdenhartog has joined #did
23:07:54 <manu> s/Agenda first/Brent: Agenda first/
23:08:04 <manu> s/then if/Brent: then if/
23:08:12 <drummond> brent: At the F2F in Amsterdam, the social event will be a boat tour. Ivan will help organize.
23:08:16 <manu> s/call in details?//
23:08:51 <agropper> agropper has joined #did
23:08:59 <drummond> ...cost will be about 20 euros per person - seeking sponsors
23:09:01 <agropper> present+
23:09:11 <drummond> ...FPWD of Use Cases document will be published the 28th
23:09:34 <manu> s/present +/present+/
23:09:36 <drummond> ...next key format discussion will be Wed Dec 4th at noon Eastern Time
23:09:40 <manu> rrsagent, draft minutes
23:09:40 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/26-did-minutes.html manu
23:10:55 <drummond> grantnoble: Introduced himself. Works with Dan Burnett on the Pegasus team at Consensys. Based in Australia.
23:11:26 <drummond> agropper: Introduced himself. CTO of an NGO called Patient Privacy Rights.
23:11:44 <drummond> ...works on putting together the various standards that can support patient privacy in healthcare.
23:11:55 <drummond> ...working on SSI, UMA, OAuth
23:12:12 <drummond> brent: Asking Orie to give an update on key format discussions
23:12:38 <drummond> Orie: Been discussing different key formats. Multiple proposals for early voting.
23:12:49 <drummond> ...JWK is always a valid format for representing keys.
23:12:58 <Dudley> Dudley has joined #did
23:13:12 <drummond> ...Attempting to come to some consensus about what other formats should be supported.
23:13:17 <Dudley> Present+
23:13:35 <drummond> ...RSA PEM and ed25519 are being considered/discussed.
23:13:49 <kimhd> q+
23:13:58 <drummond> brent: any proposals coming out of this group will be brought before the greater group for consensus
23:14:09 <drummond> ...encouraged by progress
23:14:10 <brent> ack
23:14:27 <brent> ack kimhd
23:14:45 <drummond> kimhd: Question for Orie: where did we land with the ongoing algorithmic agility concern?
23:14:58 <selfissued> q+
23:14:59 <drummond> ...with JWK, there were potential nonsense combinations
23:15:37 <drummond> Orie: there is an open issue assigned to him RE the specific privacy concerns on JWK or other key formats that uses non-standard config values
23:15:44 <brent> Topic: key format discussion update
23:15:45 <drummond> ...this applies to all properties in a DID document
23:16:04 <drummond> ...JWK and Jose have formal key definitions, but not for base 58
23:16:20 <drummond> ...multibase has been raised as a format that a number folks like
23:16:21 <ken> ken has joined #did
23:16:32 <drummond> ...there is a spec in progress at IETF on that
23:16:36 <brent> ack selfissued
23:16:45 <ken> present+
23:17:04 <drummond> selfissued: Responding to Kim: it's possible to inject stuff with privacy concerns in any key format, including JWK
23:17:18 <Orie> regarding pii / extra data in did documents (and their properties): https://github.com/w3c/did-core/issues/124
23:17:25 <drummond> ...it can be somewhat controlled by required and optional fields
23:17:44 <drummond> brent: if you care deeply about this topic, please join the calls for the subgroup
23:18:11 <Orie> Regarding supported public key formats: https://github.com/w3c/did-core/issues/67
23:18:16 <drummond> jonathan_holt: is on the phone
23:18:24 <brent> Topic: horizontal review
23:18:26 <brent> https://github.com/w3c/did-core/labels/horizontal%20review
23:18:50 <drummond> brent: this is the labeled horizontal review issues
23:19:06 <drummond> ...the chairs have reached out to the other chairs to let them know about the FPWD
23:19:24 <dmitriz> dmitriz has joined #did
23:19:28 <drummond> ...the chairs have looked at the assessment, especially 104 and 105
23:19:41 <drummond> ...if you disagree with the assessment, let the chairs know
23:19:46 <dmitriz> present+
23:19:55 <drummond> ...the chairs also invited feedback from the other groups
23:20:07 <brent> q?
23:20:10 <drummond> ...also, the Privacy Interest Group has indicated interest in reviewing
23:20:20 <brent> Topic: Issue 70
23:20:25 <drummond> topic: issue 70
23:20:32 <drummond> ...5 minute time box
23:20:56 <drummond> daniel: proposal is for an additional matrix parameter called initialvalues
23:21:06 <markus_sabadello> q+
23:21:18 <Orie> https://github.com/w3c/did-core/issues/70
23:21:34 <drummond> ...this is needed for DID methods that are anchored someplace else and thus there may be initial values that need time to be turned into final values
23:21:51 <brent> q?
23:21:55 <drummond> ...having the initial values allows the DID to be used immediately
23:22:00 <brent> ack markus_sabadello
23:22:18 <drummond> markus_sabadello: Has been part of the discussion of this, and generally supports it
23:22:24 <manu> q+ to have matrix parameter discussion first, but not opposed.
23:22:34 <manu> q+ to ask for examples
23:22:38 <brent> ack manu
23:22:38 <Zakim> manu, you wanted to have matrix parameter discussion first, but not opposed. and to ask for examples
23:22:49 <drummond> ...suggests that before we discuss any of the matrix parameters in detail, we should introduce the overall topic
23:23:05 <jonathan_holt> q+ is there a more specific example of the need for init values?
23:23:06 <drummond> manu: would like to have the matrix parameter discussion first
23:23:14 <brent> q?
23:23:18 <drummond> ...this for example might be a resolver option
23:23:38 <drummond> ...also would like to see examples in the spec, because it's hard to understand
23:23:53 <drummond> ...for example, how are the initial values expressed/encoded
23:24:16 <drummond> daniel: the initialvalues parameter is defined by the DID method spec
23:24:31 <Orie> for example: did:sidetree:<unique-portion>;initial-values=<encoded-original-did-document>
23:24:48 <drummond> ...a specific example for the sidetree method is above
23:25:11 <brent> q?
23:25:13 <drummond> ...the use of initialvalues enables a single DID document to be stored rather than two of them
23:25:22 <Orie> I just added a reference to how this is used in sidetree to the issue.
23:25:24 <drummond> manu: that helps. Please add that example to the PR
23:25:43 <manu> I wonder if we should do a matrix param for the specific thing Daniel mentioned.
23:25:47 <drummond> brent: everyone who is interested in this issue, please review, and if you approve, indicate that
23:25:53 <drummond> topic: DID metadata
23:26:01 <dmitriz> q+
23:26:01 <brent> https://github.com/w3c/did-core/issues/65
23:26:31 <drummond> brent: wants to frame the discussion as finding answers to 2 questions:
23:26:39 <markus_sabadello> q+
23:26:40 <drummond> ...1) what is DID document metadata
23:26:46 <brent> ack dmitriz
23:26:52 <drummond> ...2) Where does it go in the DID document?
23:27:18 <manu> q+ to note specific proposal based on what Markus says.
23:27:29 <drummond> dmitriz: proposes a third question: if it does belong in the DID document, how do we represent it?
23:27:39 <drummond> ...does it belong in its own subgraph?
23:27:41 <brent> q?
23:27:46 <brent> ack markus_sabadello
23:27:47 <drummond> ...does it go in its own envelope?
23:28:11 <manu> https://github.com/w3c/did-core/issues/65#issuecomment-558274770
23:28:12 <drummond> markus_sabadello: this is a deep topic, which takes us deep into the RDF discussions
23:28:25 <drummond> ...there is some discussion about DID resolution results, and how to control them
23:28:45 <drummond> ...Markus feels those should be controlled by resolution parameters
23:28:54 <drummond> ...but that is not what we are talking about in this issue
23:28:56 <tplooker> q+
23:29:10 <drummond> ...rather we are talking about metadata about the DID, DID subject, etc.
23:29:34 <drummond> ...second point was that there was conflation of identifiers for the DID subject and the DID document
23:29:53 <drummond> ...and that is important from an RDF and semantic web context
23:30:21 <tplooker> q-
23:30:26 <drummond> ...if the DID is an identifier for the DID subject, then how is the DID document identified?
23:30:41 <drummond> ...for example if a fragment is added to the DID, it resolves inside the DID document
23:30:49 <drummond> ...thus the DID document is a Web resource
23:30:59 <drummond> ... this results in conflation of the DID and DID document
23:31:05 <brent> ack manu
23:31:05 <Zakim> manu, you wanted to note specific proposal based on what Markus says.
23:31:10 <drummond> ...some would call it conflation and some would call it simplification
23:31:27 <drummond> manu: Markus' two examples are very helpful
23:31:27 <manu> Markus provides two examples here -- https://github.com/w3c/did-core/issues/65#issuecomment-558274770
23:31:48 <manu> Analysis of Markus' examples and another example -- https://github.com/w3c/did-core/issues/65#issuecomment-558838589
23:31:48 <drummond> ...Manu followed with his analysis
23:31:56 <tplooker> q+
23:32:06 <drummond> ...if folks haven't read that, we won't get far on this call today
23:32:30 <drummond> ...first point: we have confused everyone by calling it a DID document
23:32:48 <drummond> ...fundamentally it's not an RDF "thing" or not. It's an informational thing.
23:33:07 <drummond> ...the DID identifies a DID subject, and then you can say things about it
23:33:22 <drummond> ...so there is information, and then there is metadata about the information
23:33:23 <drummond> q+
23:33:43 <drummond> ...so he disagrees with Markus that there is conflation
23:33:56 <drummond> ...Manu believes the DID always identifies the DID subject
23:34:01 <tplooker> q-
23:34:24 <drummond> ...thus if we want metadata about the DID information, we need to make it clear
23:34:33 <drummond> ...the three potential approaches are
23:34:50 <drummond> ...1) put the metadata on the outside (this was done with verifiable credentials)
23:34:53 <dmitriz> q+
23:35:05 <drummond> ...2) add a meta field (done for proofs in verifiable credentials)
23:35:13 <drummond> ...Manu thinks that's the wrong approach
23:35:30 <drummond> ...3) put the metadata in the DID resolution result
23:35:40 <drummond> ...Manu believes that's where most of the metadata belongs
23:35:48 <Orie> did resolution aligns with document loader concept in json-ld...
23:35:58 <jonathan_holt> q+ to point out differences in DID methods
23:36:03 <drummond> ...it may sound like this is a fairly simple discussion, but it suffers from definitions
23:36:07 <markus_sabadello> q+
23:36:23 <brent> scribe+ ken
23:36:29 <ken> drummond: I agree this is a challenging subject.
23:36:30 <brent> ack drummond
23:36:41 <manu> +1 to drummond!
23:36:46 <manu> yes, exactly
23:36:46 <brent> +1
23:36:47 <daniel> jonanthan: I addressed your comment on GH Issue 70 just now
23:36:52 <TallTed> DID identifies the entity which we've been calling the DID subject.
23:36:52 <TallTed> Dereferencing the DID gets a description/representation of that entity (the DID subject), which we've been calling the DID document.
23:36:53 <TallTed> Metadata about the description might say when that description was updated.
23:36:53 <TallTed> Metadata about the DID document which conveys that description might say when that *representation* was updated/generated.
23:36:58 <ken> ... Principle 1. The did identifies the did subject. Period.
23:37:31 <ken> Principle 2. I like the term did doc. The way we describe it can be muddy. We need to be clear in the spec.
23:37:39 <manu> q+ to note "who gets to say when a DID was created/updated"?
23:37:47 <ken> ... It is not covered in the community draft.
23:38:01 <brent> q?
23:38:11 <ken> ... From a web standpoint, does it need an identifier or not?
23:38:11 <TallTed> Electronic documents (and their provenance, destiny, etc.) are harder to track than paper documents, but they are no less analogous or important to be describable because of that difficulty.
23:38:14 <manu> I'm agreeing w/ drummond, what he's saying makes sense to me.
23:38:36 <brent> ack dmitriz
23:38:50 <ken> dmitriz: I wanted to clarify what manu was saying.
23:38:55 <drummond> dmitriz: The discussion is very much NOT about metadata about the resolution.
23:38:56 <dmitriz> https://w3c-ccg.github.io/did-resolution/#example
23:39:34 <ken> ... In example 3, we have a separate resolution structure which separates the meta that is about the document and resoltion.
23:39:39 <drummond> ...this example from the DID resolution spec clearly separates the metadata about the resolution process vs. metadata about the DID document that is method-independent
23:40:11 <brent> ack jonathan_holt
23:40:11 <Zakim> jonathan_holt, you wanted to point out differences in DID methods
23:40:15 <ken> ... We keep retreading the argument about whether the datecreated applies to the doc or the did.
23:40:26 <drummond> ...we keep retreading the same ground around questions like the date of the DID document. Some say it should be the ledger, but some ledgers don't keep time
23:40:51 <ken> jonathan_holt: I think that the datecreated is there for convenience. It could be interpolated and self-asserted.
23:40:55 <drummond> jonathan_holt: Some DID methods self-assert the time, whereas others are verifying it via the DID registry
23:41:18 <drummond> ...so in some cases its self-asserted and in some it is interpreted
23:41:30 <brent> q?
23:41:37 <drummond> ...the self-assertion is for convenience, but they can also be verified via resolution
23:41:38 <brent> ack markus_sabadello
23:41:42 <Orie> I'm in favor of not mutating the didDocument type with metadata annotations... mostly because it will create integrity / authentication issues with signed documents...
23:42:16 <drummond> markus_sabadello: Disagrees with Manu and agrees with Dmitri that metadata that describes the DID document belong inside the DID document
23:42:33 <manu> q+ to note that we shouldn't conflate things for convenience sake - it always leads to corrupt data models
23:42:42 <drummond> ...an example is proofs included within the DID document under the BTCR method
23:42:46 <tplooker> Does the metadata conversation need to seperate along the lines of who created of the metadata? E.g metadata created by the ledger vs that is asserted by the entity who updated the did?
23:42:48 <SamSmith> SamSmith has joined #did
23:43:09 <SamSmith> q
23:43:11 <dmitriz> Orie: absolutely agreed. But we're only talking about metadata that comes into existence the moment the DID Document is created. That is, it's metadata that is signed over, it's protected by the signature
23:43:13 <drummond> ...different resolvers may give you different resolution metadata, but the proof metadata should always be the same inside the DID document
23:43:23 <SamSmith> Q
23:43:28 <TallTed> q?
23:43:35 <TallTed> q+ SamSmith
23:43:36 <SamSmith> q?
23:43:41 <manu> q+ to say no we're not saying the id is the same.
23:43:46 <jonathan_holt> tplooker "Turtles all the way down"
23:43:49 <drummond> ...RE the question about whether the DID document has a Web URI, he again points to fragment resolution
23:43:51 <brent> ack manu
23:43:51 <Zakim> manu, you wanted to note "who gets to say when a DID was created/updated"? and to note that we shouldn't conflate things for convenience sake - it always leads to corrupt data
23:43:54 <Zakim> ... models and to say no we're not saying the id is the same.
23:43:58 <drummond> ...but he's in favor of not changing anything
23:44:11 <drummond> manu: URIs are opaque, full stop
23:44:43 <drummond> ...the fact that a DID URl starts with the DID subject identifier has nothing to do with being able to point to info inside the DID document
23:44:58 <drummond> ...the point is that you have an identifier that you can use to point inside a graph of information
23:45:04 <dmitriz> it's more than convenient though…
23:45:08 <markus_sabadello> q+
23:45:11 <dmitriz> has direct implications to security.
23:45:14 <drummond> ...Manu is also hearing argument that "it's convenient"
23:45:39 <dmitriz> q+
23:45:47 <drummond> ...arguments for putting in the metadata are "convenient" for methods that don't have another way to do it
23:46:08 <drummond> ...but Manu believes that there is a cleaner way to add that metadata
23:46:20 <selfissued> q+
23:46:37 <drummond> ...a specific example is "created" or "updated" dates. Do they describe the DID subject or the DID document?
23:46:55 <drummond> ...if the data model is not clear, then implementers will use the same value for different purposes
23:47:32 <TallTed> metadata (DID document modification date) about data (contents of DID document) about entity (DID subject)
23:47:39 <drummond> ...let's not do this. Let's clearly separate statements about the DID subject, and statements about how the DID document was produced
23:47:45 <dmitriz> wait.. but the resolver document /does/ have that information already.
23:47:57 <Orie> +1 to manu's point... messing with the didDocument alters its type... end up getting a type that is part data about subject / part meta data about identifier...
23:48:21 <drummond> ...to put it the other way: anything that puts the metadata on a DID ledger, the DID document author cannot tell the ledger about the metadata; the ledger is authoritative.
23:48:21 <TallTed> q+ to talk some about the layers
23:48:28 <markus_sabadello> +1 to continuing this conversation
23:48:29 <brent> ack SamSmith
23:48:46 <drummond> SamSmith: Having a difficult time with this conversation.
23:48:59 <drummond> ...the original purpose of the DID spec is to convey trust over the Internet
23:49:08 <drummond> ...it's more important than anything else we might do
23:49:28 <drummond> ...so when we start discussing things that make that harder, it confuses us. One step forward, 2 steps back
23:49:44 <manu> yes, but I don't think anyone is saying "don't express `created`" -- we're discussing where `created` should go.
23:49:54 <drummond> ...there are a few things done with DID documents, and those should be very strongly supported cryptographically
23:50:01 <tplooker> q+
23:50:25 <drummond> ...so the test should be can a DID document establish a verifiable root of trust (a "control authority") and everything else should be secondary
23:50:37 <brent> ack markus_sabadello
23:50:42 <drummond> ...if we lose sight of that fact, then we will stray from the main purpose of DID documents
23:50:55 <dmitriz> manu: we're discussing where 3 different 'created' timestamps go. 1) when the did document was created, 2) when it was registered on the ledger/whatever persistence mechanism, and 3) when it was resolved. We already have a data model for expressing 2 & 3. So we're arguing about 1.
23:50:57 <drummond> markus_sabadello: Agrees with what Sam said.
23:51:35 <drummond> ...responding to Manu, although URIs are opaque, but we can't ignore URI rules
23:52:09 <drummond> ...the rules are that to dereference a fragment, you first resolve the primary resource, then you resolve the fragment to a secondary resource
23:52:16 <TallTed> they remain opaque.  the lexical characters that comprise the fragment, as well as the rest of the URI, have no inherent meaning.
23:52:24 <manu> +1 TallTed
23:52:30 <brent> ack dmitriz
23:52:32 <drummond> ...by that logic, if a fragment identifies a secondary resource in a DID document, then the DID document must be the primary resource
23:53:18 <drummond> dmitriz: Believes that Manu is suggesting that resolution metadata be injected into a DID document.
23:53:41 <drummond> ...there are 3 different timestamps involved: 1) creation, 2) registration, 3) resolution
23:54:19 <manu> q+ to say we should define what "created" and "updated" means... because it seems like that definitions is changing.
23:54:20 <drummond> ...we had a place for created-date, but this whole discussion was kicked off by the PR to remove that
23:54:30 <manu> q+ to ask about the use case.
23:54:36 <brent> ack selfissued
23:54:43 <drummond> ...so clarified that we are talking about the creation date of the DID document itself
23:54:53 <drummond> selfissued: Most important is to keep it simple
23:55:12 <drummond> ...the most important thing is to be clear about which properties describe what
23:55:28 <drummond> ...so some claims can describe the subject, but others can describe other things
23:55:35 <SamSmith> The problem is the mental model. Well suited mental models lend themselves to straightforward answers. Poorly suited mental models have convoluted difficult to understand answers. From a cryptographic standpoint 1) We need to establish the current control authority for the DID and DID Doc. 2) Given that control authority we then need to establish if the DID  Doc was provided under the current control authority.
23:55:39 <brent> q?
23:55:44 <brent> ack TallTed
23:55:44 <Zakim> TallTed, you wanted to talk some about the layers
23:55:46 <drummond> ...an example is the "audience" claim in JWT, which describes who the claim is for
23:56:34 <SamSmith> Answering this second question requires linking the DID Document with some identifier for the current control authority. This naturally lends itself to some type of version identifier.
23:56:34 <drummond> TallTed: It's hard to keep it simple because there are a lot of layers here. To keep it precise, we must have some complexity
23:56:50 <drummond> ...prefers the term "Decentralized Identifier" because it's clearer
23:57:08 <drummond> ...the statements that describe the DID subject can go anywhere
23:57:32 <manu> YES, +1000 to TallTed !
23:57:35 <drummond> ...when we dereference the DID, we get back some manifestation of those statements
23:57:43 <drummond> ...we need to be able to say:
23:57:51 <drummond> ...1) they were made at some time
23:58:00 <drummond> ...2) they were posted at some time
23:58:09 <drummond> ...3) they were retreived at some time
23:58:18 <drummond> ...4) they were forwarded at some time
23:58:34 <drummond> ...what would really help is a picture that sketches out the layers and what goes where
23:58:38 <SamSmith> So cryptographically how do we establish that given did doc was created by the current control authority. The easy approach is that its signed non-repudiably by the control authority.  This means that some identifier within the DID Doc is included in the signature in order to make the linkage non-repudiable. Putting that linkage anywhere else is bad crypto.  It doesn't matter whether or not if fits an RDF model. Bad crypto is bad crypto
23:58:51 <brent> q?
23:58:52 <jonathan_holt> q+ to highlight the self-sovereign cryptographic signature that I as the author of the DID data assert the time created and updated, not that it is necessarily convenient.
23:58:59 <brent> ack tplooker
23:59:00 <drummond> ... this might reveal 17 "created-dates", but they can all be precise
23:59:05 <dmitriz> there isn't 17 different created stamps though. There's only 3.
23:59:10 <SamSmith> The complexity is we have a poor mental model of what we are trying to accomplish with a DID Doc.
23:59:31 <selfissued> +1 to what Sam said
23:59:32 <drummond> tplooker: Agrees with Manu that we don't want confusion for implementers.
23:59:54 <drummond> ...agrees with dmitriz that there is utility in certain types of metadata
00:00:05 <dmitriz> +1 to what SamSmith is saying, about a signed non-repudiable 'didDocumentCreated' timestamp, as opposed to 'didDocumentRegisteredOnLedger' timestamp, or 'didDocumentWasRetrievedByResolver' timestamp.
00:00:22 <jonathan_holt> q- given time constraints
00:00:24 <drummond> ...and that there are layers of metadata involved with different parts of the DID document creation, registration, and resolution process
00:00:25 <markus_sabadello> no DID method should allow "created" and "updated" to be written arbitrarily by the DID subject
00:00:32 <SamSmith> Is the data needed inside the DID Doc? If it is it should not be excluded because we can't classify it as not metadata
00:00:40 <drummond> brent: apologies to the rest of the queue as we are out of time
00:00:51 <kimhd> What Mike Jones said really resonated with me, and I hope we can aspirationally get to the state he described
00:00:58 <drummond> ...encourages everyone to continue working in github and to add comments
00:00:59 <Orie> thanks!
00:01:14 <brent> rrsagent, make minutes
00:01:14 <RRSAgent> I have made the request to generate https://www.w3.org/2019/11/26-did-minutes.html brent
00:01:31 <ken> ken has left #did
02:02:28 <gkellogg> gkellogg has joined #did
02:04:00 <Zakim> Zakim has left #did
02:20:04 <gannan> gannan has joined #did
02:23:59 <gkellogg> gkellogg has joined #did
03:32:43 <gannan> gannan has joined #did
03:52:15 <gkellogg> gkellogg has joined #did
04:11:48 <gannan> gannan has joined #did
05:15:45 <gannan> gannan has joined #did
06:23:32 <gannan> gannan has joined #did
07:25:16 <gannan> gannan has joined #did
08:25:22 <gannan> gannan has joined #did
09:33:38 <gannan> gannan has joined #did
10:37:43 <gannan> gannan has joined #did
11:46:36 <gannan> gannan has joined #did
12:49:04 <gannan> gannan has joined #did
13:00:16 <Chunming> Chunming has joined #did
13:05:59 <Chunming> Chunming has joined #did
13:18:52 <Chunming> Chunming has joined #did
13:48:43 <Chunming_> Chunming_ has joined #did
13:58:11 <gannan> gannan has joined #did
13:59:04 <Chunming> Chunming has joined #did
14:05:19 <Chunming> Chunming has joined #did
14:15:05 <Chunming_> Chunming_ has joined #did
14:37:31 <Chunming> Chunming has joined #did
14:42:54 <gkellogg> gkellogg has joined #did
14:43:29 <Chunming> Chunming has joined #did
14:52:29 <dmitriz> dmitriz has joined #did
15:01:06 <Chunming> Chunming has joined #did
15:01:29 <gannan> gannan has joined #did
15:03:39 <ivan> ivan has joined #did
15:22:27 <Chunming> Chunming has joined #did
15:26:11 <gannan> gannan has joined #did
15:57:36 <gannan> gannan has joined #did