14:14:02 <RRSAgent> RRSAgent has joined #did
14:14:02 <RRSAgent> logging to https://www.w3.org/2021/05/18-did-irc
14:14:04 <Zakim> RRSAgent, make logs Public
14:14:06 <Zakim> please title this meeting ("meeting: ..."), ivan
14:14:10 <ivan> Meeting: DID WG Telco
14:14:10 <ivan> Chair: burn
14:14:10 <ivan> Date: 2021-05-18
14:14:10 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021May/0013.html
14:14:10 <ivan> ivan has changed the topic to: Meeting Agenda 2021-05-18: https://lists.w3.org/Archives/Public/public-did-wg/2021May/0013.html
14:35:07 <dmitriz> dmitriz has joined #did
14:46:15 <burn> burn has joined #did
14:52:39 <burn> present+
14:56:59 <cel> regrets+
14:59:47 <ivan> present+
14:59:59 <ivan> present+ shigeya
15:01:06 <justin_r> justin_r has joined #did
15:01:19 <justin_r> present+
15:01:23 <ivan> present+ markus
15:01:28 <chriswinc> chriswinc has joined #did
15:01:29 <ivan> present+ manu
15:01:33 <Geun-Hyung> Geun-Hyung has joined #did
15:01:42 <Geun-Hyung> Present+
15:01:44 <chriswinc> present+
15:01:59 <ivan> present+ dmitriz
15:02:41 <burn> Topic: Agenda Review, Introductions, Re-introductions
15:03:11 <dmitriz> burn: we're gonna talk about the Special Call, Brent will mention our communication with ITU, then status of implementations
15:03:13 <markus_sabadello> markus_sabadello has joined #did
15:03:19 <markus_sabadello> present+
15:03:25 <dmitriz> ... then registries, then DID Core issues & PRs
15:03:35 <dmitriz> scribe+
15:03:37 <rhiaro> present+
15:03:40 <agropper> agropper has joined #did
15:03:58 <agropper> present+
15:04:09 <dmitriz> burn: any requests for changes/additions to the Agenda?
15:04:10 <burn> Topic: No Special Topic Call
15:04:35 <dmitriz> burn: summary - no special topic call this week. We're going to be switching to some other work, but at the moment, no particular items
15:04:41 <dmitriz> ... what we need is for people to get their implementations in
15:04:52 <dmitriz> ... so, in case you missed it - no special topic call this week.
15:04:53 <burn> Topic: ITU and DID
15:05:10 <dmitriz> ... Ivan, can you give us a summary?
15:05:25 <dmitriz> ivan: so, we've got contacted by the ITU Working Group
15:05:36 <dmitriz> ... they collect references to a number of identity-related standards all over the world
15:05:39 <TallTed> TallTed has joined #did
15:05:45 <dmitriz> ... not only formal standards, but also other various groups like FIDO
15:05:55 <dmitriz> ... Brent was invited to go to one of their calls
15:06:08 <dmitriz> ... to give a presentation about DIDs, which he did, brialliantly
15:06:37 <dmitriz> ... and now they have contacted us. If we understand their request -- if we would be ok with them listing the DID spec on their list of identity standards
15:06:49 <brent> brent has joined #did
15:06:55 <dmitriz> ... the only thing they need is a 1-2 paragraph description (of what this group does, wants to do)
15:06:55 <brent> present+
15:07:04 <markus_sabadello> q+
15:07:13 <dmitriz> ... and of course reference to the standard. And an authorization/blessing from us to include our spec on the list.
15:07:20 <drummond> drummond has joined #did
15:07:26 <drummond> present+
15:07:32 <dmitriz> ... I think the right time to do that would be in a few weeks or months, when we begin to discuss the future of this WG
15:07:47 <dmitriz> ... what's our longer-term plan for spec maintenance, etc.
15:07:53 <dmitriz> ... Brent - anything I'm missing?
15:08:03 <dmitriz> brent: no, +1 to what you said
15:08:18 <dmitriz> ... it was fascinating how much they already knew about DIDs, and are planning to use the tech (and encourage their members)
15:08:23 <dmitriz> ... (which are telcos)
15:08:35 <dmitriz> ... so, I encourage us to look at this positively.
15:08:45 <burn> ack markus_sabadello
15:09:10 <dmitriz> markus_sabadello: personally, I think it would be great if they reference our work. one question - if I remember correctly, we were contacted about a year ago, by ITU Study Group 17 (?)
15:09:27 <dmitriz> ... which was about security aspects for distributed ledger tech. (and they asked for a liaison?). Was that the same group?
15:09:34 <dmitriz> ivan: I don't remember.
15:09:43 <dmitriz> brent: 17 is the Study Group for Identity management
15:09:56 <dmitriz> ivan: ah ok, so.. seems like the same group, but not exclusively about ledgers
15:10:12 <dmitriz> burn: Ivan, do we need a decision by the group? Or just, hear if there are any objections?
15:10:19 <dmitriz> ivan: let's do a resolution
15:10:38 <dmitriz> burn: ok, I'll put a draft proposal.
15:10:59 <TallTed> Question back to them about whether this will be a static list, once published, or we can be listed later?
15:11:07 <TallTed> q+
15:11:20 <burn> ack TallTed
15:11:36 <dmitriz> tallted: is this something they'll publish in stone at the end of the week? Or something that can be listed in later? (once we're done)
15:11:42 <drummond> Do we really need to approve someone else referencing our specs?
15:11:43 <dmitriz> ... so that it can just be part of the PR when we publish
15:11:59 <manu> btw, SG17 is their Security Study Group -- https://www.itu.int/en/ITU-T/studygroups/2017-2020/17/Pages/default.aspx
15:12:22 <dmitriz> ivan: good question. My proposal is - let's tell them we'll give them information about our longer-term plans; it'll be a combination of a reference to the current WG, plus an idea of the longer term plans
15:12:31 <dmitriz> ... so, we can send them something in 1-1.5 months
15:12:33 <manu> ... and here's what they're publishing: https://www.itu.int/md/T17-SG17-R
15:12:43 <dmitriz> brent: that sounds like half-agreement with what Ted said?
15:12:44 <dmitriz> ivan: yeah
15:13:06 <drummond> q+
15:13:14 <burn> ack drummond
15:13:28 <dmitriz> drummond: do we really have to approve someone else referencing our spec?
15:13:44 <dmitriz> ivan: that was my question too. our legal advisory ppl said - institutions like ITU are 10x as cautious about this kind of thing; they always ask for authorization
15:13:52 <TallTed> I think we should also use W3 labels for these things -- e.g., not "specification", but CR (or PR or TR)
15:13:56 <dmitriz> drummond: sure, but like.. that's the whole point of a public spec :)
15:14:17 <dmitriz> burn: how about - instead of 1-2 months, we can just say "when the spec is complete"
15:14:41 <drummond> Looks good
15:14:51 <dmitriz> tallted: we should use W3 labels for the specs. (CR/TR etc)
15:15:43 <manu> q+ to suggest TR
15:15:59 <ivan> q+
15:16:02 <manu> q-
15:16:23 <drummond> looks good
15:16:33 <burn> PROPOSED: We approve ITU SG 17 referencing our DID Core Technical Report in their report on identity standards when it is completed.
15:16:35 <TallTed> +1
15:16:37 <burn> +1
15:16:37 <ivan> +1
15:16:38 <dmitriz> +1
15:16:40 <manu> +1
15:16:41 <chriswinc> +1
15:16:42 <shigeya> +1
15:16:42 <rhiaro> +1
15:16:45 <markus_sabadello> +1
15:16:48 <brent> +1
15:16:49 <drummond> +1
15:16:54 <Geun-Hyung> +1
15:16:59 <burn> RESOLVED: We approve ITU SG 17 referencing our DID Core Technical Report in their report on identity standards when it is completed.
15:17:18 <dmitriz> brent: drummond, that was my first question too, re approval :) (but, these large orgs seem to like that)
15:17:19 <dmitriz> drummond: yep, got it
15:17:26 <burn> Topic: Status of Implementation Feedback
15:17:32 <manu> q+
15:17:34 <dmitriz> burn: how are we doing on implementations?
15:17:36 <burn> ack ivan
15:17:38 <burn> ack manu
15:17:43 <dmitriz> manu: (sharing screen)
15:17:48 <ivan> q-
15:18:03 <dmitriz> manu: ok, implementations! we have a ton of them in, which is great
15:18:14 <dmitriz> ... we have a ton of Resolver implementations. (unfortunately, it's all the Universal Resolver :) )
15:18:17 <dmitriz> ... but still, that's great
15:18:24 <dmitriz> ... we have 3Box and Consensys resolvers, as well
15:18:30 <dmitriz> ... only one de-referencer still. (so, problematic)
15:18:36 <dmitriz> ... and a number of DID Method submissions.
15:18:43 <dmitriz> ... now, this is only after a week, so, that's still good.
15:18:54 <dmitriz> ... and we have another week to take implementation reports, to determine whether we have enough to exit CR
15:19:06 <dmitriz> ... for us to know that, we need to generate a report (that tells us if there's at least 2 independent impls, for each feature)
15:19:18 <dmitriz> ... there's upwards of a 150 normative statements
15:19:35 <dmitriz> ... we needed an automated way to do that. Shigeya started on an automatic report generator (in this PR), made great progress
15:19:44 <dmitriz> ... here's a preview of the Test Suite report
15:19:47 <shigeya> actually, just finished working on it (besides matrix)
15:19:49 <dmitriz> ... organized by sub-suites
15:20:08 <dmitriz> ... layout is - here's the normative statement being tested, then every single DID Method & thing that conforms to it
15:20:16 <dmitriz> ... we don't have anything checked in that is failing yet.
15:20:27 <ivan> q+
15:20:38 <dmitriz> ... the idea is, we're going to go down through the report, and look for things that only have one implementation.
15:20:42 <dmitriz> ... for example - JSON Production
15:20:59 <dmitriz> ... for that, we don't have anything, other than an example, generating a Number, a Null Value, a Double, that sort of thing
15:21:23 <dmitriz> ... we may choose to overlook this, because - it may be obvious to the WG, that clearly we want to support integers in the data model, etc.
15:21:29 <dmitriz> ... but it's just an example of implementation
15:21:34 <shigeya> https://github.com/w3c/did-test-suite/pull/105
15:21:37 <manu> https://pr-preview.s3.amazonaws.com/shigeya/did-test-suite/pull/105.html#conformance-by-test-suites-3
15:21:57 <dmitriz> manu: so, basically, thanks a ton to Shigeya for fixing this mechanism
15:22:08 <dmitriz> ... there's a couple more things we need to add to it that are being tracked
15:22:17 <dmitriz> ... shigeya, would you like to add anything?
15:22:25 <dmitriz> shigeya: basically, I just funished
15:22:35 <dmitriz> ... and it statically generates the HTML
15:22:53 <dmitriz> ... I still need to do/figure out - how to create an NxN matrix
15:23:04 <dmitriz> ... we have several test suites here, but it doesn't match to the section number, for example
15:23:40 <dmitriz> ... I've seen the VC test suite using the matrix structure, for the tests
15:23:51 <manu> q+
15:24:02 <burn> ack ivan
15:24:02 <dmitriz> ... I'm not sure how to structure this - thoughts from the WG?
15:24:48 <TallTed> is it possible to have each test linked, within, e.g., https://pr-preview.s3.amazonaws.com/shigeya/did-test-suite/pull/105.html#conformance-by-test-suites-1
15:25:07 <shigeya> q+
15:25:09 <dmitriz> ivan: (question about the right column, the Parameters). whether this will be a useful info to the W3C Director
15:25:25 <dmitriz> ivan: also, there has to be some sort of back-link to what these implementations are
15:25:46 <dmitriz> ... just some metadata on implementations, so one can see that easily
15:26:04 <dmitriz> ... for the matrix, what I would expect to see is a big table which says "these are the tests, and you can categorize that, one per row"
15:26:12 <dmitriz> ... and for each row, every implementation that does implement that item
15:26:21 <dmitriz> ... I realize that I don't know how many implementations we'll have in that list
15:26:23 <burn> ack manu
15:26:51 <dmitriz> manu: couple of things. first, this report won't be too useful to the Director; this is just for our reference
15:27:03 <TallTed> +1 to ivan's question about need to include parameters column ... tho I now see it containing media types (and 2 such for 1 implementation)
15:27:03 <dmitriz> ... shigeya - I don't think we should do a full table/matrix, will be too large
15:27:17 <burn> q+
15:27:18 <dmitriz> ... what the Director is more likely to want to see is - which features DIDN'T make it
15:27:49 <dmitriz> ... so, being able to generate that programmatically (the features that didn't make it) - that would be super useful
15:28:05 <dmitriz> ... and then if you really wanted to dig down into the details, you can view the full implementation tables
15:28:26 <dmitriz> ... also, this is still very much experimental; some of the output requires explanation. A lot of this has to do with the complexity of the spec
15:28:39 <dmitriz> ... since we're testing all kinds of things - syntax, data model, resolution, dereferencing, metadata structs, etc
15:28:44 <shigeya> 47 test inputs (files in implementation directory). 32 of them are universal resolver based test
15:28:51 <dmitriz> ... and that just results in a very complex report
15:28:52 <shigeya> (some of them are examples)
15:29:07 <TallTed> summary of summary table good; huge summary table and ability to drill down to per-implementtion and/or per-tested-fature details also good
15:29:18 <dmitriz> ... shigeya - so, don't work on a 2d matrix. ivan - what we need to show the Director specifically, is the list of features that didn't cut it. (and, obv, that list should be 0 items long :) )
15:29:50 <rhiaro> scribe+
15:29:51 <burn> ack shigeya
15:29:52 <ivan> q+
15:30:18 <shigeya> q-
15:30:20 <burn> ack burn
15:30:50 <manu> q+ to note I only think we're missing one thing -- a list of things that don't have sufficient implementation experience -- that list will be non-zero for JSON
15:30:57 <rhiaro> burn: what I've been through in director meetings - you're right manu, whatever the categories are that we are testing for which we say we need at least two implementations we need to be able to clearly summarize at the top the number of features we don't have sufficient implementations
15:31:03 <rhiaro> ... it's also helpful to say what we do have sufficient for
15:31:07 <rhiaro> ... and to click in to see details
15:31:21 <rhiaro> ... and should be easy to tell visually which don't have enough, eg. bright red title
15:31:25 <rhiaro> ... so it's easy to skim
15:31:45 <rhiaro> ... one of the reasons it's good to have the link to sufficient implementations is because another important check for the director (sometimes, depending on things) is to see how independant they are
15:32:06 <rhiaro> ... this example is a great example because it looks like everythingis great but when you click on the list of implementations and you see 'example examlpe example' that could be a red flag
15:32:17 <burn> q?
15:32:18 <rhiaro> ... yes, summary at the top sayinghow many featurs have at least two, how many don't, but a click to get to details
15:32:20 <burn> ack ian
15:32:21 <burn> ack ivan
15:32:22 <rhiaro> ivan: agree
15:32:30 <rhiaro> ... only a minor thing, more psychological than anything
15:32:35 <rhiaro> ... we will have 30-40 implementations
15:32:43 <rhiaro> ... it might be more impressive to give the number of positive implementations
15:32:46 <rhiaro> ... not only to say yes we are over 2 or not
15:32:49 <rhiaro> ... but give the number
15:32:54 <burn> ack manu
15:32:54 <Zakim> manu, you wanted to note I only think we're missing one thing -- a list of things that don't have sufficient implementation experience -- that list will be non-zero for JSON
15:33:03 <rhiaro> manu: we're converging
15:33:08 <rhiaro> ... with optional things that might be helpful
15:33:24 <rhiaro> ... we're only really missing one thing in the report - that is a breakdown of here are all of the features that don't have more than implementation
15:33:27 <rhiaro> ... or have 0 or 1
15:33:33 <rhiaro> ... and then links to take you to those detail sections
15:33:42 <rhiaro> ... and another section that says here are all the features that have mor ethan two indepant implementations
15:33:46 <rhiaro> ... here are the number of implementations
15:33:51 <TallTed> 37 uses of "universal resolver" are not 37 implementations ... and it seems like there isn't another resolver?  that's a pretty big gap.
15:33:53 <rhiaro> ... and here's a link to that section if you want to look in more detail
15:34:03 <rhiaro> ... the expectation si the director will look at those two things first and if they have questions will drill down
15:34:09 <rhiaro> ... we will have things in each list
15:34:18 <rhiaro> ... I don't think anyone is going to submit a json implementation that has a null value
15:34:21 <rhiaro> ... as the right hand side value
15:34:25 <rhiaro> ... i don't think anyone has a use case for that yet
15:34:33 <rhiaro> ... so we'll be able to prove both lists are being generated properly
15:34:36 <burn> q?
15:34:42 <rhiaro> ... did I say anything that didn't agree?
15:34:45 <burn> q+
15:34:47 <TallTed> q+
15:34:48 <burn> ack burn
15:34:49 <rhiaro> ivan: it's fine
15:35:20 <rhiaro> burn: additional comment - when you get to that last step, you first have the summary, then click to see how many implemented, then to that list and I like the idea per feature that has a summary, what the blue bars are
15:35:24 <rhiaro> ... it has a feature with a count
15:35:35 <rhiaro> ... but when you go to see details of the implementations I'd prefer a link to the individual implementation report
15:35:37 <rhiaro> ... that contianed that
15:35:52 <rhiaro> ... and the reason is because it can be helpful when you click to that to see the implementer implemented one feature and nothing else
15:35:58 <rhiaro> ... to see the full report for somebody is sometimes helpful and interesting
15:35:59 <burn> q?
15:36:02 <burn> ack TallTed
15:36:06 <rhiaro> TallTed: echoing that
15:36:12 <rhiaro> ... being able to drill down on either access to any given point
15:36:17 <rhiaro> ... per implementation, but also per feature
15:36:20 <rhiaro> ... see who implemented it
15:36:25 <manu> q+ to note that "fancy" and "nice to have" -- shigeya is very graciously doing the work, I don't want to overload him.
15:36:33 <rhiaro> ... if the blue bars included a count of... just count successes, no failures? failures wouldnt be in the table?
15:36:35 <rhiaro> manu: they would
15:36:42 <rhiaro> TallTed: the bars could summarise one success out of 37 testers that would be useful
15:36:58 <rhiaro> ... I'm concerned in the early comments you said there were a bunch of resolver implementations which aren't independant
15:37:01 <rhiaro> ... they're a bunch of uses of the thing
15:37:04 <rhiaro> ... that looks like a big gap
15:37:06 <rhiaro> manu: correct
15:37:07 <burn> ack manu
15:37:07 <Zakim> manu, you wanted to note that "fancy" and "nice to have" -- shigeya is very graciously doing the work, I don't want to overload him.
15:37:08 <shigeya> agreed.
15:37:11 <justin_r> +1 to the gap
15:37:20 <rhiaro> manu: I ack Dan that would be nice to have
15:37:22 <burn> I don't want to overload Shigeya either
15:37:32 <rhiaro> ... Shigeya has done a ton of work and I want to be respectful and not overload him
15:37:38 <rhiaro> ... want ot make sure we get to the minimum possible, then it's up to Shigeya
15:37:45 <shigeya> q+
15:38:00 <rhiaro> ... I'd like to ask you Shigeya does everything make sense and do you feel it's actionable? Are the priorities clear?
15:38:07 <rhiaro> ... and what you need to implement is clear?
15:38:08 <burn> ack shigeya
15:38:14 <rhiaro> shigeya: yes, actionable
15:38:16 <rhiaro> ... depends on the deadline
15:38:18 <rhiaro> ... and my time
15:38:25 <rhiaro> ... not so much work I believe
15:38:26 <manu> q+
15:38:33 <rhiaro> ... when do we need the report?
15:38:34 <burn> q+ to say summaries, both pos and neg, are what's important
15:38:39 <burn> ack manu
15:38:48 <rhiaro> manu: whenever
15:38:51 <rhiaro> ... you can do it
15:39:02 <rhiaro> ... ideally everything ready by next monday, but I don't think that's realistic
15:39:18 <rhiaro> ... within the next two to three weeks, the most basic thing, that would be decent shape
15:39:22 <burn> ack burn
15:39:22 <Zakim> burn, you wanted to say summaries, both pos and neg, are what's important
15:39:25 <rhiaro> shigeya: that's doable
15:39:26 <rhiaro> burn: agree
15:39:38 <rhiaro> ... first, thank you Shigeya, we should give Shigeya a lot of thanks
15:39:42 <manu> yes, +1 -- this is a big job and it's very much appreciated.
15:39:57 <rhiaro> ... all we need is the summaries
15:40:08 <rhiaro> ... and individual reports if you can. Doesn't have to be beautifully linked
15:40:13 <rhiaro> ... positive and negative are important
15:40:13 <manu> q+ to note negatives
15:40:17 <burn> ack manu
15:40:17 <Zakim> manu, you wanted to note negatives
15:40:31 <rhiaro> manu: on the negatives, people don't like submitting negative tests to show an implementation fails or doesn't conform
15:40:36 <rhiaro> burn: i meant that we don't have at least two
15:40:41 <rhiaro> ... we are failing the report
15:40:46 <rhiaro> manu: +1
15:40:50 <rhiaro> burn: any other comments?
15:40:51 <shigeya> q+
15:40:57 <burn> ack shigeya
15:41:04 <rhiaro> shigeya: there are a bunch of examples here
15:41:08 <rhiaro> ... so we need to eliminate them
15:41:10 <rhiaro> ... at some point
15:41:16 <manu> q+
15:41:29 <rhiaro> ... any good ideas to handle this?
15:41:30 <burn> ack manu
15:41:39 <TallTed> +1000000 thanks to Shigeya -- setting these reports up is vital, never gets enough resource, and often falls flat. this is one of the more challenging groups to set up report on, and these reports are far beyond what might have been delivered.
15:41:48 <rhiaro> manu: it is very important that the examples remain in th etest suite to make sure we are testing everything
15:41:53 <rhiaro> ... we needed the test suite to run against something
15:42:10 <rhiaro> ... all that needs to remain, but shigeya you're right, when we generate the report the report should not include the examples
15:42:13 <burn> q?
15:42:21 <ivan> +1 to manu on not including did:example
15:42:25 <rhiaro> ... probably needs code that you run to eliminate the things with example in them
15:42:31 <rhiaro> ... I don't know how exactly, might have to be a regex
15:42:47 <rhiaro> ... I don't think we have the word example in any of the normative statements, so you would check the implementation, and I don't think we have 'exmaple' in any implementation names
15:42:57 <rhiaro> ... so you might be able to filter out those test results by doing a regex against the implementation name
15:42:58 <rhiaro> shigeya: i will try
15:43:12 <burn> Topic: Report on documents
15:43:18 <manu> q+
15:43:20 <TallTed> present+
15:43:23 <rhiaro> burn: report on implementation guide or rubric?
15:43:23 <burn> ack manu
15:43:35 <rhiaro> manu: I have a list, but happy to defer to editors of each doc
15:43:41 <rhiaro> ... Use cases would be Joe and Phil
15:43:50 <rhiaro> ... it's done.
15:43:55 <rhiaro> ... We published it. Hurrah!
15:44:05 <rhiaro> ... DID Core has a few issues remaining but they're being handled
15:44:13 <rhiaro> ... one issue from securekey that we want to have a light discussion around in the next week or two
15:44:18 <rhiaro> ... around the construction of DID URLs
15:44:25 <rhiaro> ... and we've got a number of PRs, many editorial
15:44:31 <rhiaro> ... one is moving the cbor thing out into its own note
15:44:36 <rhiaro> ... other ones having to do with cleanup in the appendices
15:44:40 <rhiaro> ... that's happening and will continue
15:44:48 <rhiaro> ... slower than I'd like but we're addressing them
15:44:56 <rhiaro> ... The outstanding scary thing is the MIME type discussion at IETF
15:45:01 <rhiaro> ... Need to email about a decision
15:45:05 <rhiaro> ... concerned our fallback is unworkable
15:45:20 <rhiaro> ... We may need to put aside some time to talk about what we're going to do
15:45:26 <rhiaro> ... waiting on sending an email to ietf
15:45:26 <ivan> q+
15:45:35 <burn> ack ivan
15:45:47 <rhiaro> ivan: why do you think the alternative is not workable?
15:45:57 <rhiaro> manu: i don't think people want to implement it... the profile thing on ld+json feels unworkable
15:46:02 <rhiaro> ... having had a fresh discussion about it
15:46:15 <rhiaro> ... we thought people would be okay with it but they thought surely ietf would have a decision at this point so they didn't consider us having to implement it
15:46:30 <rhiaro> ... do other people feel that way?
15:46:32 <rhiaro> ivan: separate discussion
15:46:43 <rhiaro> manu: DID Spec registries
15:46:50 <rhiaro> ... based on decisions in past weeks, design is mostly stable
15:46:54 <rhiaro> ... still a large number of issues
15:47:06 <rhiaro> ... most are we don't have contact information for authors of specs, except for github handles, which have worked out well
15:47:11 <rhiaro> ... we can get a list of all the contributors
15:47:20 <ivan> q+
15:47:23 <rhiaro> ... many are DID method creators, that's how we pinged 90+ of them when we needed implementations and they repsonded
15:47:28 <rhiaro> ... we just don't have email addresses
15:47:29 <ivan> q-
15:47:31 <rhiaro> ... no big blockers I can think of
15:47:48 <rhiaro> ... Next, DID Rubric
15:48:02 <rhiaro> ... Joe reported out on that two weeks ago, in good shape, waiting on a PR from Joe to update with 20+ new considerations
15:48:04 <rhiaro> ... work continues
15:48:13 <rhiaro> ... Next is DID+CBOR note
15:48:19 <rhiaro> ... that spec was created this weekend by ivan and I
15:48:27 <rhiaro> ... we have a repo with all the latest in it, spec has been cleaned up
15:48:31 <rhiaro> ... we're close to being able to publish that as a note
15:48:44 <ivan> q+
15:48:45 <rhiaro> ... we'll do it when we've got many of the DID Core editorial updates to the appendices done
15:48:53 <rhiaro> ... finally the implementation guide has been updated to use Orie's language
15:48:56 <rhiaro> ... Orie did a bunch of suggestions
15:49:00 <rhiaro> ... some were controversial
15:49:09 <rhiaro> ... markus has put in a PR on @context and his concerns around that
15:49:23 <rhiaro> ... the decision we made is that we're going to allow people to take positions that are controversial and document all the different arguments on that controversy
15:49:28 <rhiaro> ... so it's documented and crosslink them to each other
15:49:37 <rhiaro> ... so people can read and understand that there are some things the group couldnt agree on
15:49:46 <rhiaro> ... take a look at Orie's new language and markus' PR, we're going to merge that
15:49:49 <rhiaro> ... and we'll have a note by the tiem the WG ends
15:49:51 <rhiaro> ... that's in good shape
15:49:58 <rhiaro> ... General takeaway is we're in good shape, have been for a while
15:50:02 <rhiaro> ... Good job as a WG
15:50:14 <burn> ack ivan
15:50:16 <rhiaro> ... looks like we're going to have a number of useful documents that are in our charter and a couple that weren't that are going to help the ecosystem
15:50:23 <rhiaro> ivan: did we get any feedback from jonathon the cbor stuff?
15:50:24 <rhiaro> manu: none
15:50:37 <rhiaro> burn: questions or comments?
15:50:51 <ivan> s/jonathon/jonathan/
15:51:21 <burn> Topic: Status of registries
15:51:26 <rhiaro> manu: We never came to ground on if we were going to have a description field in the Registries or not
15:51:50 <rhiaro> ... Currently every entry is meant to have the thing that's being registered a link to where it' sdefined and an open question about should we have a field where the person registering can put in useful information about the field
15:52:01 <rhiaro> ... eg. this property will work across all representations
15:52:15 <rhiaro> ... and the cbor tag for this is value 63
15:52:18 <rhiaro> ... that's been a proposa
15:52:28 <rhiaro> ... the counter argument against it is because there's no standard entry people can put in whatever
15:52:31 <rhiaro> ... but maybe that's okay
15:52:40 <rhiaro> ... maybe we allow people to put in guidence around specific properties that they feel are important
15:52:46 <rhiaro> ... the real thing that matters is the link to the spec
15:52:53 <rhiaro> ... the managers of the registry dont' have to care that much about th edescrpition
15:53:10 <rhiaro> ... may do some high level check but not requiring the registry maintainers to evaluate the truth of what the registrant writes
15:53:20 <rhiaro> ... Do we want a general description field? Or forbid that and only provide a link?
15:53:23 <rhiaro> ... and the json-ld context
15:53:46 <rhiaro> ... Would there be any objections to providing a description field that registrants can use for purposes that they deem are important?
15:53:50 <rhiaro> ... free form text field
15:53:57 <rhiaro> ... light vetting
15:54:06 <rhiaro> ... but up to the people managing the registry to determine
15:55:02 <rhiaro> manu: *proposal writing voice*
15:55:23 <manu> PROPOSAL: The DID Specification Registries will support a "description" field for all registry entries that can be used at the discretion of the registrant to express items of importance to the registered item. The registry maintainers are not required to check the truthfulness of the statement, but may exercise their best judgement when processing the registration request.
15:55:41 <justin_r> q+
15:55:45 <burn> ack justin_r
15:56:10 <rhiaro> justin_r: problem I have is that it is a very long winded way to say this is a human readable field with no implied impact on interoperability
15:56:35 <rhiaro> ... but given the fact it has been the intent of the WG of the registry to not have a normative impact on interop... we can make this proposal but it is ultimately meaningless
15:56:43 <rhiaro> ... I object to the statement but I dont think my objection matters
15:57:10 <TallTed> +0.5 but may need "how to get changes made" if/when something gets past "best judgement" and similar...
15:57:10 <rhiaro> manu: the effect is .. I half agree
15:57:23 <rhiaro> ... it is true, but we're recording that the group contemplated this.
15:57:39 <rhiaro> ... yes we have the field, no it doesn't really mean anything, has no normative effect, but might guide  people in the right direction
15:58:09 <rhiaro> burn: the way I heard what Justin said is that there was a different decision that you disagree with and this continues to be part of that same disagreement. You can object but there's no point in objecting because it's at a different level
15:58:24 <rhiaro> ... unless we're going to revisit the broader statement I'd rather see if we get agreement on a statement today that presumes that prior broader decision
15:58:29 <rhiaro> ... maybe it requires manu a couple of adjustments
15:58:45 <rhiaro> ... something like "because these statements do not have normative effects, this doesn't either"
15:59:26 <rhiaro> burn: ...this description field will not have a normative effect because the DID Spec Registries are not normative
15:59:30 <justin_r> q+
15:59:36 <burn> ack justin_r
15:59:47 <rhiaro> justin_r: I'm not trying to throw a process wrench
15:59:53 <rhiaro> ... take the proposal as is go ahead
15:59:56 <TallTed> I can't form a considered opinion for this.... maybe table
16:00:04 <TallTed> ?
16:00:05 <manu> PROPOSAL: The DID Specification Registries will support a "description" field for all registry entries that can be used at the discretion of the registrant to express items of importance to the registered item. The registry maintainers are not required to check the truthfulness of the statement, but may exercise their best judgment when processing the registration request.
16:00:10 <manu> +1
16:00:13 <justin_r> +0 (it's a bad idea)
16:00:17 <agropper> +0
16:00:30 <rhiaro> <rhiaro> 0 .. seems like everything should go in external specs, and also 'description' is maybe misleading and could duplicate spec content
16:00:38 <TallTed> I like "description" field, but unclear this is doig what i wanted
16:00:40 <markus_sabadello> +0 has pros and cons
16:00:45 <rhiaro> burn: not seeing overwhelming support
16:01:00 <rhiaro> manu: if nothing else happens we're just not going to have a description field, and the registration will have al ink to spec and to jsonld context
16:01:03 <rhiaro> burn: needs more work..
16:01:06 <TallTed> s/i wanted/is wanted/
16:01:07 <rhiaro> manu: but we need to implement something
16:01:13 <rhiaro> ... if the group changes its mind that's fine
16:01:17 <rhiaro> ... or we add in future that's fine
16:01:23 <rhiaro> ... for now the decision is clear.. no description yet
16:01:30 <rhiaro> ... editors shouldn't move on that
16:01:38 <rhiaro> ... all we have is a link to spec and to jsonld context and you're done
16:01:42 <rhiaro> burn: we're over time
16:01:51 <rhiaro> ... thanks everyone
16:01:56 <ivan> rrsagent, draft minutes
16:01:56 <RRSAgent> I have made the request to generate https://www.w3.org/2021/05/18-did-minutes.html ivan
16:02:15 <ivan> zakim, end meeting
16:02:15 <Zakim> As of this point the attendees have been burn, ivan, shigeya, justin_r, markus, manu, Geun-Hyung, chriswinc, dmitriz, markus_sabadello, rhiaro, agropper, brent, drummond, TallTed
16:02:18 <Zakim> RRSAgent, please draft minutes
16:02:18 <RRSAgent> I have made the request to generate https://www.w3.org/2021/05/18-did-minutes.html Zakim
16:02:20 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:02:24 <Zakim> Zakim has left #did