Joe Andrieu: The VCWG f2f will be in Barcelona right after RWOT, if you'd like to participate plan your travel accordingly ✪
Manu Sporny: Heads up to those going to RWOT, we will have hotel choices shortly especially for those going to RWOT and then the VCWG meeting, you may need to change hotels, we'll get a list of top 3 for both ✪
... We'll email the mailing list
... F2F is 4 and 5 March
Brent Shambaugh: Do you have the address for the venue? ✪
... In the w3c ccg github organisation, for work items that we've accepted we create repos
... some issues around the creation of them and standardisation, I realised a lot of things were in different states. I've been going around attempting to clean them up and document
... if you look in that structure, I want to draw attention to some standard files that we should be creating for you when you have a work item
... This is a comment and also a request for feedback
... There's this code owners file, for identifying who are the owners of the work item
... The file is basically used so that if someone creates a PR then these people will be automatically assigned
... You don't need to do this, this file will be created for you when you request your work item you'll identify owners and charis will take care of this part
... If there become additional owners to add or take advantage of some of the more advanced code owners features, or you don't know what's going on, reach out to me
... A file we're missing is the contributing file. That talks about the contribution policy
... I think it's important we add this by default. I helps to put it in people's faces more readily when they submit a PR
... You don't have to add it, the chairs will do it.
... This is helping ot put the IP policy in people's awareness when they contribute
... License was missing on some. It's the W3C software and document license
... Readme is a default file
... index.html is the spec text
... Any questions?
... When we've been talking about the DID resolution contributions, at this point, the creator or owner of the work item doesn't need to care about the IIP policy. The combination of these files and the licensing covers making sure people are aware of the policy, so that work item owners don't need to make additional effort in the context of their repo
... speak up if you disagree with that
... Github topics; one other thing is that on each repo, eg. on OCAP-LD at the top you'll see 'topics'
... a 'work item' one, a 'w3c cg' one. Chairs are using these to categorise say work items vs registries.
... if you have strong feedback we can update these
... Lastly, I want to show.. last week we talked about the process of creating a new work item
... there was feedback that it was a lot to take in
... I want to draw attention to.. I have some screengrabs
... if you scroll down to Work Item Process, page 4, the two screenshots at the top are the more usable replacements for everything listed in step 1
... The tempalte has the key information to prompt you through what 1 is asking for
... For whatever reason the contributors aren't comfortable with using github, reach out to us, the chairs can help
... The new work item github issue template should help make that process more seamless
... That's it for getting everyone up to speed with what's been going on
... There's going to be a lot of stuff going on in the background
... As we did the cleanup I noticed that there were ones where it wasn't clear where they were in the pipeline. We won't on an ongoing basis be taking time in the calls to cover that
... Expect the chairs to reach out to you
... One other thing I want to remind people of - if you look in the work item status
... On that page note that this is what we reviewed last week, look under current work items, those are going to be changing a lot in the next few weeks, this is a good page to look at if you want to know the status of things
... If you want to be more involved in the group, we'll be calling out opportunities
... anything that says 'needs spec text' is a good way to get involved
... We have a training guide on that
... Joe proposed an idea of a spec-a-thon if people want to gather, if they ahve questions about text generation to get on a call, make it a working session so people can learn and unblock 'needs spec text' items
... some like the DID Primer.. I need to update that one.. there's something else like the registry process maybe.. they're ready to move on to be closed after being converted to spec text
... that would be a really good way to advance items
... Reach out on the mailing list if you're interested
Joe Andrieu: Having tired to sit through the first version of the video, I was hoping to have.. to sit for an hour and know by the end of that investment I'd have the spec text repo and everything created, as opposed to watching the video when by the end i may not understand ✪
... anyone who would want to schedule an hour, after which your spec text would be created?
Kim Hamilton Duffy: I might send out a poll, that would be extremely helpful to the whole community ✪
... Work items 43 and 44.. Ryan and Lionel are owners of those; some of the efforts overlap. They'll be working together on those. Do you have anything to report on that?
... They have to do with DID security and threat modelling
Topic: New work items
... I want to formally kick off a few work items that were described in the call last week
Kim Hamilton Duffy: 1. Multihash: https://github.com/w3c-ccg/community/issues/46 2. Multibase: https://github.com/w3c-ccg/community/issues/47 3. Hashlink: https://github.com/w3c-ccg/community/issues/48 ✪
... manu described these last week. We posted it on the mailing list. As far as I can tell there are no substantive objections
... So we can consider them kicked off
... I'll go through the process of converting these to actual work items and work can begin whenever
Christopher Allen: I just want to make the statement that there is one small step in there we missed speakinga bout, which is those 3 work items, the chairs believe there is sufficient community support for to continue ✪
... there is a check. A week goes by and there are no objections, but the chairs may decide to wait a bit longer
... It's a chair decision. Doesn't apply to any of these, there are multiple people/companies involved
Kim Hamilton Duffy: Two have issues, one we don't but we'd like to hear the introduction ✪
... First is DID resolutions
Markus Sabadello: Dmitriz and I have been working on a document for specifying DID resolutions for a while. There is an existing repo ✪
... we think it makes sense to have a separate spec for that. There is a lot of community interest. The document has a bit of initial structure, a number of topics and sections
... Covers topics such as resolver architecture, what does it mean to have a hosted resolver as opposed to in an app or browser; what are input parameters to DID resolution; what is its potential output
... Talks about things like service selection, service endpoint construction, caching, verisoning, revocation and other things that affect the resolution process
... Quite a few people have expressed interest in this being a work item
... dmitri and I thought we would send out information on how to contribute
... We'll make a proposal. There are some issues already with some good discussion points
... One question would be what will be the delination between DID resolution and the main DID spec. THere are some issues on the main spec that would be more appropriate for DID resolution. We'll figure this out.
Manu Sporny: +1 For moving DID Resolution specific issues in the DID Spec repo to the DID Resolution repo. ✪
Kim Hamilton Duffy: For this topic, there will be quite a bit of interest and it will definitely need some break out sessions. These we'll probably do in a similar manner to the did hardening process. The timing and cadence of those can be figured out over time. What we would do for sure is follow a similar process where we're still scribing and recording everything, with IP protection etc ✪
... If you're interested in participating in the DID resolution spec, please let us know through the mailing list or reaching out directly
Manu Sporny: +1 To support the work. A number of the companies in work depends on there being some kind of resolution spec ✪
... The quesiton I have is around implementation - we have a couple floating around, the DID io implemntaiton that DB has done can do Veres One resolution and we want to add Sovrin resolution and any other did method that seems like it's getitng traction
... That raises the question about test suites, is it a data model only spec, is it an API..
... We already have multiple implementations, I'm wondering how soon the test suite stuff might start as a result of that
Markus Sabadello: Not sure I understood. When we'll have test suites? ✪
Manu Sporny: One of the thing you end up creating to go with a spec is a test suite, and the question is what would the test suite look like. Or do you feel like there's plenty of spec work here? ✪
... if you're working on a data model spec the test suite will look very different than if you're working an http api binding and a data model
... are you trying to do something with a broader scope; a data model for requests and resolvers in addition to an http binding
Markus Sabadello: Definitely both, there are some things on the data model side. The primary DID data model is still in the main DID spec, not in DID resolution. but I think there would be some additional data model concepts specific to DID resolution, particularly to do with versioning and caching, we'd define additions to the data model ✪
... but we'd also define APIs. An abstract definition for DID resolution functions, an abstract API and then there could be bindings such as an HTTP binding
... we could have test suites for all of those things
... Are test suites a separate work item?
Manu Sporny: Typically the test suite is ina different repo but it's bound to the work ✪
... At some point if it's going to go standards track, you need a test suite. Starting the test suite before the WG is a pretty strong indication that it's fairly well thought out, especially if you can show two implementations
Dave Longley: Spec needs a test suite w/two independent implementations to get to Recommendation status at W3C ✪
... It's a part of the work item, but a different reposityr
Markus Sabadello: Then let's do it, I know there are 4 or 5 different projects implementing DID resolution, there's a list ✪
... They're far enough that we could work on test suites, that's a great idea
Kim Hamilton Duffy: I can start the repo for that. In the kick off calls there will be discusison about breaking up that work ✪
... Expect a followup email to reiterate the kick off of DID resolution
Joe Andrieu: The goal of this is to pull in the work on the functional identity primer from RWOT ✪
... Get feedback from the CCG. Iterate as necessary. Hopefully get it published as a Note
... The functional identity approach has three components
... The first is to ask folks to talk about identity from a functional perspective. How we use it, rather than the political aspects
... The second is a definition of identity. The definition from ISO is not functional
... It has some interesting complications
... The third part is 10 terms that we've defined, 5 nouns and 5 verbs, assets and processes, to get it into our conversation in the CCG, and publish it for guidence that could have wider reach
... Probably a lot of you have already taken the survey and this is just following the process so it's accepted as an actual work item
Kim Hamilton Duffy: Oh I thought you had a proposed new one.. is this the existing one? ✪
Heather Vescent: In the discussion about having participation in the feedback survey I had this idea that we could do one for a broader audience and I don't know if I want to sign up for that ✪
Heather Vescent: I think it was getting ahead of itself a little bit, maybe we shoudl focus on this survey, the one that's in progress right now, until the end of this month ✪
... It's not an inconsequential amount of work, it's a piece of research
Manu Sporny: +1 For focusing on the current survey. ✪
... There's going to be analysis and a report
... We're going to have plenty of feedback from that. I'm not sure if it's useful to get a broader look at things right now
... I'd be happy to do it, it's just will we be able to take action? This community takes technical action, it doesn't take action on the non-technical adoption or education in this space
... is my understanding
Kim Hamilton Duffy: Yes, so I think possibly.. right the end of year survey, that should have been work item 2, you already have the information supplied for that, it's in process ✪
... I'll update our bookkeeping step on that to note it's already underway. The follow up one, we'll put that on the back burner
... This is a lot of work for now
... This one already is a work item
Heather Vescent: That was my understanding, it was housekeeping because this survey came ad-hoc ✪
... Not everyone was on that call, the survey was the right way to get feedback. Then, scope creep..
Kim Hamilton Duffy: To your point about focussing on technical items, I think we would like to be better at other aspects, but point taken that we show up more on the technical space than others. If anyone else on the call would like ot get more involved in that, it would benefit the community greatly. ✪
... it's just up to us now to get the bookkeeping correct. Please fill out the survey if you haven't already
Bohdan Andriyiv: I have a quesiton about hashlink spec ✪
... I think it's a great specification, and strange it didn't exist earlier
... My question is how to implement this specification in practice, in particular when we create hash of the resource, how to know what needs to be hashed?
... There is no explanation where the content the resource returns starts
... The second question about hashlink maybe we can add to the spec, how to locally store content. In metadata we can add links, but no example how to reference locally stored data
Manu Sporny: That makes me happy, the hashlink spec was partially written for you, from use cases in the VCWG ✪
... The answer to what do you hash is basically the content that's returned to you. When you do an HTTP GET the data stream that you get back, not the HTTP headers, the actual data blob, that's the thing that is hashed
... There are other things you can put in the hashlink description like the content type
... It's meant to be super simple
... You've got a URL. you GET the URL, and the raw byte stream you get back is what you hash to make sure it matches
Bohdan Andriyiv: I think it's goign to be a long conversation, I will write an email ✪
Manu Sporny: Is there a repo that goes with the spec? [scribe assist by Dmitri Zagidulin] ✪
Manu Sporny: In response to heather. +1 to focussing on the narrower end of year thing and not expanding scope yet ✪
... We can do a second survey later. I agree with all the rationale.
... The other question.. I heard two things. Joe said it and Heather and Kim said it.. what we focus on in this group is the technical stuff... it's somewhat true but we do want to change that. We do want to focus on educaiton and outreach and how we get the message out, otherwise we're just naval gazing and not doing the right type of out reach
... some of that happens at RWOT, some at TPAC, but primarily we're focussed on the technical topics, but we shouldn't lose sight that there are other community members that would probably be more interested in doing the non-technical stuff and helping us to communicate this stuff externally
Heather Vescent: The comment about technology and going beyond, I definitely feel like it's an aspirational only from my direct experience with the group as a non-technical person. You're really good at all the technical stuff, so I think that if there's real desire to change that there has to be real change in the group ✪
Manu Sporny: +1 To what heathervescent just said... I think it's a cultural thing... ✪
Joe Andrieu: What we noticed when the chairs talked last friday, it's fairly clear that getting the DID spec going is high priorty. There's a ton of stuff wallowing. Over 60 open issues and 9 open PRs ✪
... I want to go through those PRs in reverse chronological order and get a sense of whether we can close or merge these
... Most of the conversation we want to direct to the PRs themselves on github. We don't need to dive into it, just identify if they're ready to go or need more work
... 55: allow DID methods without update and delete. It does have some conflict so we can't merge it right off
Manu Sporny: This was not communicated, it happend ad-hoc. rhiaro is going to be triaging as much as she can and we did sit down a couple of days ago and triage all the PRs. There hasn't been any movement on it yet.. ✪
... Many have merge conflicts, and the conversations died down
... There's another item which is Needs a new PR
... it's good in concept, but needs a new PR to make it happen
Christopher Allen: My comment was that which of these PRs have some larger questions than.. the first one (55).. I think have some larger questions that the community doesn't have consensus on ✪
... If you can clarify which ones have these larger questions
Manu Sporny: We can move stuff out to raise new issues for the larger questions ✪
Kim Hamilton Duffy: Next week we'll be talking about DIDs and for the forseeable future ✪
Michael Herman: Do people have an idea of the process for going through the issues? Maybe there are some larger overarching issues we need to deal with first before we get down to the nitty gritty ✪
Joe Andrieu: One of the things that became apparent is that if we had resolved some of the PRs the issue wouldn't be there. So we look at the PRs, then return to the issue list ✪