14:02:56 <RRSAgent> RRSAgent has joined #did
14:02:57 <RRSAgent> logging to https://www.w3.org/2021/04/13-did-irc
14:03:00 <Zakim> RRSAgent, make logs Public
14:03:00 <Zakim> please title this meeting ("meeting: ..."), ivan
14:03:03 <ivan> Meeting: DID WG Telco
14:03:03 <ivan> Chair: brent
14:03:03 <ivan> Date: 2021-04-13
14:03:03 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Apr/0015.html
14:23:23 <TallTed> TallTed has joined #did
14:26:01 <TallTed> TallTed has changed the topic to: Meeting Agenda 2021-04-13: https://lists.w3.org/Archives/Public/public-did-wg/2021Apr/0015.html
14:48:38 <ivan> ivan has joined #did
14:54:59 <burn> burn has joined #did
14:56:02 <burn> present+
15:00:00 <shigeya> present+
15:00:23 <ivan> present+
15:00:32 <justin_r> justin_r has joined #did
15:00:58 <rhiaro> present+
15:01:03 <ivan> chair: burn
15:01:16 <justin_r> present+
15:01:21 <ivan> present+ dmitriz
15:01:25 <ivan> present+ TallTed
15:01:31 <cel> present+
15:01:36 <ivan> present+ cle
15:01:42 <ivan> preent+ dlongley
15:01:51 <dlongley> present+ dlongley
15:01:52 <ivan> s/cle//
15:02:30 <jonathan_holt> jonathan_holt has joined #did
15:03:06 <ivan> present+ by_caballero
15:03:12 <brent> brent has joined #did
15:03:16 <manu> present+
15:03:17 <ivan> present+ msporny
15:03:26 <brent> present+
15:04:01 <ivan> present+ agropper
15:04:13 <by_caballero__> by_caballero__ has joined #did
15:04:22 <agropper> agropper has joined #did
15:04:29 <drummond> drummond has joined #did
15:04:35 <agropper> present+
15:04:41 <jonathan_holt> present+ jonathan_holt
15:04:50 <rhiaro> scribe+ by_caballero__
15:05:10 <ivan> present+ chriswinc
15:05:12 <chriswinc> present+
15:05:14 <by_caballero__> brent: agenda review
15:05:53 <justin_r> q+ to ask for an addition to the agenda (secevent)
15:05:57 <by_caballero__> LD Contexts in DID Docs & Registry issues, then Issue Review
15:06:04 <brent> ack justin_r
15:06:04 <Zakim> justin_r, you wanted to ask for an addition to the agenda (secevent)
15:06:17 <by_caballero__> justin_r: subject identifier thread on CCG mailing list
15:06:31 <by_caballero__> 5min, added to agenda
15:06:43 <drummond> present+
15:06:51 <brent> scribe+
15:07:05 <ivan> topic: re-introductions
15:07:08 <brent> by_caballero__: currently in california, here representing Spruce
15:07:18 <ivan> topic: special topic call
15:07:35 <by_caballero__> brent: today's topic call, 6pm est, did-test-suite
15:08:04 <ivan> topic: IETF subject identifiers
15:08:29 <JoeAndrieu> JoeAndrieu has joined #did
15:08:32 <by_caballero__> justin_r: context on secevent thread
15:09:10 <drummond> +1 to including DIDs!
15:09:52 <manu> +1 to DID URL
15:10:03 <dlongley> +1 to DID URL as the value
15:10:03 <by_caballero__> big questions are one format or two and names
15:10:19 <brent> +1 to DID URL
15:10:20 <manu> q+
15:10:22 <ivan> +1 DID URL
15:10:27 <brent> ack manu
15:10:36 <by_caballero__> account identifier has type URI; DID could have URI as type, DID could have URL as type, or there could be two formats
15:11:15 <by_caballero__> URI field could be defined as a URI but named " did" or named "uri"
15:11:16 <cel> q+
15:11:19 <cel> https://www.iana.org/assignments/uri-schemes/prov/did
15:11:26 <brent> ack cel
15:11:53 <cel> i am wondering if it is consistent with the uri registration
15:12:05 <cel> or should registration be updated to allow DID URL
15:12:52 <cel> ok, thanks. sorry for audio problem
15:13:03 <ivan> q+
15:13:10 <brent> ack ivan
15:14:43 <by_caballero__> additional context on purpose/goal: identity assurance and auditing across systems
15:14:52 <by_caballero__> also useful to GNAP
15:15:16 <manu> also, thank you to Justin for chasing that down! :)
15:15:24 <ivan> topic: status of at-risk items
15:15:41 <ivan> present+ JoeAndrieu
15:15:43 <justin_r> I'll change the field name to "uri" and send the text off to the editor -- thanks everyone
15:15:58 <by_caballero__> mid april deadline and 15 of may for implementation reports
15:16:03 <by_caballero__> to timeline next CR
15:16:18 <manu> q+
15:16:19 <by_caballero__> brent:
15:16:23 <by_caballero__> manu:
15:16:35 <JoeAndrieu> present+
15:16:39 <burn> s/mid april deadline/end of april deadline for did core tests to be written/
15:16:45 <brent> ack manu
15:17:01 <by_caballero__> manu: screensharing
15:17:10 <by_caballero__> spec as published
15:17:33 <drummond> q+
15:17:39 <by_caballero__> 3.1 feature at risk warning
15:17:47 <brent> https://www.w3.org/TR/did-core/#did-syntax
15:17:49 <brent> ack drummond
15:18:10 <by_caballero__> drummond: the reason this was decided was that well-known method specific value could be used for discovery of did doc
15:18:25 <by_caballero__> so we gave up on any justification for empty value
15:18:32 <brent> subtopic: https://www.w3.org/TR/did-core/#also-known-as
15:18:36 <by_caballero__> manu: so we will drop that feature if nothing happens
15:18:44 <agropper> q+
15:18:59 <drummond> q+
15:19:00 <brent> ack agropper
15:19:04 <dmitriz> uh ohs. did:web definitely intends to implement alsoKnownAs
15:19:08 <by_caballero__> 5.1.3 another feature at risk-- here we need two implementations to keep the feature
15:19:25 <by_caballero__> agropper: i have not been following alsoKnownAs closely, but
15:19:59 <by_caballero__> is it useable for linking two dids? where inn the spec do we recommend a method for provably correlating two dids?
15:20:16 <by_caballero__> manu: there are multiple spots where we talk about
15:20:24 <drummond> q+
15:20:59 <justin_r> PR for Subject Identifiers changeset: https://github.com/richanna/secevent/pull/2
15:21:28 <brent> ack drummond
15:22:06 <by_caballero__> drummond: Indy definitely uses it, so I will reach out to that dev team and see who can help write the impl. stuff and submit to test suite
15:22:16 <by_caballero__> manu: 5.2.1 feature at risk
15:22:18 <cel> q
15:22:21 <brent> at risk feature in this section: https://www.w3.org/TR/did-core/#verification-material
15:22:45 <Orie> Orie has joined #did
15:22:53 <Orie> present+
15:23:01 <by_caballero__> ... publicKeyBase58 & pKMultibase can be allowed in extension but not in spec, we have options open
15:23:05 <ivan> q+
15:23:05 <by_caballero__> q?
15:23:24 <brent> did+ld+json at risk statement here: https://www.w3.org/TR/did-core/#production-0
15:23:27 <brent> ack ivan
15:23:43 <by_caballero__> manu: 6.3.1 another feature at risk - media type registry
15:23:55 <by_caballero__> ivan: we should've done it earlier, now we're stuck waiting on IETF
15:24:22 <by_caballero__> ... if CR get republished, that would be the deadline to get a draft in to IETF
15:24:23 <Orie> can we halt wg activity until the mimetypes are registered properly?
15:24:50 <by_caballero__> ... per process we should've done it at CR time instead of just a comment; if we republish, we should definitely submit official proposal to IETF
15:25:09 <by_caballero__> manu: editors will try to pose the question directly to IETF to speed up the process a little
15:25:18 <by_caballero__> manu: 6.4 CBOR serialization also at risk
15:25:24 <Orie> q+
15:25:25 <brent> at risk statement for CBOR here: https://www.w3.org/TR/did-core/#cbor
15:25:26 <by_caballero__> ... Orie has been working on it
15:25:37 <jonathan_holt> q+
15:25:41 <brent> ack Orie
15:25:45 <by_caballero__> but is not finding 2 implementations of vanilla CBOR
15:25:56 <by_caballero__> Orie: This description does not map to what people are actually implementing
15:26:27 <by_caballero__> ... this normative text is not about DAG-CBOR or CBOR-LD, where the real action is
15:26:58 <by_caballero__> ... we kept this open in case vanilla CBOR implementations were to arise, but we are not seeing support that would justify leaving it in the spec as is
15:27:16 <brent> ack jonathan_holt
15:27:18 <by_caballero__> ... we should make the best-supported representations an integral part of the spec and IMHO remove this
15:27:40 <by_caballero__> jonathan_holt: i disagree; i am back inn the groove of this group
15:28:05 <ivan> q+
15:28:07 <manu> q+
15:28:14 <justin_r> +1 to jonathan_holt 's point
15:28:15 <by_caballero__> ... and have submitted 12000 lines of code, including working with CDDL NODE libraries to make a less JSON-beholden test apparatus
15:28:45 <by_caballero__> ... protocol labs has joined W3C and they will be helping to find/write testable implementations
15:29:05 <Orie> "our test suite"
15:29:09 <by_caballero__> ... hexadec repr of the CBOR and I'm currently working on the "test CBOR" test in the test-suite
15:29:11 <Orie> for which we need PRs
15:29:14 <brent> ack ivan
15:29:46 <by_caballero__> ivan: to be precise, at-risk status and test suite are orthogonal; what determines at-risk status is 2 independent and testable implementations by our deadline
15:30:10 <brent> ack manu
15:30:14 <by_caballero__> ... and CDDL is itself also orthogonal, although i personally support the CDDL work, the test-suite, and the support of this section of the spec
15:30:26 <burn> And will we have that second implementation by mid-May ...
15:30:41 <by_caballero__> manu: to recap, we need two implementations by mid-may, but we have a big agenda...
15:30:58 <by_caballero__> ... and I want to ask if anyone on this call is planning to submit a vanilla CBOR implementation besides jonathan_holt
15:31:06 <by_caballero__> ... outreach would help
15:31:22 <by_caballero__> jonathan_holt: 3Box may be interested, although not a w3c member
15:31:27 <by_caballero__> manu: implementers need not be members!
15:31:31 <drummond> +1 to implementations coming from anywhere
15:31:51 <by_caballero__> manu: moving on, 7 - dereferencing section
15:31:54 <brent> at risk statement on resolution: https://www.w3.org/TR/did-core/#resolution
15:32:12 <by_caballero__> ... oops markus isn't here, but there were, i think, only nits last i chatted with him
15:32:43 <by_caballero__> manu: 7.1.3 - various at-risks in the resolution section
15:32:54 <brent> metadata at risk statements: https://www.w3.org/TR/did-core/#did-document-metadata
15:33:04 <by_caballero__> ... can we get the people on the call working on resolvers to list the sections they plan to support
15:33:34 <Orie> we are
15:33:36 <cel> +1 spruce
15:33:58 <cel> q+ wouldn't these be implemented DID methods
15:34:01 <Orie> correct as of now
15:34:03 <by_caballero__> orie: transmute will submit
15:34:04 <drummond> q+
15:34:07 <by_caballero__> cel: spruce as well
15:34:08 <brent> ack drummond
15:34:15 <by_caballero__> drummond: daniel buchner is not here
15:34:19 <markus_sabadello> markus_sabadello has joined #did
15:34:27 <by_caballero__> ... but canonical is central there, i believe
15:34:30 <cel> q-
15:34:32 <by_caballero__> ... at sidetree i eman
15:34:59 <markus_sabadello> present+
15:34:59 <by_caballero__> manu: nextUdpate nextVersionId
15:35:09 <by_caballero__> ... may not be represented
15:36:11 <by_caballero__> markus_sabadello: i've been working on how to test these fields, but they are often hard to write without deep knowledge of those methods
15:36:20 <by_caballero__> ... i will attend the topic call today to discuss this
15:36:36 <by_caballero__> manu: please attend the topic call if you have input/insight into these features
15:36:38 <markus_sabadello> Some statements in the DID Resolution sections I've had some questions about when writing tests: https://github.com/w3c/did-test-suite/issues/53
15:36:52 <brent> Topic: JSON-LD Contexts in DID Documents
15:37:01 <manu> q+
15:37:07 <brent> ack manu
15:37:29 <Orie> can we merge did test suite PRs?
15:38:13 <by_caballero__> brent: next topic
15:38:21 <by_caballero__> manu: LD context and suites
15:38:51 <by_caballero__> ... (screensharing /test-suite/did-key-2020-db.json)
15:39:01 <by_caballero__> ... the suites have largely been taken out of context
15:39:33 <by_caballero__> ... leaving base context and the more or less explicit requirement that implementers add suites and curves in their contexts
15:39:57 <by_caballero__> ... mix and match, no options taken off the table, just setting a different course for design of dependencies
15:40:11 <Orie> here is an example of a did method specific context
15:40:11 <by_caballero__> ... security contexts could be bundled or composed
15:40:11 <Orie> https://ns.did.ai/transmute/
15:40:21 <markus_sabadello> q+
15:41:00 <dlongley> consuming software that doesn't care about DID methods but does care about crypto suites will prefer the individual crypto suites listed
15:41:11 <brent> ack markus_sabadello
15:41:22 <by_caballero__> markus_sabadello: i want to mention that the DIF ID WG discussed this a bit
15:41:30 <by_caballero__> ... that recording is public, for anyone curious
15:41:41 <by_caballero__> ... there was talk of major breakage and versioning issue
15:41:42 <by_caballero__> s
15:42:18 <Orie> please don't use resolvers to "fix" did documents... its like swallowing an error that should be thrown.
15:42:23 <by_caballero__> ... that said, i fully agree with this change, and this group never promised a static context and I feel this amount of breakage is within reason
15:42:48 <by_caballero__> manu: is anyone concerned about this?
15:43:11 <by_caballero__> ... we need to put the word out that the core context HAS changed and every implementer should check if this affects their work
15:43:17 <markus_sabadello> Agree, Orie, except maybe for a transitional period, or with a warning
15:43:19 <brent> Topic: JSON-LD Contexts in the Registry
15:43:25 <by_caballero__> ... also, we should put the word out about this change in design strategy and guidance
15:43:27 <by_caballero__> brent: next topic
15:43:35 <by_caballero__> .. and back to manu again
15:43:36 <markus_sabadello> DIF call where this was discussed yesterday: https://github.com/decentralized-identity/identifiers-discovery/blob/main/agenda.md#meeting---12-apr-2021---1400-et-recording
15:43:36 <Orie> q+
15:43:43 <brent> ack Orie
15:43:43 <by_caballero__> ... psych, Orie can lead
15:44:04 <by_caballero__> orie: we have had some input about the registry
15:44:57 <by_caballero__> ... one of the PRs suggested removing the explicit CDDL requirement
15:45:04 <ivan> q+
15:45:18 <by_caballero__> ... making it OPTIONAL (i personally still recommend anyone interest in precision use CDDL to specify!)
15:45:36 <by_caballero__> ... but it can create an addition burden on both submitters and reviewers
15:46:10 <manu> q+ to support thinning down the registry.
15:46:44 <brent> ack ivan
15:46:59 <by_caballero__> ... secondly, another PR proposed removing CDDL registry altogether
15:47:17 <by_caballero__> ivan: i would like to reiterate that JSON-LD is NOT a schema language, we should be very explicit
15:47:25 <by_caballero__> ... that a schema language is still needed
15:47:25 <brent> ack manu
15:47:25 <Zakim> manu, you wanted to support thinning down the registry.
15:47:26 <burn> burn has joined #did
15:47:59 <markus_sabadello> q+
15:48:09 <by_caballero__> manu: i want to support CDDL requirement being removed and thinning the registry; removing LD contexts is a bit more tricky
15:48:32 <by_caballero__> ... i think we should collect implementers' contexts and work with them a little
15:48:54 <by_caballero__> ... i.e., submitters could optionally submit a pointer to a context, that we can then automatically process
15:49:20 <by_caballero__> ... so that when we have something like publicKeyHex, we could (automatically) point to which submitted contexts use it
15:49:22 <dlongley> q+
15:49:32 <brent> ack markus_sabadello
15:49:36 <by_caballero__> ... as a non-normative utility/reference
15:49:42 <rhiaro> if we dn't require jsonld contexts we don't get any interop between representations with extensions, do we?
15:49:52 <by_caballero__> markus_sabadello: when we set up the registry, that was one of our requirements: providing an LD context
15:49:57 <Orie> q+ to cover the case for removing jsonld contexts from the registry
15:49:59 <by_caballero__> ... to enable lossless conversion between reps
15:50:34 <by_caballero__> ... and i still think that it is useful
15:50:42 <by_caballero__> ... in ways many people don't realize
15:51:05 <ivan> q+
15:51:05 <by_caballero__> ... for example, we recently had a case where verificationMethods were being defined differently and non-interoperably between otherwise conformant methods
15:51:18 <by_caballero__> ... so having their contexts on hand was very useful in understanding the problem
15:51:45 <brent> ack dlongley
15:51:50 <by_caballero__> ... and each method somehow linked to its corresponding context is useful for detecting and mitigating
15:52:02 <by_caballero__> dlongley: i agree with markus
15:52:13 <drummond> +1 to keeping the requirement for JSON-LD contexts
15:52:16 <brent> ack Orie
15:52:16 <Zakim> Orie, you wanted to cover the case for removing jsonld contexts from the registry
15:52:18 <by_caballero__> ... if we don't link the context in the registry, people will end up having to look for them in the spec for all these reasons
15:52:38 <by_caballero__> orie: i understand this, unfortunately i think this is a problem of the ADM
15:52:51 <markus_sabadello> WG resolution where we agreed on this requirement: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-01-30-did#baseline
15:53:20 <by_caballero__> ... we are having our cake and eating it to if we allow people to not support LD (i.e. throw "rep not supported" error, which is conformant)
15:53:21 <dlongley> q+
15:53:37 <by_caballero__> ... and still ask them to submit an LD context?
15:54:00 <by_caballero__> ... /s / eating it to / eating it too/
15:54:43 <dlongley> q-
15:54:50 <by_caballero__> ... i don't know that cluttering the registry with bad examples of LD helps us produce interoperability
15:55:02 <by_caballero__> ... bad LD contexts going into the registry is more harmful than having no registry
15:55:10 <brent> ack ivan
15:55:28 <by_caballero__> ... and registry does not currently have the resources to adequately analyze and improve LD at time of submission
15:55:35 <by_caballero__> ivan: perhaps a middle ground is possible here
15:55:57 <dlongley> the point of the registry was for properties that are meant to be expressible in the various representations -- which means saying how your registered terms can be expressed (and +1 to what ivan is saying, you need a globally unambiguous ID for your term)
15:56:16 <drummond> q+ to second Ivan's suggestion - I was going to propose the same thing
15:56:22 <brent> ack drummond
15:56:22 <Zakim> drummond, you wanted to second Ivan's suggestion - I was going to propose the same thing
15:56:23 <by_caballero__> ... what if registering a term requires registering a URL, not a URL that points to a context?
15:56:34 <by_caballero__> drummond: +1
15:56:41 <dlongley> you may also want to provide a URL for the value of expected value
15:56:51 <dlongley> s/value of/type of/
15:56:55 <Orie> we clearly don't need JSON-LD unambious terms or we would not have added a representation like did+json that specifically does not use that.
15:57:13 <drummond> +1 to @dlongley's suggestion of the value URI
15:57:36 <by_caballero__> drummond: URI representating value, not type
15:57:44 <by_caballero__> ... pace dlongley
15:57:58 <drummond> To be clear: both URIs - one for the property and one for the value
15:58:01 <by_caballero__> thanks you Ivan who will probably spend a good bit of time fixing my nonsense!
15:58:15 <ivan> rrsagent, draft minutes
15:58:15 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/13-did-minutes.html ivan
15:58:18 <by_caballero__> that makes more sense, drummond!
15:58:19 <by_caballero__> haha
15:58:50 <dlongley> a URI for the *type* of the value, e.g., it's a multibase-encoded string
15:59:04 <ivan> zakim, end meeting
15:59:04 <Zakim> As of this point the attendees have been burn, shigeya, ivan, rhiaro, justin_r, dmitriz, TallTed, cel, cle, dlongley, by_caballero, manu, msporny, brent, agropper, jonathan_holt,
15:59:07 <Zakim> ... chriswinc, drummond, JoeAndrieu, Orie, markus_sabadello
15:59:07 <Zakim> RRSAgent, please draft minutes
15:59:07 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/13-did-minutes.html Zakim
15:59:09 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
15:59:12 <ivan> rrsagent, bye
15:59:12 <RRSAgent> I see no action items