15:24:21 RRSAgent has joined #did 15:24:21 logging to https://www.w3.org/2019/11/19-did-irc 15:24:22 rrsagent, set log public 15:24:22 Meeting: DID Working Group Telco 15:24:22 Chair: brent 15:24:22 Date: 2019-11-19 15:24:22 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2019Nov/0031.html 15:24:22 ivan has changed the topic to: Meeting Agenda 2019-11-19: https://lists.w3.org/Archives/Public/public-did-wg/2019Nov/0031.html 15:25:20 chaals has joined #did 15:46:04 ivan_ has joined #did 15:46:14 Chris__MITRE_ has joined #did 15:52:36 brent has joined #did 15:55:04 present+ 15:57:05 present+ 15:57:26 TallTed has joined #did 15:59:37 gannan has joined #did 15:59:54 present+ 16:00:26 present+ 16:00:47 present+ 16:01:44 phila has joined #did 16:01:51 present+ 16:01:57 present+ 16:02:07 present+ 16:02:11 present+ 16:02:51 ken has joined #did 16:02:58 present+ 16:03:17 dmitriz has joined #did 16:03:48 joel has joined #did 16:04:16 scribe+ rhiaro 16:04:40 present+ 16:04:46 burn has joined #did 16:04:50 present+ 16:04:58 present+ 16:05:05 JoeAndrieu has joined #did 16:05:06 present+ 16:05:08 present+ 16:05:13 present+ 16:05:47 brent: outline agenda 16:06:36 ... anyone want anything else on the agenda? 16:06:40 topic: introductions 16:06:52 brent: tom, please tell us who you are 16:07:30 ... tom is getting kicked off the call if no intro 16:07:49 Tom: from USAA 16:07:54 present+ jonathan_holt 16:08:30 topic: face to face social activity 16:08:46 brent: we planned 3 days for the f2f so we could spend half a day doing some 'mandatory fun' (not negative) 16:08:49 sumita has joined #did 16:08:50 oliver has joined #did 16:08:51 ... an opportunity for us to get to know one another 16:08:53 present+ oliver_terbu 16:08:57 present+ 16:09:02 ... such activities can significanly improve the cohesiveness of our group 16:09:12 We do very much want people to attend. Social time with the WG is quite important. 16:09:18 ... is there anyone who would be willing to name themselves as planner of a social activity in amsterdam? 16:09:24 ... best time would be the afternoon of the second day 16:09:29 q+ 16:09:31 Ivan may be able to help with ideas 16:09:38 ack ivan 16:09:53 ivan: it is a bit unfortunate because part of the year i live in amsterdam, but then I will not be 16:10:03 ... one thing I looked up if someone can help is to have a boat tour on the canals of amsterdam 16:10:05 +1 boat tour 16:10:16 on a closed boat 16:10:18 ... it's a very pleasant thing to do, I know where we can get seats on a small boat 16:10:26 ... it's about 20eur/pp 16:10:47 ... I can make a phonecall closer to the time but I cannot be there to check it, i arrive to amsterdam at the same time as the rest of the group 16:10:58 ... mike is not here, maybe some people at microsoft can help for the details 16:11:06 ... that's the only idea I came up with. In January is not the ideal time for amsterdam 16:11:26 brent: anyone in the group willing to take ivan's boat tour idea and run with it or do some other option seeking? 16:11:45 kdenhartog has joined #did 16:11:59 ... the chairs will continue reaching out, this is important 16:12:25 topic: Next key format call 16:12:46 ... a doodle went out 16:13:08 ... It will be Monday Nov 25th 3pm Eastern Time 16:13:21 ... ivan, if you can get us a webex connection for an hour that would be wonderful 16:13:23 ivan: of course 16:13:37 brent: that's an optional call, but official for members, interested in moving that discussion forward 16:13:47 topic: use cases and requirements fpwd note 16:13:58 brent: you all should have recieved an email with a link to the proposed fpwd of this note 16:14:14 -> https://w3c.github.io/did-use-cases/FPWD/2019-11-21/ UCR candidate FPWD 16:14:19 +1 to publish as is... 16:14:24 ... we have five minutes to hopefully discuss whatever we might need to but the goal of this converstation is to end with a resolution to publish unless there are objections 16:14:30 ... queue up if you would like to add anything 16:14:35 +1 to publish 16:14:44 +1 16:14:59 +1 16:15:02 q+ 16:15:20 ivan: before we make a final resolution, a practicality. Two ways of publishing this, we have to decide 16:15:24 ack ivan 16:15:38 ... one is we publish a WD, like we do for a rec, even if it's clearly saying that it's not going to become a rec, then at some point in time we publish it as a note 16:15:43 q+ 16:15:46 ... the other possibility is we publish a note now which we can update whenever we want 16:16:01 q+ to publish NOTE now and then update it. 16:16:04 ... it has a different feel to it if you do one or the other, I'm not saying we should do either one in particular, we have a choice and need a clear decision 16:16:08 ack phila 16:16:15 q- 16:16:22 phila: I would say draft because Joe and I have put lots of places in where we say finished or more to come 16:16:42 ... in particular an area we need to add more content is a section for short use cases. there's a section of more expanded use cases that has been around for a long time, from the CCG 16:16:53 ... but there is a call for more people to provide us with short use cases and without that document is lacking 16:16:59 ... there are open issues that we need to point to it being a draft 16:17:03 ... and content yet to be provided 16:17:03 +0.000001 draft 16:17:06 q+ are we Echidna'ing? 16:17:08 ... I prefer something that says this is a draft 16:17:09 q+ 16:17:12 q+ 16:17:21 ack manu 16:17:30 manu: are we going to use echidna if the proposal is to do a draft? 16:17:39 ack ivan 16:17:44 ivan: personally I defer to the editors on the best way to publish 16:17:59 ... Echidna, yes, as soon as we have the fpwd published, we can't use echidna for the first round. Then we can set it up 16:18:22 yes. A draft was our expectation. 16:18:22 ... if we take the resolution it shoudl also say that editors want to use echidna 16:18:37 brent: typing proposal 16:19:14 JoeAndrieu: we should also figure out the publication date 16:19:17 q+ 16:19:18 ivan: yes 16:19:42 ... we have to submit a request for first public draft, I can do it tomorrow, will take a few days, we could aim for the 26th but it doesn't depend on me 16:19:58 markus_sabadello has joined #did 16:19:59 ... I would say the 28th that's probably very safe. I know it's US thanksgiving but our webmaster is on the island of St Denis not in the US 16:20:23 present+ 16:20:58 JoeAndrieu: that language sent up red flags about, we still need to have the group chime in if it's not editorial 16:21:06 brent: any updates to the draft of the note would come through PRs that get discussed by the group 16:21:36 PROPOSAL: The DID WG will publish the current Use Cases and Requirements document as a FPWD of the Note, with a publication date of November 28, 2019. Subsequent WDs will be published automatically using Echidna as the editors see fit, following standard group discussion of any PRs. 16:21:50 +1 16:21:51 +1 16:21:52 +1 16:21:57 +1 16:21:59 +1 16:21:59 +1 16:21:59 +1 16:22:00 +1 16:22:00 +1 16:22:00 +1 16:22:02 +1 16:22:04 brent: any objections? 16:22:09 +1 16:22:16 +1 16:22:23 RESOLVED: The DID WG will publish the current Use Cases and Requirements document as a FPWD of the Note, with a publication date of November 28, 2019. Subsequent WDs will be published automatically using Echidna as the editors see fit, following standard group discussion of any PRs. 16:22:26 q+ 16:22:35 ack ivan 16:22:39 ack phila 16:22:54 phila: I'm very keen to hear more use cases. they don't need to be long 16:22:57 ... particuarly ones that are not american 16:23:02 ... this group is dominated by the US 16:23:07 ... some are weird american only things 16:23:09 q+ 16:23:16 ... short, brief are good 16:23:22 ack JoeAndrieu 16:23:41 JoeAndrieu: in addition to non-US use cases it would be great to see ones that flesh out some of the requirements that drive some of the technical advocacy 16:23:51 ... we don't have use case coverage for all of the examples brought up in the key conversations 16:23:57 ... the focal ones were written a while ago 16:24:04 ... we don't have coverage on all the things we want to make happen 16:24:19 brent: we definitely have more work to do, appreciate the editors helping us to move forward 16:24:29 topic: DID metadata 16:24:41 https://github.com/w3c/did-core/issues/65 16:24:50 q+ about DID metadata 16:25:05 ack markus_sabadello 16:25:25 q+ to refer to the specific PRs. 16:25:25 markus_sabadello: this issue is about the question of having data in the DID document some of which is about the subject and some of which is about the DID document itself 16:25:33 ... there were ideas to maybe remove some properties like created or updated 16:25:41 ... or proof property. That's where this discussion started 16:25:55 ... we thought created, updated, proof is it about the subject or the DID document itself 16:25:59 ... dmitriz wrote a really good summary 16:26:12 ... The question that we need to agree on is are we okay with data that is sometimes about the subject and sometimes about the document 16:26:15 ... or do we want to separate that somehow 16:26:35 ... I think there's a third category which is data about a the resolution process, some metadata may be added about that in the result 16:26:50 ... but the primary question is are we fine having data about the did subject like services an dpublic keys 16:26:54 ... as well as about the document like proof 16:27:04 ... and if we're not, do the subject and the document have separate identifiers? 16:27:09 ... we spent a lot of time discussing that 16:27:16 q? 16:27:23 ... we felt we are comfortable with combining that, they don't need separate identifiers 16:27:24 q+ to disagree w/ conflating identifiers 16:27:29 ... the same identifier for the subject and the did document 16:27:36 ack manu 16:27:36 manu, you wanted to refer to the specific PRs. and to disagree w/ conflating identifiers 16:27:49 https://github.com/w3c/did-core/pull/27 16:27:51 https://github.com/w3c/did-core/pull/28 16:28:07 manu: I want to point out that we have two PRs pending, 27 and 28, when I put those PRs in there my assumption was that the created and updated were being used to describe metadata about the DID document 16:28:16 q+ 16:28:20 ... but after putting it in I can see how people thought they were about the DID itself, the identifier 16:28:29 chaals has joined #did 16:28:39 ... this is really a metadata discussion, if created and updated are truly about the identifier itself and not metadata about the DID document then it's fine to keep them in there 16:28:54 ... but if is metadata about the DID document I feel strongly we should take it out, we shouldn't be conflating those two things 16:28:56 q+ 16:29:05 ... we need to decide whether or not it's okay to use the same identifier to kind of sort of refer to two different things 16:29:14 +1 to manu 16:29:15 ... that is a huge red flag in the linked data space, yoru semantics get really messy 16:29:23 ... similarly you do not need to have an identifier for everything 16:29:32 ... you can do autogenerated identifiers, that's a common thing, we use it in VCs 16:29:45 ... we could have metadata about the DID document that's outside of the DID document itself, much cleaner separation 16:29:48 The DID document is not the resource. It is an explicit representation of access mechanisms (to use the HTTP URI analogy) 16:29:59 ... if we come to that philosophy it's much easier for us to determine if a particular item is in or outside of the DID document 16:30:13 ack jonathan_holt 16:30:18 ... I thought the original issue was about metadata about the DID document, interested to see if anyone hears differently 16:30:38 jonathan_holt: I thought these were for convenience, and if you wanted to find the original sourc eof truth you spin up a resolver or your own node and verify the assertions being made in the DID document 16:30:50 I'm hearing Jonathan say "issued" and "created" are about the DID Document. 16:30:50 ... my interpretation was they were self asserted related to creation of the DID document, and are there for convenience 16:31:22 ... what markus mentioned for identifiers, the keys ed25519, hiding keys.. was that what you were talking about as far as the subjec tidentifier? you ahve to have a self asserted key identifier in the DID document that's only about its own keys? 16:31:26 ack to mention the notion of truth is in the resolution process. 16:31:32 ... or are we having this concpetual framework of referring to delegate keys or controller keys? 16:31:32 lol 16:31:37 ... what are the semantics we are working with? 16:31:40 q+ to mention the notion of truth is in the resolution process. 16:31:45 q? 16:31:56 s/ack to mention the notion of truth is in the resolution process.// 16:32:01 q+ to ask "about the identifier" or "about the DID Document" being helpful 16:32:01 s/lol// 16:32:13 markus_sabadello: we're not talking about identifiers for keys, we're talking about whether the DID is an identifier for the subject, that's where we ended up after a few months of httpRange-14, or is the DID the identifier for the document, or is it both? 16:32:19 ... I think the community thinks it should be both 16:32:26 ... but understand that's ambiguous from a linked data perspective 16:32:35 jonathan_holt: the subject is the identifier around the DID document, not a human subject? 16:32:45 markus_sabadello: the DID subject is the person, org, thing, whatever, resource, identified by the DID 16:32:51 ack dmitriz 16:33:07 "The DID subject is the subject of the DID." <- Official definition :) 16:33:14 dmitriz: interpretation about created, updated, my summary in issue 65, I was interpreting them to be metadata about the DID document 16:33:28 ... I'm not sure it makes sense to have metadata abut the DID because it doesn't apply separately to the DID document 16:33:34 +1 to dmitriz that created, updated are metadata about the DID document 16:33:39 chaals has joined #did 16:33:39 ... On the issue of does metadata about the document belong there. On which grounds is manu objecting? 16:33:58 ... I laid out several arguments that i've seen you make in the various issues against it, which are relevant and howd o you feel about the counterpoints? 16:34:00 ack JoeAndrieu 16:34:00 JoeAndrieu, you wanted to mention the notion of truth is in the resolution process. 16:34:09 JoeAndrieu: I've flipflopped on this issue 16:34:24 ... one aha for me right now is the definitive way to find out if a given DID document is the correct DID document for a given DID is to execute the resolution process 16:34:27 markus_sabadello, does created not apply to BTCR DIDs where DID documents are generated rather than stored? 16:34:50 ... If that's correct, there's not necessarily a baked in way for a document to demonstrate on its own as a set of bytes that it's the authoritative one, I think whatever metadata you need to verify the process needs to be in the DID document 16:34:56 ... otherwise that separation feels a little false to me 16:34:57 ack manu 16:34:57 manu, you wanted to ask "about the identifier" or "about the DID Document" being helpful 16:35:00 q+ to mention that DID Doc portability, and did methods that do not have ledger etc to provide metadata 16:35:16 manu: there is a certian subset of things I'm strongly objecting to, and that's the conflation of any kind of semantics 16:35:24 ... it's not clear to me what the group things issued, attributed, means yet 16:35:32 ... one thing that might be helpful, there are two categories of information we are talking about 16:35:44 ... information about the identifier itself, the DID string, and whatever it may identify 16:35:50 ... and then information about the DID document itself 16:35:52 q+ 16:35:58 ... those are two distinct categories that i think we should keep distinct 16:35:59 q+ please don't conflate the identifier with the subject 16:36:04 ... if we conflate them there's nasty stuff that can happen 16:36:06 q+ to say an update that adds a key to DID Document really updates the subject 16:36:07 ... that's where my concern comes from 16:36:08 q+ to say please don't conflate the identifier with the subject 16:36:37 agree with what dlongley is on queue to say 16:36:41 ... Let's say that we say that updated is the time the identifier was updated. Semantically that's meaningless. I know the identifier was updated but it doesn't tell me anything more than that 16:36:51 q+ to talk about what a DID document really is 16:37:04 ... whereas if the DID *document* was updated, ther'es a change the resolver can check, that's about the document itself not the identifier. The semantics are very different 16:37:07 q+ 16:37:12 dmitriz: nobody is proposing that it would be about the identifier 16:37:14 manu: i'm not convinced 16:37:26 ... I think some people are and some people arne't, and some people don't understand what conflating those two things does to the entire data model 16:37:27 q? 16:37:53 ... You may not be proposing that and I think other people might be, we need to get down to the definition of what created and updated really means to people, and then see if those definitions are the problem 16:37:57 ack dmitriz 16:37:57 dmitriz, you wanted to mention that DID Doc portability, and did methods that do not have ledger etc to provide metadata 16:38:17 dmitriz: the topic of this issue is does metadata about the document belong in the document 16:38:23 ... that's a separate httpRange-14 discussion 16:38:35 ... nobody is conflating, just discussing whether data about the document belongs in the document 16:38:38 q+ so the did is about the document, not the subject? 16:38:44 "How do we identify the identifier which identifies an entity?" 16:38:45 q+ to ask -- so the did is about the document, not the subject? 16:38:46 ... Having metadata about the DID document in the document allows portability 16:38:59 ... it allows fo rstandardising of that metadata among mutable DID methods that don't have underlying ledger mechanisms 16:38:59 ack markus_sabadello 16:39:21 markus_sabadello: manu is saying sometimes we're talking about metadata about the identifier, I don't think that makes much sense 16:39:28 ... it always identifies something, and the data is about that resource 16:39:37 ... we can't have data about the idnetifier, we can only have data about the thing being identified 16:39:44 ... with data about the subject, data about the DID document 16:40:02 ... I agree it's better to separate them, even though conflating was the outcome of a few months of discussion of httpRange-14, makes more sense to keep separate 16:40:26 ... agree with dmitriz that the metadata about the document inside the DID document is the issue. inside the DID document we need a separate object or level of JSON-LD structure 16:40:37 ... one one level describe the document, on one about the subject 16:40:39 ack dlongley 16:40:39 dlongley, you wanted to say an update that adds a key to DID Document really updates the subject 16:41:00 dlongley: when we're talking about updating or applying an update to a DID document, eg. adding a key, we're really updating the subject 16:41:27 yes, explicitly marking any meta data as such by placing it in a separate subtree in the DID doc would at least make clear that it is different 16:41:27 ... The predicates in a DID document are things like authorisation, which the subject, some aspect of a person or some thing, and when you add a key you say this person authorises this key for some purpose 16:41:31 ... that's the statement you're making 16:41:40 ... if you make that kind of update you're updating information about the subject, not the document 16:41:58 ... these update times that are metadata might actually be information about the subject not the DID document 16:42:13 I agree with dlongley, that's the point I'm attempting to make. 16:42:16 ... dmitri also brought up portability, we're talking about porting information about the subject, not the document 16:42:25 ... the information inside the DID document is about the DID soubject. That's what you'd want to port 16:42:38 ... I think we disagree less than we think because a lot of these things we're talking about are really just more information about the DID subject 16:42:54 ... manu was talkign about the identifier, I think he really meant information about the subject not the DID, we're not changing DIDs, that doesn't make any sense 16:43:07 ack JoeAndrieu 16:43:07 JoeAndrieu, you wanted to say please don't conflate the identifier with the subject 16:43:16 ... a lot of the disagreements go away because we're not talking about metadata tha thappens to live on some registry somewhere, we're talking about the subject 16:43:35 q+ to disagree with dlongley - a large part of the discussion /is/ about metadata about the document itself, the actual record. 16:43:47 JoeAndrieu: manu, you conflated the identifier with the subject. A lot of people have been responding in confusing because of that. I don't think anyone is talking about putting information about the subject in a DID, that would be a privacy antipattern 16:43:55 ... we have a did that's a string, we don't need metadata about that 16:44:10 ... The subject.. the DID document is how you get from the DID to secure interaction with that subject 16:44:25 ... We need to be much more careful about the language we use here, it's confusing us, going to be more confusing for others 16:44:40 ... we have this weird issue of the definitive DID document is not a string of bytes anywhere, it's the output of a resolution process 16:44:51 ack burn 16:44:51 burn, you wanted to talk about what a DID document really is 16:44:52 ... to understand if it's definitive, whatever metadata we use, needs to be part of the DID document 16:45:03 burn: I wanted to bump up a level here 16:45:09 ... the metal model that led to where we are 16:45:15 ... as long as we can keep that mental model we'll be fine 16:45:19 ... what joe said matches what manu said 16:45:31 ... we wanted our use of DIDs as URIs to work similarly to the way other URIs work 16:45:35 ... such as http URIs 16:45:47 ... if you look at the definition that we always refer to of a URI there is a resoultion process and a dereferencing process 16:46:05 ... the resoultion process is where you discover what the access method and operation methods with the resource are, including any kinds of authn approaches that are necessary 16:46:20 ... we're different from http - we put a lot of that information that is part of the resolution process in the DID document 16:46:29 ... we're getting confused by makign the DID document something more magical than it is intended to be 16:46:37 ... which is a representation about how you access and update the resource 16:46:52 ... it's not the access to the resource itself and the things you can do with the resource and how you can authenticate yourself for that 16:46:56 q- later 16:47:07 ... That may help. We may still deicde that there is information that is not about the resource itself but we stil may put it inside the DID document 16:47:23 q+ to say resolution meta-data is a sibling of proofs--they explain why we should believe the rest of the data is authentic 16:47:26 ... joe is correct that conceptually the resource acces smethods all of this exists even for DID methods that do not explicitly store a representation of the DID document 16:47:37 ... the DID document can be generate if necessary, not have to live at a location somewhere 16:47:42 ack ivan 16:47:55 ivan: from a linked data / semantic web point of view 16:48:19 ... with JSON-LD for the did document, that means we define in a particular syntax a bunch of RDF triples and if I can imagine a linked data environment which includes lots of triples, includes the triples in the did document 16:48:45 ... according to the JSON-LD and RDF, there are triples, and all what i see in the DID document, the triple consistes of subject, predicate, object, and the subject is a DID URL 16:48:48 ... that's what happens in RDF 16:48:58 s/and the things you can do with/, it is the things you can do with/ 16:49:02 yep, to Ivan. 16:49:05 ... none of those triples have to say anything about the DID document itself because the DID document is just a collection of triples 16:49:06 exactly, Ivan. 16:49:20 ... if we want to say something about the DID document, we need another subject that identifies it, in order to play properly with the linked data world 16:49:34 q+ 16:49:38 ... if you link it to any other process that wants to use these identifiers, we have to be careful because you will get wrong triples 16:49:43 ... triples that say thigns you don't want 16:49:52 q+ to say we need some examples so it's not as vague in people's heads. 16:49:58 ... and someone may use those triples to deduce things that semweb technologies can deduce, you will get wrong statements, you cannot mix these two up 16:50:04 chaals has joined #did 16:50:06 brent: we have 9 mins left 16:50:09 ack dmitriz 16:50:09 dmitriz, you wanted to disagree with dlongley - a large part of the discussion /is/ about metadata about the document itself, the actual record. 16:50:21 dmitriz: to draw a parallel with the VC data model 16:50:34 ... we had teh same discussion about the created metadata, and there we have two separate sections, subgraphs 16:50:41 ... one about the credential and the other about the credenial subject 16:50:43 ... we label it 16:50:52 ... we standardised the created timestamp for the verifiable credential 16:50:52 +1 to ivan, the DID Document is a graph/dataset with triples about the DID subject in it 16:50:57 ... this is the same thing that's being proposed for the DID document 16:51:00 q? 16:51:04 ... we standardise it for the DID document, not to the person or org 16:51:18 ... if we need to have a separate linked data section so that the triples don't get confused, that's fine, let's talk about that 16:51:24 +1 to dmitriz 16:51:30 ... but I want to re-emphasise th eneed for storing the data about the document not the subject in the document itself 16:51:32 the conversation isn't about triples. it's about quads. about statements about statements. 16:51:46 ... the counter that manu seems to be propoosing is we let each did method standardise their own. That doesn't seem right 16:51:52 ack manu 16:51:52 manu, you wanted to ask -- so the did is about the document, not the subject? and to say we need some examples so it's not as vague in people's heads. 16:52:00 manu: dmitriz that is absolutely not what I'm suggesting 16:52:04 ... I think there's some miscommunication 16:52:07 ... we need some concrete examples 16:52:12 let's take 'created' as a concrete example. 16:52:22 ... The thing that your aised is spot on - in VC we had two subgraphs, oen for the credential, the other for the credential subject 16:52:25 ... this is the exact same thing 16:52:37 ... the issue is that.. what we need is put some concrete examples and ways we coudl address this problem 16:52:41 ... we can use created and issued as examples 16:52:53 ... tha twould help people see how the philosophy applies to an actual concrete solutio 16:53:00 ... we only need two examples, there are two ways we can go 16:53:05 ... that's what we need for the next time we discuss this 16:53:08 +1 to manu, we need specific examples 16:53:12 ... people can see what's being proposed 16:53:12 ack JoeAndrieu 16:53:12 JoeAndrieu, you wanted to say resolution meta-data is a sibling of proofs--they explain why we should believe the rest of the data is authentic 16:53:16 JoeAndrieu: +1 for specific examples 16:53:26 ... The thing si we're not talking about triples, we're talking about quads 16:53:31 I like the examples, too 16:53:40 ... I'm not familiar enough with JSON-LD spaghetti, methods for representing quads 16:53:42 +1 for examples 16:53:50 ... we're talking about the context in which the triples are stated 16:53:51 `{id: , authentication: []}` means "the DID subject (identified by ) has authorized for the purpose of authentication" ... that's a statement about the DID subject 16:53:53 ... we need to make statements about that context 16:54:00 ... we need to be able to in the DID document say something about the DID document 16:54:05 ... metadata about the resolution is part of proof 16:54:18 ... why do we believe this? here' ssome metadata about the process to increase your confidence that this is legitimate 16:54:30 ... What needs to be in there we should figure out at the DID document level, not at the DID resolution level 16:54:33 ack markus_sabadello 16:55:01 markus_sabadello: +1 to keep the triples/quads clean and separate. Strictly speaking we would need a spearate identifier for the DID document 16:55:09 +1 dlongley 16:55:28 you don't need to give the DID Document a separate identifier... can be a blank node... works just fine. 16:55:29 ... the problem with that which we've discussed before for a few months, if we give the DID document a separate identifier we ran into problems defining the deferencing process with URLs, especially if the DID URL has a fragment 16:55:34 q? 16:55:55 ... the way you dereference a fragment is you first deref the primary resource, without the fragment. The result has a mime type and dereferencing the fragment depends on the mime type 16:56:12 +1 to markus_sabadello 16:56:19 ... if it's an identifier for the subject, we can't dereference it because it's a real world resource and doens' thave a mime type 16:56:35 ... I like what dmitri said, paralell with VC, separate sections about the document and the subject 16:56:43 a DID Document itself is much more ephemeral -- you generally don't "talk about it", except perhaps to make statements in a resolution process 16:56:53 brent: we had a recommendation to present real world examples so we can have something more concrete to discuss about 16:56:58 ... The issue, 65 is assigned to markus 16:57:02 {resolution_things... didDocument: {did document things}} 16:57:07 ... markus, comfortable working to arrange some concrete examples? 16:57:19 markus_sabadello: I can come up with some examples 16:57:22 {metadata_about_did_document... didDocument: {did_document_stuff}} 16:57:23 brent: great 16:57:34 ... hopefully we'll have those to refer to next time 16:57:40 yes, dlongley, this is what I meant by giving a DID document more reality than it should have, which is a physical representation of resolution info 16:57:41 ... everyoen continue this conversation in the issue itself and keep moving forward 16:57:42 i think it helps to think of the DID Document as a graph ... for which we generally don't give an identifier 16:57:49 ... I'm going to wrap up the call, thanks everyone for coming 16:57:58 DID document ... is { .ttl owl:sameAs .jsonld owl:sameAs .rdfxml }? Can you speak of one serialization? Or only of all? 16:57:58 It can be important to track when info about a subject was changed, as well as when the subject changed, as well as when the info about the subject was *logged* (which may be different from when it changes)... 16:57:58 VERY complex! 16:58:04 ... Reminder - still looking for someone to host and someone to plan an activity during our f2f in amsterdam 16:58:14 ... Reminder - next week's meeting will be at a different time 16:58:14 https://www.amsterdamcitytours.com/tours/walking-tours/cannabis-tour/ 16:58:23 ... happier for US and Asia pacific, afternoon eastern time 16:58:42 ... 6pm eastern time next week 16:58:51 ken has left #did 16:58:52 ... Fin. 16:59:06 rrsagent, draft minutes 16:59:06 I have made the request to generate https://www.w3.org/2019/11/19-did-minutes.html ivan 16:59:07 zakim, bye 16:59:07 rrsagent, bye 16:59:07 I see no action items 16:59:07 leaving. As of this point the attendees have been brent, ivan_, gannan, manu, dlongley, yancy, phila, rhiaro, ken, joel, TallTed, burn, dmitriz, Chris__MITRE_, JoeAndrieu, 16:59:07 Zakim has left #did 16:59:10 ... jonathan_holt, oliver_terbu, sumita, markus_sabadello