14:56:13 <RRSAgent> RRSAgent has joined #did
14:56:13 <RRSAgent> logging to https://www.w3.org/2020/08/11-did-irc
14:56:15 <Zakim> RRSAgent, make logs Public
14:56:16 <Zakim> please title this meeting ("meeting: ..."), ivan
14:56:21 <ivan> Meeting: DID WG Telco
14:56:21 <ivan> Chair: brent
14:56:21 <ivan> Date: 2020-08-11
14:56:21 <ivan> Agenda: https://www.w3.org/mid/000000000000b4fdcf05ac49aa2b@google.com
14:56:21 <ivan> ivan has changed the topic to: Meeting Agenda 2020-08-11: https://www.w3.org/mid/000000000000b4fdcf05ac49aa2b@google.com
14:56:22 <ivan> Regrets+ dezell
14:56:30 <webauthn> present+
15:00:06 <rhiaro> present+
15:01:01 <drummond> drummond has joined #did
15:01:09 <drummond> present+
15:01:11 <dlongley> present+
15:01:26 <markus_sabadello> markus_sabadello has joined #did
15:01:32 <markus_sabadello> present+
15:02:28 <brent> brent has joined #did
15:02:50 <brent> present+
15:02:52 <jonathan_holt> jonathan_holt has joined #did
15:02:59 <JoeAndrieu> JoeAndrieu has joined #did
15:03:05 <JoeAndrieu> present+
15:03:37 <ivan> present+  dmitri
15:03:38 <manu> present+
15:03:42 <drummond> I can't scribe as I can only stay for the first 30 mins today.
15:03:46 <ivan> present+ selfissued
15:03:59 <ivan> present+ justin
15:04:08 <ivan> present+ jonathan_holt
15:04:29 <agropper> agropper has joined #did
15:04:44 <agropper> present+
15:04:51 <webauthn> scribe+
15:05:34 <manu> present+ justin
15:06:08 <webauthn> brent: Will have a conversation about URL dereferencing
15:06:14 <ivan> present+ wayne
15:06:17 <manu> q+ to note delay on test suite.
15:06:21 <ivan> present+ oliver
15:06:39 <webauthn> manu: Not progressing on the test suite
15:06:43 <webauthn> ... Don't have an ETA
15:06:45 <burn> burn has joined #did
15:06:51 <webauthn> ... Will delay our ability to enter CR
15:06:53 <ivan> present+ burn
15:06:53 <ivan> q+
15:07:01 <ivan> ack manu
15:07:01 <Zakim> manu, you wanted to note delay on test suite.
15:07:03 <oliver> oliver has joined #did
15:07:05 <webauthn> ... Asking for volunteers with development time
15:07:08 <oliver> present+ oliver_terbu
15:07:30 <webauthn> Wayne Chang volunteered to work on the test suite
15:07:45 <webauthn> manu: Was discussed at virtual F2F
15:07:55 <webauthn> ... Can also look at VC test suite for an example
15:08:22 <brent> ack ivan
15:08:28 <wayne> present+
15:08:40 <manu> q+ to note yes, ideally trying to cut down on churn
15:09:08 <brent> ack manu
15:09:08 <Zakim> manu, you wanted to note yes, ideally trying to cut down on churn
15:09:10 <webauthn> ivan: We don't need the whole test suite to go to CR
15:09:34 <webauthn> manu: I'm hoping we can minimize churn in CR by having a mostly-complete test suite
15:10:21 <ivan> Topic: member self-presentation
15:10:49 <webauthn> brent: Sent e-mail asking to reserve space in calendar for next special topic call
15:10:54 <ivan> Topic: next topic call
15:10:57 <webauthn> ... Not clear what the topic will be yet
15:11:10 <ivan> present+ identitywoman
15:11:22 <webauthn> ... Hopefully we'll know what the topic will be by the end of this call
15:11:33 <ivan> Topic: URL dereferencing
15:11:36 <webauthn> brent: Topic URL dereferencing
15:11:54 <dmitriz> dmitriz has joined #did
15:12:08 <manu> webauthn: Is the question, do we understand what it is?
15:12:08 <drummond> +1
15:12:09 <dmitriz> present+
15:12:09 <webauthn> 0
15:12:10 <agropper> I don't understand the question
15:12:11 <ivan> 0
15:12:13 <JoeAndrieu> 0
15:12:17 <agropper> 0
15:12:18 <dlongley> 0
15:12:18 <wayne> -0
15:12:18 <markus_sabadello> +1
15:12:21 <dmitriz> -0
15:12:21 <manu> +1 let's do it! (whatever it is)
15:12:22 <oliver> +1
15:12:22 <jonathan_holt> 0
15:12:49 <agropper> what and why?
15:12:50 <manu> +1 include a section on URL Dereferencing as a formal part of the spec
15:12:57 <drummond> +1
15:12:57 <ivan> +1
15:12:57 <markus_sabadello> +1
15:13:02 <oliver> +1
15:13:07 <dmitriz> -0
15:13:08 <dlongley> 0
15:13:11 <webauthn> brent: Should we include URL dereferencing as part of the spec?
15:13:13 <webauthn> -0
15:13:17 <jonathan_holt> q+ can we clarify that scope 0
15:13:18 <wayne> -0
15:13:20 <JoeAndrieu> -1
15:13:39 <webauthn> brent: We will definitely need to verify the scope
15:13:47 <brent> https://github.com/w3c/did-core/issues/364
15:14:02 <webauthn> ... The purpose of the next block of time is to discuss URL dereferencing
15:14:15 <markus_sabadello> q+
15:14:32 <ivan> +1
15:14:37 <agropper> Use case?
15:14:54 <ivan> q+
15:15:00 <agropper> q+ to ask for a use case
15:15:40 <brent> ack markus_sabadello
15:16:33 <webauthn> markus_sabadello: We have an empty section on dereferencing that we added when we added DID Resolution
15:16:55 <webauthn> ... dereferencing is a key part of the Web architecture
15:17:06 <jonathan_holt> jonathan_holt: just to clarify what is DID URL dereferencing.  My understanding is that we take a DID URL,  chop it up and reattached it to a section in say the service endpoint that is in the DID document to have a full re-concatonated URL with another endpoint that is performed in a deterministic fashion.
15:17:10 <webauthn> ... It is a means of retrieving the URL content
15:17:21 <ivan> present+ pam
15:17:32 <webauthn> ... Do we want abstract functions again?
15:17:47 <webauthn> ... Selecting service endpoints would be out of scope - at least for now
15:18:18 <brent> ack ivan
15:18:32 <webauthn> ivan: +1 for consistency in document issues
15:18:39 <webauthn> ... We do define a DID URL
15:18:47 <webauthn> ... Someone asked for use cases
15:19:05 <webauthn> ... If we do have it, we must say what these are and how they are used
15:19:07 <webauthn> ... One doesn't go without the other
15:19:08 <Orie> Orie has joined #did
15:19:14 <drummond> q+
15:19:18 <brent> ack agropper
15:19:18 <Zakim> agropper, you wanted to ask for a use case
15:19:28 <Orie> present+
15:19:36 <markus_sabadello> q+
15:19:42 <brent> ack drummond
15:20:03 <webauthn> drummond: As soon as you add a fragment to a DID, you have a DID URL
15:20:23 <webauthn> ... You use DID URLs to reference parts of DID documents
15:20:36 <Orie> DID_URL = did:example:123/path/values?query=values#fragment-values
15:20:37 <webauthn> ... There are more complex URLs that can redirect to a service endpoint
15:20:38 <markus_sabadello> q-
15:21:22 <webauthn> agropper: Asked who benefits from DID URL dereferencing
15:21:41 <markus_sabadello> q+
15:22:08 <brent> ack markus_sabadello
15:22:10 <dlongley> q+ to say people may have different opinions based on fragments vs. dereferencing through service s
15:22:37 <webauthn> markus_sabadello: We are already dereferencing DIDs in many cases, for instance VCs
15:22:48 <manu> q+ to speak to not going half way -- going all the way.
15:23:00 <webauthn> ... We resolve the DID to a DID document then use the fragment to select a key
15:23:44 <phila> phila has joined #did
15:23:51 <brent> ack dlongley
15:23:51 <Zakim> dlongley, you wanted to say people may have different opinions based on fragments vs. dereferencing through service s
15:23:55 <ivan> present+ phila
15:24:28 <webauthn> dlongley: People may have different viewpoints on selecting keys versus selecting services
15:24:38 <manu> q+ jandrieu
15:24:39 <manu> q- later
15:24:43 <pam> pam has joined #did
15:25:02 <manu> q-
15:25:02 <brent> ack jandrieu
15:25:04 <manu> q+
15:25:20 <dlongley> s/People may have different viewpoints on selecting keys versus selecting services/People may have different opinions about referencing something that is in the document vs. referencing an external resource via services/
15:25:25 <webauthn> JoeAndrieu: Dereferencing something in the document versus ??? seem very different
15:25:28 <markus_sabadello> q+
15:25:33 <manu> q+ to note that we should define something, but not go crazy.
15:25:49 <brent> ack manu
15:25:49 <Zakim> manu, you wanted to note that we should define something, but not go crazy.
15:25:49 <justin_r> justin_r has joined #did
15:25:58 <dbuc> dbuc has joined #did
15:26:03 <dbuc> present+
15:26:08 <justin_r> present+
15:26:17 <dlongley> Dereferencing can refer to DID URLs that reference something internally to the DID Document -- or to DID URLs that reference an external resource via service query parameters.
15:26:34 <webauthn> manu: We have to put something in to complete this section
15:26:41 <webauthn> ... Otherwise this is a half measure
15:27:01 <webauthn> ... I also agree with Joe and Dave
15:27:14 <webauthn> ... We should have an abstract function defining inputs and output
15:27:22 <webauthn> ... We shouldn't say how this function works internally
15:27:27 <ivan> present+ dbuc
15:27:32 <drummond> q+
15:27:43 <brent> q+ to ask about proposals
15:27:50 <brent> ack markus_sabadello
15:27:50 <pam> present+
15:28:11 <dlongley> -1 to talking about following redirects to external resources (the service query parameters can talk about what URL is referenced and how that works, but without doing deref text), +1 to talking about referencing things within the DID Document
15:28:41 <webauthn> markus_sabadello: The output of dereferencing a DID is a DID document
15:28:55 <webauthn> ... With a fragment, the output can be other things
15:28:55 <ivan> dlongley the way I can translate what you say is that the DID document should define a fragment id only...
15:29:46 <webauthn> ... Noone has spoken strongly against this
15:29:47 <drummond> To save Mike typing, I'll just pre-enter my comment that I'm about to share: specifying in the abstract function how a redirect to a service endpoint is done is an essential part of that function. We don't have to specify the rest of the resolution function, but we do have to specify that much.
15:29:51 <brent> ack drummond
15:30:07 <webauthn> drummond: I totally support specifying the abstract function
15:30:21 <webauthn> ... Saying that anything in the DID document can be referenced
15:30:27 <ivan> s/DID document should/DID Core spec should/
15:30:47 <webauthn> ... Specify the basic transformation to the DID parameters to dereference something outside the DID document
15:30:55 <ivan> q+
15:30:56 <webauthn> ... Interop requires all implementations doing this the same way
15:31:10 <webauthn> ... This is a valuable use of DID URL dereferencing
15:31:18 <markus_sabadello> See DID URL Dereferencing algorithm in the DID Resolutions spec: https://w3c-ccg.github.io/did-resolution/#dereferencing-algorithm
15:31:21 <webauthn> ... (Drummond now has to go to another call)
15:31:25 <brent> q- later
15:31:36 <dlongley> +1 to drummond, if we're going to have "service query params" in the spec, then we should define what they mean and how to interpret them, but do that in this section, and not define all the actual redirection and so on
15:31:47 <dlongley> s/this section/that section/
15:32:02 <identitywoman> identitywoman has joined #did
15:32:24 <identitywoman> present+
15:32:25 <brent> ack ivan
15:32:48 <webauthn> ivan: We could keep it simple and define what the fragment means - and that's all we do
15:32:58 <webauthn> ... This could result in a consistent view of the world
15:32:59 <brent> ack brent
15:32:59 <Zakim> brent, you wanted to ask about proposals
15:33:25 <markus_sabadello> q+
15:33:26 <webauthn> brent: It sounds like if we can come to consensus on a constrained scope for dereferencing
15:33:52 <webauthn> ... that we could also get consensus on having a dereferecing function in the spec
15:34:02 <webauthn> brent: roposed
15:34:10 <markus_sabadello> q-
15:34:15 <ivan> q+
15:34:36 <webauthn> ivan: Trying to understand what you proposed
15:34:39 <brent> ack ivan
15:34:48 <webauthn> ... Should it be limited to properties in the DID document?
15:34:55 <markus_sabadello> q+
15:35:54 <manu> q+
15:35:54 <webauthn> ivan: The fragment should be specified. Everything else should be informal.
15:36:01 <brent> ack markus_sabadello
15:36:09 <webauthn> brent: Everything else would be method specific.
15:36:09 <phila> q+
15:36:27 <webauthn> markus_sabadello: We can't change the DID URL syntax to only allow fragments
15:36:46 <webauthn> ... People are using DID Parameters in the DID URL syntax
15:37:00 <webauthn> ... The dereferencing function would take the DID URL as an input
15:37:13 <webauthn> ... It's not realistic to restrict to just DID+fragment
15:37:40 <webauthn> ... We should define the abstract function to allow non-fragment syntax but only define the semantics for fragments
15:37:51 <manu> q- later
15:37:51 <webauthn> ... The non-fragment parameters could be out of scope
15:38:03 <phila> q-
15:38:16 <webauthn> brent: This is the first of 2 1/2 proposals
15:38:37 <brent> ack manu
15:38:54 <webauthn> manu: I tried to split your proposal into two to get focus
15:39:00 <markus_sabadello> q+
15:39:02 <webauthn> ... I think Ivan agrees with it
15:39:17 <webauthn> ... Could we use the two split proposals?
15:39:28 <webauthn> brent: Your second proposal needs to come first
15:39:53 <brent> ack markus_sabadello
15:40:19 <webauthn> markus_sabadello: I don't agree with the "anything else" clause
15:40:40 <webauthn> brent: It may just be the HTTP dereferencing
15:40:45 <dbuc> *mumbles: we're gonna need a bigger registry*
15:41:00 <brent> PROPOSAL: Define how fragment identifiers are dereferenced within the DID Core specification, anything else is defined elsewhere.
15:41:05 <webauthn> brent: Is there anyone who would recommend specific changes to the proposal?
15:41:06 <manu> +1
15:41:09 <dbuc> +1
15:41:09 <dlongley> +1
15:41:10 <ivan> +1
15:41:11 <Orie> +1
15:41:12 <webauthn> brent: Asked for +1/-1
15:41:12 <markus_sabadello> +1
15:41:13 <JoeAndrieu> +1
15:41:14 <dmitriz> +1
15:41:20 <webauthn> 0
15:41:38 <brent> RESOLVED: Define how fragment identifiers are dereferenced within the DID Core specification, anything else is defined elsewhere.
15:41:53 <brent> PROPOSAL: Define an DID Dereferencing abstract function with inputs and outputs in the specification.
15:42:02 <manu> +1
15:42:02 <ivan> +1
15:42:04 <markus_sabadello> +1
15:42:08 <Orie> +1
15:42:15 <dbuc> +1
15:42:15 <webauthn> brent: Asked for +1/-1 again
15:42:16 <phila> +1
15:42:17 <dlongley> +1
15:42:18 <webauthn> +1
15:42:20 <JoeAndrieu> +1
15:42:29 <brent> RESOLVED: Define an DID Dereferencing abstract function with inputs and outputs in the specification.
15:42:47 <webauthn> brent: That was excellent!
15:42:48 <jonathan_holt> q+
15:42:52 <JoeAndrieu> q+
15:42:56 <brent> ack jonathan_holt
15:43:04 <webauthn> ... Is there anything else on dereferencing that we need to discuss today?
15:43:06 <dbuc> Can we talk about having a registry for params?
15:43:51 <manu> dbuc, the DID Spec Registry already covers DID parameters, IIRC.
15:43:52 <dbuc> ok, then we're set, assuming they are registered there?
15:43:54 <markus_sabadello> q+
15:43:59 <dbuc> q+
15:44:03 <manu> dbuc, yes, you register them there.
15:44:03 <brent> ack JoeAndrieu
15:44:26 <webauthn> JoeAndrieu: I'm still trying to understand the impact of this
15:44:42 <brent> ack markus_sabadello
15:44:42 <webauthn> ... (said something about URLs)
15:44:54 <ivan> q+
15:45:06 <webauthn> markus_sabadello: This means that we would not define service endpoint selection
15:45:13 <dbuc> resolveURL(DID_URL) > resolve doc > apply registered abstract param functions > apply fragment selection, if present > return result
15:45:21 <brent> ack dbuc
15:45:48 <manu> q+
15:45:55 <brent> ack ivan
15:45:56 <webauthn> dbuc: Are those the rough high-level things?
15:46:29 <dbuc> Is this the rough blueprint for the function we're talking about?: resolveURL(DID_URL) > resolve doc > apply registered abstract param functions > apply fragment selection, if present > return result
15:47:10 <webauthn> ivan: We have fragments in DID URLs.  The behavior of them is something we care deeply about.
15:47:34 <markus_sabadello> q+
15:47:38 <webauthn> ... But if the fragment comes after a bunch of other DID parameters, we probably can't say what the fragment means or does
15:47:40 <dbuc> I don't think that's really true, because fragments that don't match an ID in a result simply don't have effect
15:47:41 <brent> ack manu
15:47:46 <dbuc> that's the way the Web handles it today
15:47:56 <webauthn> manu: Daniel and Ivan - you're exactly right
15:47:57 <dbuc> q+
15:48:10 <webauthn> ... We'll have to some dancing in the PR to address this
15:48:27 <markus_sabadello> q-
15:48:28 <webauthn> ... It's not clear what we'll say about the complex cases but we can come up with language for this
15:48:56 <webauthn> ... Does the DID registry support DID parameters? Yes
15:49:07 <brent> ack dbuc
15:49:13 <webauthn> ... That will tell people how to utilize that DID parameters
15:49:14 <manu> q+
15:49:47 <webauthn> dbuc: For parameter presence in the abstract function, do we need normative language in the parameter registration?
15:49:56 <brent> ack manu
15:50:13 <webauthn> manu: It will be difficult for us to have normative language because that presumes that we know what will happen
15:50:29 <webauthn> ... We should be vague for the first few years until a pattern emerges
15:50:39 <markus_sabadello> q+
15:50:54 <brent> q+ to ask what are next steps (and who is going to take them?)
15:50:58 <Orie> dbuc i think your spec for your param is responsible for defining that.
15:50:59 <brent> ack markus_sabadello
15:51:02 <dbuc> ok, makes sense
15:51:12 <webauthn> manu: We don't have a clear idea of the specifics yet
15:51:23 <webauthn> markus_sabadello: We see parameters emerging
15:51:32 <webauthn> ... Some are method-independent
15:51:40 <webauthn> ... Some are method-specific
15:51:41 <dbuc> @orie: I think we have to set some guardrails, because if you don't, we'll see nasty collisions
15:51:47 <webauthn> ... Some are mutually exclusive
15:52:05 <dbuc> like if one param puts out binary, and is eval'd in the middle of 5 different params, it might brick the rest
15:52:10 <Orie> Here is an example of a param spec, that defines such behavior: https://github.com/decentralized-identity/did-spec-extensions/blob/master/parameters/signed-ietf-json-patch.md
15:52:24 <webauthn> ... We already have language about some of this - fragments
15:52:28 <brent> q?
15:52:31 <brent> ack
15:52:35 <dbuc> we should ensure that we are outputting something every param can at least ingest into its own abstract evaluation space
15:52:38 <brent> ack brent
15:52:38 <Zakim> brent, you wanted to ask what are next steps (and who is going to take them?)
15:52:45 <dbuc> that could be as simple as the format of the data
15:52:55 <webauthn> brent: The next steps are for someone to raise a PR
15:53:03 <webauthn> ... Who is going to submit initial text?
15:53:14 <markus_sabadello> q+
15:53:24 <brent> ack markus_sabadello
15:53:24 <webauthn> ... I would prefer that it be someone other than the editors
15:53:44 <webauthn> markus_sabadello: I would also prefer if someone else would do this
15:53:46 <dbuc> like "Your param will be handed JSON, JSON-LD, or CBOR, and must either perform its additional processing or pass through the value to the next param function"
15:53:57 <webauthn> ... There's existing text in PRs related to resolution
15:54:09 <markus_sabadello> https://github.com/w3c/did-core/issues/364
15:54:41 <webauthn> brent: My call for volunteers is still outstanding
15:54:48 <wayne> q+
15:54:57 <brent> ack wayne
15:55:14 <webauthn> wayne: Please restate the scope of the requested work
15:55:36 <dbuc> yeah, I think we should mandate failures are silent and purely success-based outputs, else the original input value is passed forward
15:55:39 <webauthn> brent: Write text specifying inputs and outputs for DID dereferencing
15:55:53 <webauthn> ... There might be text in closed PRs that we can borrow from
15:56:09 <webauthn> wayne: I will do that sometime this week
15:56:11 <dbuc> Basically affect the input data and succeed, or pass without modification
15:56:13 <markus_sabadello> E.g. here is previously proposed text for this section: https://github.com/w3c/did-core/pull/253/files#diff-eacf331f0ffc35d4b482f1d15a887d3bR2693
15:56:42 <webauthn> brent: We have 4 minutes left
15:56:51 <webauthn> ... I feel like we've had an excellent meeting
15:56:52 <JoeAndrieu> +1
15:56:56 <Orie> +1
15:57:02 <ivan> rrsagent, draft minutes
15:57:02 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/11-did-minutes.html ivan
15:57:06 <webauthn> brent: Thank you to Mike for scribing
15:57:23 <webauthn> ... Daniel, show up early next time, because you're #1 on the scribe list
15:57:33 <ivan> zakim, end meeting
15:57:33 <Zakim> As of this point the attendees have been webauthn, rhiaro, drummond, dlongley, markus_sabadello, brent, JoeAndrieu, dmitri, manu, selfissued, justin, jonathan_holt, agropper,
15:57:36 <Zakim> ... wayne, oliver, burn, oliver_terbu, identitywoman, dmitriz, pam, Orie, phila, dbuc, justin_r
15:57:36 <Zakim> RRSAgent, please draft minutes
15:57:36 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/11-did-minutes.html Zakim
15:57:36 <webauthn> ... We will send e-mail about the upcoming DID topic call
15:57:38 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
15:57:40 <manu> +1 thanks brent - we <3 you
15:57:42 <Zakim> Zakim has left #did
15:58:00 <ivan> rrsagent, draft minutes
15:58:00 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/11-did-minutes.html ivan
15:58:35 <ivan> rrsagent, bye
15:58:35 <RRSAgent> I see no action items