15:35:51 RRSAgent has joined #did 15:35:51 logging to https://www.w3.org/2019/12/10-did-irc 15:35:52 rrsagent, set log public 15:35:52 Meeting: DID Working Group Telco 15:35:52 Chair: brent 15:35:52 Date: 2019-12-10 15:35:52 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2019Dec/0009.html 15:35:52 ivan has changed the topic to: Meeting Agenda 2019-12-10: https://lists.w3.org/Archives/Public/public-did-wg/2019Dec/0009.html 15:35:53 Regrets+ phila 15:52:09 chriswinc has joined #did 15:57:13 markus_sabadello has joined #did 15:58:11 present+ 15:59:06 TallTed has joined #did 15:59:26 present+ 15:59:48 present+ 15:59:49 present+ 16:00:21 Justin_R has joined #did 16:00:27 brent has joined #did 16:00:32 Orie has joined #did 16:00:47 present+ 16:01:00 selfissued has joined #did 16:01:29 present+ 16:01:31 present+ 16:01:39 present+ 16:01:40 present+ 16:01:52 scribe+ 16:02:33 agropper has joined #did 16:02:37 JoeAndrieu has joined #did 16:02:53 present+ 16:02:55 oliver has joined #did 16:03:03 present+ oliver_terbu 16:03:06 brent: Welcome, agenda review. 16:03:10 drummond has joined #did 16:03:15 present+ 16:03:19 present+ 16:03:20 scribe+ 16:03:33 brent: We invite you to join IRC, that's where the official record happens. For side conversations use /me THING_YOU_SAY 16:04:02 brent: q+ if you have something you'd like to add... q+ to THING_YOU_WANT_TO_SAY for reminder. 16:04:22 Irene has joined #did 16:04:22 brent: we're going to start off w/ a PSA on scribing... then F2F activity... time boxed matrix parameter discussion, then created property. 16:04:25 present+ 16:04:29 jonathan_holt has joined #did 16:04:30 present+ 16:04:33 q? 16:04:39 brent: Any additions to agenda? 16:04:44 None, moving on. 16:04:47 Topic: Introductions 16:04:53 brent: Anyone joining the call for the first time? 16:04:53 present+ jonathan_holt 16:04:55 Yes, hello. 16:05:20 regrets+ 16:05:38 present+ Irene 16:05:39 Irene: Hello, Irene, joining on behalf of Jolocom, already a W3C Member, I will be here to soak it all in, wanting to actively contribute, Honor to be here, looking forward to getting to know all of you, based in Berlin. 16:05:58 brent: Anyone else want to introduce themselves? 16:06:02 daniel has joined #did 16:06:17 q+ to note merge for public keys PR. 16:06:32 gannan has joined #did 16:07:12 TallTed: Hi, Ted Thibodeau with OpenLink Software, joined W3C 2001-ish. Since the early days of WebID, we've recognized this is an important piece of distributed computing, happy to be here. 16:07:15 q? 16:07:23 After thinking a lot about the Matrix param discussion last week, and the realization that Matrix params actually make an ID with a param into a new ID, I don't thing they're hardly as useful 16:07:45 Topic: Contributing 16:08:11 brent: There are many ways to contribute to the WG... some contribute via issues, discussion, unique viewpoints, reactions/responses on PRs, all valuable things. 16:08:14 That behavior, adding a matrix param == a new ID, it's just not useful for the vast majority of cases 16:08:25 buchner 16:08:32 brent: One of the easiest and most valuable ways to contribute is to willingly scribe. Some consider it to be a really fun thing... some think it's onerous. 16:09:08 daniel: i do think their utility is much more limited than perhaps some people have thought 16:09:23 So much so I think they should be removed from the spec 16:09:39 so much complexity, for honestly is very little benefit 16:09:50 brent: We encourage everyone to scribe. Yes, some can't, but we do hope that all of you can contribute. Please be fully engaged, if you think that you don't think scribing is important, please look deeply into your heart and reconsider. I encourage all of you to scribe. It is important. 16:09:56 q? 16:10:00 ack manu 16:10:00 manu, you wanted to note merge for public keys PR. 16:10:03 kimhd has joined #did 16:10:14 Orie had a good suggestion yesterday: add some sort of resolver param character to pass resolver only values 16:10:22 topic: public key format 16:10:34 https://github.com/w3c/did-core/pull/100 16:10:34 manu: There's been a long discussion around public key formats, happening in dedicated calls. 16:10:46 like did:foo:123-456$initial-values=34534524 16:11:06 There is an intent to merge it, and Manu believes he's reflected all the input. 16:11:19 present+ 16:11:27 Topic: Face to Face Activity 16:11:32 manu: this is a heads up that there is an intent to merge it, so this is a heads up 16:11:40 @markus_sabadello: Matrix params don't work for the initial-values thing 16:11:40 brent: We have an activity planned for our F2F. 16:11:54 the implied difference in IDs is what nukes it 16:11:54 brent: There is an attendees tab on the spreadsheet, please let us know if you're coming. 16:12:01 brent: The boat tour is second day in the afternoon. 16:12:01 burn has joined #did 16:12:04 present+ 16:12:06 q+ 16:12:14 brent: Having a sponsor will make things simpler, we're looking for a sponsor. 16:12:45 brent: We'd like to avoid figuring out the finances of it. If it doesn't work out, people will just pay for their own tickets. Boat fee is $165 Euro, then $ZZZ per person. 16:12:52 s/ZZZ/20/ 16:13:02 brent: If there are those of you that are willing and able to sponsor, reach out to Chairs. 16:13:04 q? 16:13:06 q- 16:13:22 https://boatamsterdam.com/cruises/premium-cruise/ 16:13:35 present+ 16:13:40 dmitriz has joined #did 16:13:44 present+ 16:13:58 ivan: THere is the URl for the company I found, they gave me these prices, we're talking 90 minutes with small private boat, limit of 22 people... if the group is bigger, then we have to figure out who gets to ride on a boat. 16:14:13 ivan: The $8 EURO extra per person includes a drink. 16:14:26 for $200, I was thinking we'd each get our own keg 16:14:27 ivan: It's January in Amsterdam, probably no sunshine, but there is a closed area on the boat. 16:15:11 Topic: Matrix Parameters 16:15:17 I once made a boat using kegs, so probably 16:15:20 q+ 16:15:22 brent: Time boxed to 15 minutes. One of the Editors is going to guide us through this. 16:15:23 ;) 16:15:30 Topic: Matrix parameters 16:15:37 q? 16:15:40 q+ 16:15:45 Manu, I request that you change RFC4648 to RFC7515 before merging, per my just-submitted review 16:16:00 Link to F2F Agenda Spreadsheet: https://docs.google.com/spreadsheets/d/11haGLiY3AYi8uxIQcfndAixmtXjymNTTFbDQWRYkKrQ/edit#gid=0 16:16:04 q+ 16:16:12 ack markus_sabadello 16:16:50 Matrix parameters: https://github.com/w3c/did-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+matrix 16:16:52 markus_sabadello: This is a syntactical construct that's a part of the spec. There are some matrix params in spec that are PRs that are open, others are in the spec. Since we had the last call, two of those PRs have been closed... key matrix param was closed. 16:17:00 q+ 16:17:04 manu: selfissued, I will change that reference before merging. 16:17:31 Example of their potential use by workday did method, as an id for a VC Schema: did:work:MDP8AsFhHzhwUvGNuYkX7T;id=06e126d1-fa44-4882-a243-1e326fbe21db;version=1.0 16:17:34 markus_sabadello: The other one is to identify resources that are not a DID Document... there are more natural ways of doing that. Discussion is that when matrix parameters should be used and when they shouldn't be used. 16:18:12 Orie: i think that should just be a DID instead 16:18:15 markus_sabadello: Summary - matrix parameters could make sense if you want a separate identifier for a separate resource, when you make it part of a URl, you get a new identifier you want to use as a hyperlink, as a part of a graph, you want to use URLs to identify things... encourage everyone to look at PRs open now. 16:18:40 markus_sabadello: There are discussions about whether matrix parameters are needed at all, if you want to remove matrix parameters, maybe open an issue (because they're in the spec now). 16:19:00 (i.e., just make another DID and the subject is the schema) 16:19:03 markus_sabadello: The CCG made the decision that matrix params were useful. If we want to have a discussion about whether or not we want them, we need to do that in a separate issue. 16:19:14 ack daniel 16:19:21 dlongley: I don't disagree... we had a long debate in Aries around not doing this kind of thing for aries specs, and ended up using https instead... 16:19:31 yup https works too 16:19:35 q+ 16:19:41 daniel: I've spent some time thinking about matrix params... didn't realize that when you add any matrix parameter, you fundamentally change the DID, it's not the same identifier. I can't see how that's useful in the vast majority of use cases. 16:19:42 q+ 16:20:03 daniel: so initial parameters don't help... trying to get some clarity, so if it means DID changes then that's less useful, looking for clarity there. 16:20:35 markus_sabadello: It doesn't change the DID, but it is a new DID URL... DID URL under same authority, what it identifies needs to be specified by matrix parameter. 16:20:52 markus_sabadello: For example, if you use it to identify a service endpoint, you're not talking about the DID subject anymore. 16:21:04 markus_sabadello: if you use version, then you're talking about a DID Document at a specific point in time. 16:21:22 markus_sabadello: For example, when would you make something part of an HTTP URL, or when would you add it as an HTTP Header. 16:21:26 So it sounds possible to make a matrix parameter that identifies the did subject... where the long form, is understood to be the short form. 16:21:40 daniel: If I add a matrix parameter, what happens to original DID? 16:21:57 @orie: so we were mistaken, i assume? 16:22:02 markus_sabadello: You can set a matrix parameter in a way that doesn't identify a different person/thing. 16:22:06 ack selfissued 16:22:09 daniel: not clear at all! 16:22:32 meaning, it is again OK to use them for what we need? 16:22:49 its not clear... 16:22:53 q? 16:22:55 selfissued: I'm enlightened by discussion on matrix parameters last week, this was an invention from 25 years ago that didn't see adoption and wasn't viewed as necessary or useful... yes, I'm raising the question on whether or not we should have matrix parameters. This is a fundamental change with Web architecture and we should go in with eyes wide open. 16:22:57 based on what Markus said, it would seem so 16:23:14 selfissued: We have query parametrs and fragments... before we decide we have to change web addressing, we should think about encoding things in the proper way. 16:23:25 brent: Markus did say that if you want to have that conversation, raise that issue. 16:23:39 q? 16:23:41 q+ 16:23:47 +1 to brent, raise an issue if you want to discuss matrix parameters in general (rather than discussing a specific matrix parameter) 16:24:20 dlongley: I agree with Mike, but I do want thim to know where the conversation started. It started from place of where matrix parameters started, we didn't have a way to construct a URL that didn't impact query parameters and fragments. 16:24:45 q? 16:24:50 ack dlongley 16:24:56 q+ 16:24:57 q- 16:25:27 dlongley: A DID is used to resolve DID to get DID Document. If you have a matrix parameter in it, the only time you want to use a matrix parameter is when you're trying ot refer to something and you can't use anything else... like no query or fragment. refer to external resource relative to DID subject via some content in DID Document, past version, or talking about identifing resource that you go through DID Doc to find endpoint to go to server to find resource. 16:25:35 So are folks on here still fine with adding a regular URL param to the end of a DID? 16:25:52 did:foo:123-456?initial-values=34w5445vw45gv4wv 16:25:57 ^ ? 16:26:02 dlongley: It lets you create a stable URL based on servers moving locations... you want to move the end resource around, so you can port data from server A to server B but keep stable identifier for resource... that was main canonical use case. 16:26:21 +1 to service endpoint use case, -1 to most others. dlongley is correct that service endpoint was the initiating use case for matrix params. 16:26:26 dlongley: That resource may need to have query, hash, and that kind of stuff... those things need to be opaque, which is why we need matrix parameters. 16:26:50 ack drummond 16:27:22 dezell has joined #did 16:27:36 drummond: Wanted to reinforce, having worked on these things, answer to mike's question -- there is a very specific reason we chose matrix parameters and syntax... it was to leave the path, query, and fragment components completely open to developers to use in any way. 16:27:58 Seriously though, I just need to tack some crap on to the end of a DID string to allow a resolver to resolve a DID Doc that has not yet propagated, or the current Doc, if it's after the initial publication 16:28:15 drummond: The use of a service endpoint to compose a result URL and be able to pass it path, query, fragment leaves open only one option to select the endpoint. Something that's a part of the authority component of the URL, which means syntactically separate from DID. 16:28:46 drummond: Yes, it's an old construct, but because we're creating a class of abstract identifier that doesn't exist on the web today, that's why we are discussing. 16:28:51 ack manu 16:28:53 present+ 16:28:55 Point of clarification. We are formally discussing https://github.com/w3c/did-core/issues/137 correct? 16:29:22 manu: responding to @selfissued: Manu does not want to raise an issue to get rid of matrix parameters 16:29:36 late to the party but everything I'm hearing about matrix parameters gives me the gut reaction that these are non-standard and have design stink all over it. The use case of specifying down to a server sounds like "you're doing something wrong" 16:29:40 ...because there is no other way to solve the problem for a set of use cases 16:30:09 ...for example the ones that @dlongley and @drummond have explained, e.g., service endpoint selection or version selection 16:30:10 Current list of PRs about matrix parameters: https://github.com/w3c/did-core/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+matrix+parameter 16:30:34 ack selfissued 16:30:36 brent: We do have an issue about matrix parameters, 137. 16:31:03 selfissued: In the interest of time, let's not discuss here, but would like to have a discussion about query parameters and why we can't use those. 16:31:54 https://github.com/w3c/did-core/pull/28 16:32:04 q+ 16:32:08 @selfissued RE the authority component, we have full rights to add syntax there in the DID URI scheme, but not in query parameters 16:32:16 Topic: meaning of "Created" 16:32:26 https://github.com/w3c/did-core/issues/65 16:32:26 ack manu 16:32:54 manu: wants to try to focus the discussion on what we should talk about in this WG 16:33:13 ...there are 3 aspects. The first one is when the DID document was created an updated. 16:33:37 present+ 16:33:43 ...that topic is being debated in the resolution subgroup that @markus_sabadello is leading 16:33:45 q+ 16:33:53 q+ 16:33:55 q+ 16:34:00 q+ 16:34:03 ...so the other options are: 1) an assertion on the ledger itself about when the DID document was created/issued 16:34:24 there is already a field for 'the ledger is asserting the creation date', separate from 'created' 16:34:24 ...and 2) the DID subject's assertion of when the DID document was created/updated 16:34:31 q+ it's not the subject 16:34:35 so we're only talking about 2 16:34:36 ...manu believes that it is the latter 16:34:38 q+ to say its not the subject 16:34:42 wouldn't it be when the DID subject was created? 16:34:47 ack oliver 16:35:13 ack dmitriz 16:35:17 oliver: We should also consider that some did methods do not have an easy way to assert created/updated time 16:35:42 dmitriz: we are not talking about the update date, because that's a different parameter 16:36:00 ack jonathan_holt 16:36:15 ...so the DID document contains: 1) the DID, 2) DID metadata, 3) resolution metadata 16:36:46 s/update/'ledger is asserting the DID was created'/ 16:37:07 jonathan: For specific DID methods, you must refer to the ledger, so the only option is the author's assertion 16:37:08 ack markus_sabadello 16:37:57 markus_sabadello: Notes that "created" and "updated" correspond to two operations required by a DID method 16:38:23 ack JoeAndrieu 16:38:23 JoeAndrieu, you wanted to say its not the subject 16:38:34 ...so it's okay that the DID document contains the author-asserted timestamps and resolution produces the DID registry-based timestamps 16:38:50 JoeAndrieu: wants to comment on terminology 16:38:59 some did methods are not ledger-based but there are some did methods such as did:ethr that are ledger-based but don't require a ledger to be created. so, no information can be put into the did document for the creation time. 16:39:01 agree with Joe ... a DID document is controlled by a DID controller and says things about the DID subject 16:39:05 q+ to ask what code is going to be written against what the DID controller asserts as the created/updated dates. 16:39:09 ...it's not the "DID subject" that sets the date, it's the "DID controller" 16:39:22 +1 to JoeAndrieu , we should have all said controller instead of subject 16:39:24 q+ 16:39:25 ...wants to make sure we're using the right language 16:39:29 ack manu 16:39:29 manu, you wanted to ask what code is going to be written against what the DID controller asserts as the created/updated dates. 16:39:50 brent: seeing wide agreement that the datestamps in the DID document are asserted by the DID controller 16:39:57 probably even more specific would be the DID controller software 16:40:00 manu: agrees with Joe on terminology 16:40:32 q- 16:40:36 ...so the question is: security issues around using datestamps asserted by the DID controller 16:40:54 q+ 16:41:00 ack dlongley 16:41:00 ...so Manu would like to understand why self-asserted datestamps are important 16:41:29 brent: so this moves us to the topic that if dates are DID-controller-asserted, are they needed? 16:41:50 q+ 16:42:00 dlongley: If the timestamps are in a DID document, they should be authoritative. 16:42:07 +1 to dlongley 16:42:15 +1 to dlongley 16:42:15 ack dmitriz 16:42:17 ...so they should be describing the DID subject, not the DID document 16:42:45 -1 16:42:52 "DID subject `createdDocument` date" would make more sense 16:42:59 but still messy. 16:43:16 dmitriz: the name of the property is ambiguous, so the proposal is to change it to didDocumentCreated and didDocumentUpdated 16:43:19 why? 16:43:31 q? 16:43:34 brent: so the question is now whether this is needed 16:43:40 -1 because some ppl don't create the did document at the `created` time 16:43:47 q+ 16:43:48 what is the use case for knowing when the document was created, by looking at the document? 16:43:50 some did methods don't store the did doc on a ledger 16:43:55 ack jonathan_holt 16:44:03 oliver - I'm not sure I understand 16:44:24 oliver - the timestamp is not about the ledger. it's only about when the document was created (the 'created on the ledger' or whatever is a separate field) 16:44:44 jonathan: asks if PGP keys in the web-of-trust are self-asserted with regard to datestamps? 16:45:00 brent: is anyone a PGP key expert that can weigh in? 16:45:05 I'm not sure anything PGP does regarding embedding meta data like this is good. 16:45:11 ...brent has only been to one PGP key party 16:45:36 q+ is hearing people scrambling for use cases. 16:45:39 q+ to say is hearing people scrambling for use cases. 16:45:42 jonathan: looking at his own PGP keys, he attests to their datestamps, so he wants to get the same info about others 16:45:46 ack manu 16:45:46 manu, you wanted to say is hearing people scrambling for use cases. 16:46:18 manu: PGP does allow you to assert datastamps for keys, but that does not make for good security 16:46:29 +1 to manu, there is no solid use case. 16:46:32 dmitriz - let's have this discussion in a github issue 16:46:46 SamSmith has joined #did 16:46:46 q+ 16:46:48 Seems like added complexity for little benefit 16:46:52 q 16:46:55 q+ 16:47:04 +1 to manu 16:47:04 ...but we are not hearing a solid use case on why we would need "createdDocument" and "updatedDocument" as asserted by the DID controller 16:47:10 ack jonathan_holt 16:47:16 one can make an argument for throwing tons of things in the docs, I think we should be super stingy about it 16:47:45 jonathan: can look at his own keys and the timestamps associated with each 16:47:50 q+ to jonathan_holt -- that's metadata that is useful to you, which is fine, but not useful for anyone else. 16:47:56 q+ to mention redundancy checks and sniff test 16:48:02 ...even though it is self-asserted timestamp, it is still a way of keeping order 16:48:03 why can't you save them with an added stamp post resolution, when you save it to your machine 16:48:09 agree with daniel -- we should be very careful about the data we standardize in DID Document. 16:48:09 q? 16:48:26 agree with daniel/manu so far. 16:48:54 ack SamSmith 16:49:13 SamSmith: from a security perspective, the only way the DID controller can make an authoritative assertion about the DID document is to link it to a hash of the event that existed at that point in time 16:49:28 ...any other ordering can be self-asserted, forged, etc. 16:49:45 ...so that would be the cryptographic way of verifying the authoritative ordering 16:49:47 ack manu 16:49:47 manu, you wanted to jonathan_holt -- that's metadata that is useful to you, which is fine, but not useful for anyone else. 16:49:55 blockheight can determine time ordering? 16:50:09 what is "authoritative" is up to the DID method, but agree we should be using crypto here to extend trust 16:50:18 (when we can) 16:50:27 q? 16:50:35 manu: agrees with Sam. If a createdDocument property is in the DID document, it needs to be cryptographically verifiable 16:50:35 you can always just embed a PGP key in your did document which contains this (and other) meta data. 16:50:49 +1 to Orie 16:51:09 @orie that would only cover the key, not the entire document 16:51:10 I'm totally fine with pushing down the 'documentCreated' metadata field down to method-specific land. 16:51:20 ...the case of just self-assertion of metadata about a DID document for the author can be handled in other ways 16:51:21 +1 to metadata not going in diddoc 16:51:37 ...but all of those ways are outside of a DID document 16:51:43 or use Epoc seconds as your IDs in the values 16:51:55 ...so Manu is not hearing a strong use case for having these properties in a DID document 16:52:01 epoch* 16:52:10 ...and believes we should take them out of the spec until there is a strong use case 16:52:15 ack JoeAndrieu 16:52:15 JoeAndrieu, you wanted to mention redundancy checks and sniff test 16:52:22 if you want to express when you registered a DID with some registry -- you can add that to your DID doc perhaps under a "registration" property with more information about what you registered ... i would think if you have anchored your DID to other blockchains you'd want something like that anyway for more than just one ledger/blockchain 16:52:41 daniel, yes, that would be a fine thing to do... epoch in id itself, and hopefully, asserted by the ledger. 16:52:58 dlongley: there's a separate field for when it was registered, tho 16:53:02 JoeAndrieu: believes that it's too early to call for lack of use cases when the conversation is just getting started 16:53:14 dmitriz: this is about the DID controller saying something 16:53:26 ...there are lots of examples of claims that are not directly tied to the subject 16:53:40 q+ 16:53:48 q+ 16:53:50 ack dlongley 16:53:53 The DID controller saying something is not substrate-authoritative 16:53:56 ...this is the only place where the DID controller can assert these properties for purposes of redundancy and sniff tests 16:54:09 q+ 16:54:17 q+ 16:54:27 SamSmith this is an attempt to formalize inception event 16:54:27 dlongley: so it seems the cases here are entirely around self-assertion, in which case such an "anchor" should have 16:54:36 it's speculative data, not something remotely falsifiable 16:54:41 q+ to Joe's point -- yes, but those are security mechanisms, and we shouldn't depend on non provable mechanisms for redundancy/sniff tests. They can always express that in VC. 16:54:52 ...semantics that make it clear that its self-asserted info from the DID controller 16:54:53 +1 to more specific property 16:54:55 +1 to daniel 16:54:59 @manu: unrelated to current discussion - who can I contact about more infos on the f2f in Amsterdam? 16:55:02 q- 16:55:09 ack Justin_R 16:55:21 Justin_R: the fundamental question is whether the DID document should be internally self-describing 16:55:27 If it's just an assertion by a party external to the trust-minimizing anchoring system, then there's 0 reason we can't make that a separate witness statement outside of the doc 16:55:34 great way to put it, Justin 16:55:37 q+ to Joe's point -- yes, but those are security mechanisms, and we shouldn't depend on non provable mechanisms for redundancy/sniff tests. They can always express that in VC. 16:55:47 ...there are others seeing the DID document will be in a context that has other metadata about it 16:55:53 ack dmitriz 16:55:54 if you want it bound to a doc revision, we could just allow a single prop for witness data that can be included via hash reference 16:55:55 ...so these two views need to be reconciled 16:56:07 dmitriz: agrees with Justin_R 16:56:15 @daniel, it's a statement by the controller, just like everything else in the DID Document. All of which lack falsifiability. 16:56:23 That way you can stuff a freaking DVD worth of witness data in there if you want, just via hash link 16:56:24 ...Dmitri believes that DID documents need to be self-describing 16:56:31 q- 16:56:39 q+ to ask about next steps. 16:56:42 ...but if it is self-asserted, then it can be kicked down to DID method specs 16:56:44 ack jonathan_holt 16:57:11 Can someone argue against the hash-link approach? 16:57:15 (also standalone, yes! has implications on portability / exportability of the DID) 16:57:22 jonathan: conflating the need for a DID registry to add the security around the created or updated timestamp is a different issue 16:57:35 a DID document has information about the DID subject ... if there will be "self-describing" information, then the DID controller should state that the DID subject has a DID Document with properties X, Y, Z. 16:57:44 q+ to propose a concrete way forward - take out of DID spec for now, method specs should define, did:web should blaze the trail, then revisit before CR. 16:57:47 ...but for a DID document to be able to standalone and self-describing is still important 16:58:04 ...there is probably a room for a compromise, where the property is optional 16:58:20 { witness: HASH_OF_N_OTHER_FIELDS/DATA } 16:58:27 ...what jonathan currently does is using Open Timestamps 16:58:32 ack manu 16:58:32 manu, you wanted to ask about next steps. and to propose a concrete way forward - take out of DID spec for now, method specs should define, did:web should blaze the trail, then 16:58:35 ... revisit before CR. 16:58:38 ...so thinks there is room to compromise 16:58:40 +1 to self describing. The DID Controller needs to be able to make authoritative statements in the DID Doc. But I think that it may be method specific 16:58:59 +1 to manu's proposal. 16:59:02 -1 16:59:06 we should remember that the root subject of the DID document is the DID subject 16:59:10 manu: to speak to that compromise, he proposes to take it out of the core DID spec, and let method specs decide about how to use it 16:59:11 +1 16:59:14 +42 16:59:23 daniel - that's + too many :) 16:59:30 ...however there is already dissent, so no action on that proposal yet 16:59:40 so something must say "DID subject has a DID document", and introduce a new object with properties about that DID document. 16:59:43 brent: closes the call with thanks to the scribes 16:59:55 zakim, who is here? 16:59:55 Present: ivan, rhiaro, yancy, chriswinc, brent, manu, Orie, dlongley, selfissued, agropper, oliver_terbu, drummond, JoeAndrieu, markus_sabadello, TallTed, jonathan_holt, Irene, 16:59:56 (so there's no confusion over what the properties apply to DID subject vs. DID doc) 16:59:57 ...remind that we won't hold the call on Dec 25 or 31. 17:00:00 ... kimhd, gannan, burn, dmitriz, dezell, Justin_R 17:00:00 On IRC I see dmitriz, burn, kimhd, gannan, jonathan_holt, Irene, drummond, oliver, JoeAndrieu, agropper, selfissued, Orie, brent, Justin_R, TallTed, chriswinc, RRSAgent, Zakim, 17:00:00 ... chaals, ivan, tzviya, dlehn, dlongley, manu, deiu, yancy, ChristopherA, Travis, jfishback, bigbluehat, hadleybeeman, rhiaro 17:01:19 rrsagent, draft minutes 17:01:19 I have made the request to generate https://www.w3.org/2019/12/10-did-minutes.html manu 17:01:24 present+ kimhd, SamSmith, yancy 17:01:49 rrsagent, draft minutes 17:01:49 I have made the request to generate https://www.w3.org/2019/12/10-did-minutes.html ivan 17:01:49 zakim, bye 17:01:49 rrsagent, bye 17:01:49 I see no action items 17:01:50 leaving. As of this point the attendees have been ivan, rhiaro, yancy, chriswinc, brent, manu, Orie, dlongley, selfissued, agropper, oliver_terbu, drummond, JoeAndrieu, 17:01:50 Zakim has left #did