15:13:11 <RRSAgent> RRSAgent has joined #did
15:13:11 <RRSAgent> logging to https://www.w3.org/2020/12/15-did-irc
15:13:13 <Zakim> RRSAgent, make logs Public
15:13:15 <Zakim> please title this meeting ("meeting: ..."), ivan
15:13:23 <ivan> Meeting: DID WG Telco
15:13:23 <ivan> Chair: brent
15:13:23 <ivan> Date: 2020-12-15
15:13:23 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020Dec/0007.html
15:13:23 <ivan> ivan has changed the topic to: Meeting Agenda 2020-12-15: https://lists.w3.org/Archives/Public/public-did-wg/2020Dec/0007.html
15:25:20 <TallTed> TallTed has joined #did
15:57:38 <ivan> present+
16:00:32 <ivan> present+ brent
16:00:38 <ivan> present+ shigeya
16:00:57 <ivan> present+ rhiaro
16:00:57 <ivan> present+ TallTed
16:01:37 <jonathan_holt> jonathan_holt has joined #did
16:02:12 <jonathan_holt> present+ jonathan_holt
16:02:40 <ivan> present+ identitywoman
16:02:52 <TallTed> present+
16:02:53 <brent> present+
16:02:53 <identitywoman> identitywoman has joined #did
16:02:56 <markus_sabadello> markus_sabadello has joined #did
16:02:56 <dlongley> present+
16:02:58 <ivan> present+ dlongley
16:03:09 <agropper> agropper has joined #did
16:03:13 <ivan> regrets+ burn
16:03:19 <agropper> present+
16:03:41 <identitywoman> present+
16:03:44 <ivan> present+ markus_sabadello
16:03:57 <jonathan_holt> scribe+ jonathan_holt
16:04:04 <ivan> scribe+ rhiaro
16:04:21 <jonathan_holt> brent : agenda....
16:04:48 <jonathan_holt> ... special topic call, dagCBOR, DID core vocabulary.  then discuss issues staring with priority 1 then 2
16:04:51 <rhiaro> q+ to talk about TAG election (2 mins)
16:04:58 <ivan> present+ manu
16:05:11 <wayne> present+
16:05:19 <jonathan_holt> rhiaro :  take 2 minutes to discuss TAG election
16:05:23 <ivan> present+ wayne
16:05:48 <justin_r> justin_r has joined #did
16:05:54 <jonathan_holt> brent :  next special topic registry handling,  on Thursday the 12/17 12pm EST
16:05:57 <justin_r> present+
16:05:59 <wayne> q+
16:06:06 <ivan> present+ justin_r
16:06:40 <jonathan_holt> rhiaro:  TAG has an election coming up.  The TAG is a achetectual group.
16:06:53 <jonathan_holt> ... I'm standing in this election as is Wayne.
16:07:00 <phila_> phila_ has joined #did
16:07:10 <jonathan_holt> ... my background is in open data and I'm hoping to represent that community.
16:07:18 <identitywoman> when is the election?
16:07:28 <jonathan_holt> ... if you are an AC rep, encourage you to vote.
16:07:35 <rhiaro> https://www.w3.org/2020/12/07-tag-nominations
16:07:38 <wayne> https://www.w3.org/2020/12/07-tag-nominations#wc
16:07:47 <rhiaro> https://rhiaro.co.uk/2020/11/tag-statement
16:07:50 <jonathan_holt> ... the election is through the 5th of Jan
16:08:04 <brent> ack amy
16:08:12 <brent> ack rhiaro
16:08:12 <Zakim> rhiaro, you wanted to talk about TAG election (2 mins)
16:08:15 <brent> ack wayne
16:08:26 <ivan> present+ phila
16:08:27 <wayne> https://www.w3.org/Member/ACList
16:08:40 <jonathan_holt> wayne :  i want to express my support, there are multiple seats open including possibly both of us.  I can provide a link to find your AC rep.
16:08:46 <manu> q+ to note why this TAG election is extra special.
16:08:57 <jonathan_holt> ... there are a lot of interest in VC and we could build that bridge.
16:08:57 <brent> ack manu
16:08:57 <Zakim> manu, you wanted to note why this TAG election is extra special.
16:09:35 <by_caballero> by_caballero has joined #did
16:09:38 <by_caballero> present+
16:09:42 <jonathan_holt> manu:  that is awesome that they are running.
16:10:04 <agropper> I don't have privilege to access the ACList
16:11:17 <brent> https://w3c.github.io/did-core/#dagcbor
16:11:17 <jonathan_holt> brent:  topic dagCbor
16:11:22 <dmitriz> dmitriz has joined #did
16:11:34 <ivan> present+ dbuc
16:11:40 <dmitriz> present+
16:11:43 <jonathan_holt> manu:  check in with jonathan
16:11:57 <Orie> Orie has joined #did
16:12:11 <ivan> present+ orie
16:12:12 <jonathan_holt> ... CBOR is in!  wow-ho!.  we have made some update to make it inline including production and consumption.
16:12:15 <identitywoman> who else is good to vote for?
16:12:38 <identitywoman> cause there are 4 seats  - like should I vote for the mozilla person?
16:13:04 <jonathan_holt> ... mostly asking about canonical.  then there is a section on dagCbor.  I don't remember if we have consensus?
16:13:24 <jonathan_holt> q+
16:13:31 <brent> ack jonathan_holt
16:13:33 <ivan> scribe+ manu
16:14:21 <manu> jonathan_holt: The section I put for canonical focuses mostly on DAG CBOR section, you need it in a deterministic canonical format... CBOR spec does give guidance, but it's not set in stone, it's up to app developers like our specification to decide what is canonical.  Nuances of lossless conversion in/out of dat model... that's an additional constraint.
16:15:38 <manu> jonathan_holt: I put everything I could think of to make it canonical, very involved in IPLD / IPFS community, been working ont hat for years -- how to make sure it's as deterministic as possible... they have a billion dollar industry to make sure things are deterministics - making sure it's working as intended. Most issues are in numbers, JSON, 53-bits vs 64-bits, since we've dropped numbers, bigint, bigfloat, not an issue that will pop up right now for
16:15:38 <manu> canonical deterministic -- deterministic ordering of map - order right way, get different hash, really important.
16:15:44 <manu> q+ on canonical information models.
16:16:06 <Orie> See also https://tools.ietf.org/html/rfc7049#section-3.9
16:16:21 <manu> jonathan_holt: wrt. production/consumption rules -- consensus on DagCBOR -- suppose section on deterministic representation has more to do w/ DAG section, I certainly am heavily into DAG, lightweight approach to blockchain.
16:16:35 <dbuc> dbuc has joined #did
16:16:49 <manu> jonathan_holt: I think we do have a lot of consensus on worth of this approach, lot of work done in CG... multihash/multibase/hashlink in DID URL this community is invested in that technology
16:16:59 <selfissued> selfissued has joined #did
16:17:20 <selfissued> present+
16:17:27 <manu> jonathan_holt: DAGCBor is extension of hashlink -- rather than URL can be a type in DID Document... this probably needs to be worked out in DID Spec registries, can push DID Spec registries back into DID Core to get more cohesive support for it.
16:17:35 <Orie> q+ to talk about "cbor flavors"
16:17:39 <manu> jonathan_holt: How to build out extensibility... DAG CBOR extension to CBOR
16:17:41 <manu> q- later
16:17:50 <brent> ack Orie
16:17:50 <Zakim> Orie, you wanted to talk about "cbor flavors"
16:18:02 <dbuc> manu: wrt your latest comment in effort to resolve the serviceEndpoint value, the LinkedDomains SE will need to require that the values are only parsed as origins, in the form defined by the HTML spec and its same origin model
16:18:21 <jonathan_holt> orie:  I have support for CBOR, I want to make sure that doesn't cap us for vanilla cbor.
16:18:32 <manu> Orie: Generally supportive of CBOR, need to do that in a way that doesn't cap us -- added support for vanilla CBOR to did:key that supports vanilla CBOR (What you get when you call CBOR.encode() on DID resolution)
16:18:59 <jonathan_holt> ... vanilla CBOR is what you get when you convert.  our implementation of did key and CBOR.
16:19:02 <dbuc> manu: if we remove objects as a valid value, the one thing that could bite us is instances where a Service Endpoint needs to have other values outside of the URL - where would a SE put those values?
16:19:41 <jonathan_holt> ... when you talk about CBOR, the is an RFC.  dagCBOR is a document.  i'm not sure about the sub-types.
16:20:04 <jonathan_holt> ... i' having trouble understanding how we support them in the DID spec registries.
16:20:19 <manu> s/manu: if we remove/manu, if we remove/
16:20:23 <jonathan_holt> ... I can only do so much for the CBOR section.
16:20:36 <brent> ack manu
16:20:36 <Zakim> manu, you wanted to comment on canonical information models.
16:21:26 <jonathan_holt> manu:  the concern I have is calling something cananical form is that you have some mathmatical form.   I don't think we have that.
16:22:16 <jonathan_holt> ... having spent the last 7 years to get the JSON-LD stuff, it is hard.
16:22:32 <selfissued> q+
16:23:27 <jonathan_holt> ... dagCBOR, i agree with Orie that we can do this in DID spec registries.  we need to address. pushing canonical out and dagCBOR out as another representation.
16:23:38 <jonathan_holt> q+
16:23:44 <brent> ack selfissued
16:24:08 <manu> it is definitely not defined in the CBOR spec
16:24:12 <manu> I will find a link
16:24:13 <brent> ack jonathan_holt
16:24:13 <jonathan_holt> selfissued :  canonical is in the RFC, we ...
16:24:17 <Orie> whats in the cbor spec is not dag cbor, fyi
16:24:56 <manu> q+
16:26:30 <brent> ack manu
16:26:41 <manu> https://tools.ietf.org/html/rfc7049#section-3.9
16:26:58 <jonathan_holt> manu:  this is shaping up to need a special topic call.
16:27:05 <manu> Those protocols are free to define what they mean by a canonical format and what encoders and decoders are expected to do.
16:27:17 <jonathan_holt> ... protocols are free to define what they mean by canonical.
16:27:37 <jonathan_holt> jonathan_holt agrees with justin_r
16:27:46 <jonathan_holt> ... needs more discussion.
16:27:58 <jonathan_holt> yes, thatnk!
16:28:02 <brent> https://github.com/w3c/did-core/issues/404
16:28:04 <rhiaro> TOPIC: DID Core vocab
16:28:17 <rhiaro> brent: this was raised by ivan, folks have commented
16:28:21 <rhiaro> ... we have 10 minutes or so to talk about it
16:28:28 <manu> q+ to get a plan of attack together.
16:28:31 <Orie> q+
16:28:34 <brent> ack manu
16:28:34 <Zakim> manu, you wanted to get a plan of attack together.
16:28:43 <rhiaro> manu: ivan this is mostly, the question to you - what are the expectations here?
16:28:55 <rhiaro> ... we've had discussion, the core thing we're trying to get to is we need a formal RDF vocabulary for DID core
16:28:57 <ivan> q+
16:29:04 <rhiaro> ... what I want to make sure is that we're all aligned on what we need to do to make that happen
16:29:17 <rhiaro> ... we've got a human readable part of this which is the registries to a certain degree, itd oesn't have rdfa
16:29:28 <rhiaro> ... the expectation is that we will probably have some rdf schema definition somewhere
16:29:32 <rhiaro> ... I believe that's primarily what you're asking for?
16:29:33 <Orie> some related conversation on this dead PR
16:29:34 <Orie> https://github.com/w3c/did-spec-registries/pull/170
16:29:40 <brent> ack Orie
16:29:47 <rhiaro> Orie: I linked.. I had a conversation with amy related to this on the did spec registries
16:29:56 <rhiaro> ... it's a PR for a thing that's probably not going to get merged but there's good conversatin on there
16:30:28 <rhiaro> ... my initial proposal would be lets set up the html side of the vocab definitino the same way activitystreams have (see thread) and suse the DID spec registries repo for it for the time being, and work towards getting stable urls behaving in the way we want them to, and then work on setting up proper redirects for the vocab after that
16:30:50 <rhiaro> .. .from the perspective of what is needed, it's a versioned html and jsonld files and I think we can do all that in the did spec registries and work towards a working solutin there before we worry about fixing the top level urls
16:30:55 <brent> ack ivan
16:31:09 <rhiaro> ivan: I was probably not clear in what I wrote, but manu unfortunately this is not what I meant
16:31:12 <rhiaro> ... forget about RDF
16:31:20 <rhiaro> ... I used RDF as an example simply because that's what I understand well
16:31:35 <rhiaro> ... the problem is that if you read the document you have a bunch of properties that are defined there and it is not really clear .. two things
16:31:50 <rhiaro> ... one is, maybe it has improved, what are the properties and classes that are defined as part of the core standard and what are there as an example
16:31:53 <rhiaro> ... I have said that many times
16:31:58 <rhiaro> ... and it hasn't been clearly spelled out somewhere
16:32:10 <rhiaro> ... and what is even worse is that there are a number of constraints that are not clearly spelled out for the reader
16:32:20 <kristina> kristina has joined #did
16:32:38 <rhiaro> ... the various examples is on the top of my head the id property which in some ases can have only this and this values and in other cases can be used with different values, sometimes only did as a value, some cases you can use whatever url you imagine
16:32:51 <rhiaro> ... there are the property controller which can be used on some types of objects and cannot be used somewhere else, what do they mean
16:32:57 <rhiaro> ... there is a set of clear definition and constraints that are missing
16:33:03 <kristina> present+
16:33:08 <rhiaro> ... hard to have those constraints spelled out as part of the spec is largely an editorial thing
16:33:25 <rhiaro> ... what I did was spell out those constriants for the RDF side by using shacl and I realise that this was more an execise for myself because you don't necessarily know shacl
16:33:38 <rhiaro> ... in a way what I saw done by jonathan for cddl is doing something very similar
16:33:40 <manu> q+ to note we might have solutions in CDDL, official RDF Vocab, and JSON-LD Contexts.
16:33:49 <manu> q+ to note JSON Schema as well.
16:33:50 <rhiaro> ... I am not a real expert in cddl but what I understood is describing more or less the same things
16:33:58 <rhiaro> ... I don't are in which format we do that, but the spec must be clear
16:34:00 <rhiaro> ... in my reading it is not
16:34:18 <rhiaro> ... apart from that, yes we define a vocab for the usage of rdf and linked data and yes for that we should have a formal vocab that describes the vocab in terms of rdf
16:34:22 <rhiaro> ... that is not the same as the context file
16:34:29 <rhiaro> ... it's a rdf specification or something
16:34:32 <identitywoman> identitywoman has joined #did
16:34:42 <manu> q+ to mention ADM being tightened up.
16:34:47 <rhiaro> ... that is something that should be done, it is not necessarily part of the spec, not normative, should be present and reachable, that's something we can do very easily once the spec is out
16:34:52 <rhiaro> ... that's okay, that's not the real issue
16:34:58 <rhiaro> ... the real issue for me is the proper specification
16:35:10 <rhiaro> ... I think that amy began to thinka bout ding some kind of table representation of the terms to express the various constraints
16:35:13 <rhiaro> ... that can also work for me
16:35:15 <rhiaro> ... it's up to the editors
16:35:20 <brent> ack manu
16:35:20 <Zakim> manu, you wanted to note we might have solutions in CDDL, official RDF Vocab, and JSON-LD Contexts. and to note JSON Schema as well. and to mention ADM being tightened up.
16:35:30 <rhiaro> manu: that is helpful, thanks ivan
16:35:38 <rhiaro> ... there are a couple of things that have happened since yoru review that have improved things
16:35:53 <rhiaro> ... we're in the process of really nailing down the ADM and the representations, so hopefully it's far more clear what you can have associated with each property across all representations
16:36:00 <rhiaro> ... that's one level of improvement, not done we need another pass
16:36:07 <rhiaro> ... hopefully that addresses one of your main concerns
16:36:27 <rhiaro> ... the other thing we've got now, jonathan put all that work into the cddl stuff os we have a syntax enforcement mechanism now for things that support it, like json, jsonld and cbor
16:36:29 <ivan> q?
16:36:33 <ivan> q+
16:36:35 <rhiaro> ... we have that shacl/json schema mechanism but in this case we're using cddl to do that
16:36:47 <rhiaro> ... the third thing we have are the jsonld contexts which are in flux but we're getting them shaped up
16:36:54 <rhiaro> ... the only missing item is a good rdf voabulary
16:36:55 <jonathan_holt> q+
16:37:01 <rhiaro> ... something that more of the Semantic Web folks could utilise
16:37:22 <rhiaro> ... and we should probably look at gregg kellogg's tool that converts csv files into full blow human readable vocabs plus the rdf schema stuff in turtle format and whatever different formats we want
16:37:26 <rhiaro> ... I feel like that's the last missing thing
16:37:34 <rhiaro> ... that can be autogenerated into the rdf things
16:37:36 <selfissued> q+
16:37:42 <rhiaro> ... with all of those things in place my hope is it addresses all the concerns you raised
16:37:44 <rhiaro> ... I just don't know if it would
16:37:50 <brent> ack ivan
16:38:06 <rhiaro> ivan: as I said I am perfectly fine to use cddl for that. If that's the way we do it, that's fine.
16:38:15 <rhiaro> ... the only quesiton I have and maybe it's an obvious answer, is the cddl part of the normative spec?
16:38:18 <rhiaro> manu: no
16:38:21 <rhiaro> ivan: it should be
16:38:23 <rhiaro> ... that's the major point
16:38:30 <rhiaro> ... it's the definition of all the constraints in a clearly defined way
16:38:33 <rhiaro> ... this is one point
16:38:35 <ivan> -> Draft RDFS Vocabulary https://github.com/w3c/did-core/wiki/Draft-DID-Core-Vocabulary
16:38:49 <rhiaro> ... the rdf vocabulary I did something back then which is already on our wiki page. this has to be updated because we don't have the whole thing
16:38:53 <rhiaro> ... it was not perfect at that point
16:39:06 <rhiaro> ... but that is there and as I said if the cddl is normative then this rdfs vocab doesnt have to be normative
16:39:17 <rhiaro> ... it is perfectly fine to have it .. it should be properly doen but it's not something that holds up the CR
16:39:23 <rhiaro> ... and we can start if from there
16:39:28 <brent> ack jonathan_holt
16:39:43 <rhiaro> jonathan_holt: the cddl spec itself is normative and it extends the abnf rules, it is a normative description of the constraints and type definitions
16:39:52 <rhiaro> ... which is what I think the rdf attempts to do with symbol representaiton for concepts
16:39:57 <rhiaro> ... as ascii strings, it representsion something
16:40:00 <manu> Editor's note: It is not normative right now... it would take a lot of work to get it to be normative.
16:40:10 <rhiaro> ... I think cddl tries to not boil the ocean in that way, it really is a constraint satisfaction which is mathematically proven
16:40:15 <rhiaro> ... you can do the closures to make sure it captures everything you hope
16:40:18 <rhiaro> ... I've demoed that before
16:40:25 <rhiaro> ... you can genreate examples using cddl which I've found really helpful
16:40:30 <ivan> -> Draft SHACL version https://github.com/w3c/did-core/wiki/Draft-DID-Core-Vocabulary-Shape
16:40:41 <rhiaro> ... cddl does have a lot of power to help along the spec and really help constrain it into what types are allowed
16:40:50 <rhiaro> ... as we've been finding there are some challenges when you go into an abstracted version of that
16:40:56 <rhiaro> ... still a challenge with numbers
16:41:10 <rhiaro> ... the number representation in ipld is still challenging to represent when you have limitations with certain representations
16:41:16 <brent> ack selfissued
16:41:31 <rhiaro> selfissued: I push back on the idea that rdf is necessary or even useful
16:41:40 <rhiaro> ... if we do that it would be one more parallel representation of what we already have normatively in the spec
16:41:50 <rhiaro> ... if we believe the spec is not sufficiently clear in places that ivan described we should make the spec clear
16:42:03 <rhiaro> ... we shouldn't fall back to trying to maintain and create a separate paralell representaiton of the spec
16:42:08 <rhiaro> ... I think we should do no rdf work
16:42:20 <rhiaro> brent: if we could have those comments occur in the issues I think that would be best
16:42:23 <rhiaro> ... issue 404
16:42:30 <rhiaro> Topic: issue processing
16:42:33 <brent> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p1+sort%3Aupdated-asc
16:42:50 <rhiaro> brent: these are priority 1 issues
16:42:58 <rhiaro> ... a few we'll go through pretty qickly
16:43:03 <rhiaro> ... 118 we'll do before CR
16:43:14 <rhiaro> ... horizontal review tracking is an open issue 292 to track the various horizontal reviews, will stay open
16:43:22 <rhiaro> ... 119 is about discussion with the TAG
16:43:34 <rhiaro> ... tahns to the gruop we now have a security and privacy questionnaire, the chairs will send it on to TAG and PING
16:43:39 <rhiaro> ... and for those reviews to progress
16:43:45 <rhiaro> ... I can comment on this issue
16:43:54 <rhiaro> ... number 384 is next
16:43:58 <brent> https://github.com/w3c/did-core/issues/384
16:44:07 <rhiaro> ... review of all of the normative statements in the spec
16:44:19 <rhiaro> ... the status is the same as last week, addressing this issue requires tests to be written
16:44:39 <rhiaro> ... encourage folks to review this issue and while they review it allow the scope of normative statements to spur them to contribute to our test suite
16:44:48 <brent> https://github.com/w3c/did-core/issues/199
16:44:50 <rhiaro> ... next is 199, clarification of what DIDs might identify
16:44:57 <rhiaro> ... I raised this and am assigned to it, so taking off my chair hat
16:45:01 <rhiaro> ... the status is that there is an open PR
16:45:06 <brent> https://github.com/w3c/did-core/pull/480
16:45:07 <rhiaro> ... the PR is 480
16:45:14 <rhiaro> ... there has been some review but there needs to be more
16:45:17 <rhiaro> ... please review that PR
16:45:19 <rhiaro> ... and give your opinions there
16:45:26 <rhiaro> ... chair hat back on
16:45:29 <rhiaro> ... next is 291
16:45:33 <brent> https://github.com/w3c/did-core/issues/291
16:45:45 <rhiaro> ... PING horizontal review.. I believe Orie asked if we can check this box and I'm going to check the box!
16:46:09 <rhiaro> ... next, 464 was raised by orie and is assigned to him
16:46:14 <brent> https://github.com/w3c/did-core/issues/464
16:46:18 <rhiaro> ... did core must define how to compute the digest to secure DID spec registries entries contexts
16:46:23 <rhiaro> Orie: there is a PR open for it
16:46:27 <rhiaro> ... hopefully it's linked there, please review that
16:46:35 <brent> https://github.com/w3c/did-core/pull/485
16:46:43 <rhiaro> ... the tldr is if you're going to tell people that content digests are somehow going to help protect them you're going to have to describe how to use that
16:47:05 <brent> https://github.com/w3c/did-core/issues/498
16:47:10 <rhiaro> ... our next issue is 498, datetime data type missing timezone and precision, raised by manu
16:47:37 <rhiaro> manu: we are trying to again get very specific with the ADM and the representations and we just didn't specify that you need to express eerything in zulu time and we didnt' specify the precision that you should express datetime values in
16:47:42 <rhiaro> ... the suggestion is not to do milisecond precision
16:47:49 <rhiaro> ... if people want that they can do something else, you can extend it o you can do that
16:47:54 <rhiaro> brent: ready for a PR?
16:48:02 <rhiaro> manu: yeah, a simple thing, I just wrote it down to make sure we were tracking
16:48:14 <brent> https://github.com/w3c/did-core/issues/499
16:48:15 <rhiaro> brent: next 499, metadata properties don't define data model and serialisation format
16:48:29 <rhiaro> manu: this is to track the last item that justin had raised on the we need a better data model
16:48:38 <rhiaro> ... justin pointed out we need to spec what the values space and lexical space of all these itmes are
16:48:44 <rhiaro> ... those same things need to apply to the metadata properties
16:48:57 <rhiaro> ... we've updated to be clear about the core data model and the representations but we haven't one the same work ont he metadata section
16:49:02 <rhiaro> ... that' sa straightforward PR to write
16:49:08 <brent> https://github.com/w3c/did-core/issues/58
16:49:12 <rhiaro> brent: next is 58, registry handling
16:49:19 <rhiaro> ... we are having a special topic call on this issue this coming thursday
16:49:27 <rhiaro> ... if anyone would like to comment on it now they can but I'm happy to move on
16:49:40 <rhiaro> Orie: please review all of the issue that have discussed this before the meeting on thursday
16:49:45 <rhiaro> ... there has been a lot of talk about this
16:49:53 <rhiaro> ... if you show up on thursday having not reviewd the issue I will personally be disappointed in you.
16:49:57 <rhiaro> brent: i second that
16:50:10 <brent> https://github.com/w3c/did-core/issues/170
16:50:13 <rhiaro> ... next 170, this is public key id and type members duplicate jwk kid and kty members
16:50:17 <Orie> PROPOSAL: close this issue
16:50:20 <rhiaro> ... now assigned to selfissued
16:50:34 <rhiaro> ... the last time we talked I belive you agreed that if text needed to be changed you would write a PR for that
16:51:00 <rhiaro> selfissued: I've had other things to do
16:51:04 <rhiaro> brent: understandable, thank you
16:51:09 <Orie> selfissued, please also review https://github.com/w3c/did-core/pull/490
16:51:11 <Orie> its related
16:51:19 <rhiaro> ... issue 240, should did core restrict the use of jwk
16:51:20 <brent> https://github.com/w3c/did-core/issues/240
16:51:29 <rhiaro> ... assigned to manu, mike and orie
16:51:43 <rhiaro> manu: there's a PR that orie wrote that addresses this by saying dont' express private properties in a DID document
16:51:50 <rhiaro> ... once that PR goes in I expect that can be closed
16:52:05 <rhiaro> ... pr 490
16:52:18 <rhiaro> brent: looks like pr 490 may address this issue and the last ne
16:52:42 <rhiaro> manu: specifically mike jones needs to review this PR because it modifies a section fairly heavily. My expectation is you may have concerns, but it seems like the rest of the group is more or less okay with simplifying that section
16:52:49 <brent> https://github.com/w3c/did-core/issues/325
16:52:56 <selfissued> OK - I'll read 490
16:53:05 <rhiaro> brent: 325, rawsecp256r1 public keys..
16:53:24 <rhiaro> manu: this is fixed in 490 as well, we are just taking those details out of the DID core spec, we never should have been talking about the purvue of a cryptosuite
16:53:30 <rhiaro> ... that is once 490 pulled in we can close this issue
16:53:40 <rhiaro> brent: sounds like quite a few issues riding on 490, please review
16:53:40 <brent> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p2+sort%3Aupdated-asc
16:53:47 <rhiaro> ... now moving from p1 to p2 issues
16:54:08 <rhiaro> ... first is 163, use of terms shuld be linked to definitions, will be done just before CR
16:54:17 <brent> https://github.com/w3c/did-core/issues/208
16:54:20 <rhiaro> ... next is 208, the ietf did+ld+json media type registration
16:54:35 <rhiaro> manu: we haven't got ietf to review the proposal that amy put in
16:54:50 <rhiaro> brent: still waiting on that, but am I remembering that we have contingency plans in palce in the event that review does not occur in a timely fashion?
16:54:53 <rhiaro> manu: yes it's at risk, may change
16:54:57 <brent> https://github.com/w3c/did-core/issues/363
16:55:01 <rhiaro> brent: 363, clarify authorization requirements
16:55:10 <rhiaro> manu: on me, haven't doen it yet. will probably happent owards the end in an editorial pass
16:55:26 <brent> https://github.com/w3c/did-core/issues/425
16:55:29 <rhiaro> brent: number 425, did spec registries needs terminological criteria
16:55:34 <rhiaro> ... I'm hoping that this issue is part of the conversation on thursday
16:55:40 <rhiaro> ... not seeing Joe on the call today
16:55:47 <rhiaro> ... ivan was going to contact wendy?
16:55:56 <rhiaro> ivan: I put the comment in the issue from wendy
16:56:18 <rhiaro> brent: she suggests we describe the criteria and who the arbiters of the criteria are
16:56:45 <rhiaro> ivan: she also had a remark that she doesn't see any problem with the trademark part, the namesquatting and other things yes, but with trademarks we don't define any of those tersm we just put it into the registry
16:56:50 <rhiaro> ... trademark problem doesn't seem to be the problem
16:57:01 <rhiaro> ... the real thing is to have a mechanism whereby eg. racist terms are not added
16:57:08 <rhiaro> brent: hopefully thursday we will have time to get some resolutions on that
16:57:23 <rhiaro> ivan: i didn't look at the iana protocol registry, it has a long descripton of what has to be done to avoid these things, mabe we can refer to that
16:57:29 <rhiaro> ... somebody who is ore familair with this should do that
16:57:32 <brent> https://github.com/w3c/did-core/issues/453
16:57:44 <rhiaro> brent: next is 453, the relationship between VDR and DID Doc haven't show in figure one, raised by shigeya
16:57:52 <rhiaro> manu: the diagram just needs to be updated, minor editiroal fix
16:57:55 <rhiaro> brent: ready for PR?
16:57:57 <rhiaro> manu: yes
16:58:34 <brent> https://github.com/w3c/did-core/issues/463
16:58:34 <rhiaro> brent: last issue, naming classes of properties and syntax, 463 by markus
16:59:18 <rhiaro> markus_sabadello: we'v emade great progress on the ADM there is representations on production and consumption rules, there are some inconsistent terminology around properties and representation independant things and representation specific properties so this issue is to track that and harmonize the occurance of the different terms related to properties and syntax thorugh the spec
16:59:33 <rhiaro> ... there's a diagram that shows what I understood was the consensus at tpac in terms of how to name these buckets, so please have a look
16:59:45 <rhiaro> ... could use an editorial pass to make sure we use the same terms everywhere
16:59:48 <rhiaro> brent: is this editorial?
16:59:50 <rhiaro> markus_sabadello: I think so
16:59:54 <phila_> Just as aside, I published an update to the UCR yesterday. From POV, I'm close to declaring 'done' :-) https://www.w3.org/TR/did-use-cases/
16:59:58 <rhiaro> brent: thank you for coming everyone!
17:00:12 <rhiaro> ... we are making progress, please come to the special topic call this thursday, about the registries
17:00:24 <ivan> zakim, end meeting
17:00:24 <Zakim> As of this point the attendees have been ivan, brent, shigeya, rhiaro, TallTed, jonathan_holt, identitywoman, dlongley, agropper, markus_sabadello, manu, wayne, justin_r, phila,
17:00:27 <Zakim> ... by_caballero, dbuc, dmitriz, orie, selfissued, kristina
17:00:27 <Zakim> RRSAgent, please draft minutes
17:00:27 <RRSAgent> I have made the request to generate https://www.w3.org/2020/12/15-did-minutes.html Zakim
17:00:29 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
17:00:34 <Zakim> Zakim has left #did
17:00:35 <agropper> agropper has left #did
17:37:33 <dmitriz> dmitriz has joined #did