Topic: Drawing the line on DID Methods in/out of CCG Scope
Chairs have had discussion on in/out of scope: don't include every DID method in scope. What is criteria to include a DID method? ✪
A DID method that supports community goals, across community, or multiple people within community working on them, then these would be included in scope. But we still need more guidance on what is or is not in scope. ✪
Last time primary objection was whether it relied on blockchain. Two methods do not rely on blockchain. Suggest focusing attention on this aspect. These criteria should be applied equally: regardless of whether these rely on blockchain, these should be accepted. ✪
There is at least one method, maybe more, that rely on a particular blockchain, versus something that is agnostic to particular blockchains. For consistency sake, might want to clarify this. ✪
<markus_sabadello> +1, excluding specific technologies makes no sense
<orie> ^ especially if such discrimination is part of blocking "standards track".... DIDs and VCs started as community work items...
<mprorock> @markus exactly - we absolutely do NOT want to exclude ANY specific technologies
<cel> ... If multiple people want to work in the community on a DID method that supports community goals but does use a work item, ... if approved it would be a legit work item.
<cel> ... It is a scope question.
Ted Thibodeau is scribing.
<kim> I don't see any reason to modify the usual criteria -- if at least 2 people from different orgs offer to lead it, then it's good
<cel> ... If leveraging bitcoin, cool, seeing approaches apply to multiple things... that should be clear.
<cel> ... Other thing to be careful about... when we are looking at specific work items... is it working on something that can ultimately become a standards item?
<rgrant> I don't think that we want to "be careful" but that we want to foster innovation.
<cel> ... Doesn't have to necessarily, but let's get the conversation going around the criteria, as a community.
<cel> ... CCG is getting more active - more work item proposals - need to evaluate.
<cel> ... I think I am kind of reiterating the obvious, based on the criteria stated, based on the criteria (we, chairs) agreed on as a guideline, these would be approved... and we would request did:tz to be withdrawn.
<rgrant> Ahh, there it is, "rehome" my DID Method.
<orie> moving community work out of the community seems pretty bad form....
<cel> ... If accepted I would like to see the same kind of designation applied to previous ones... did:v1, did:btcr, maybe others.
<orie> why are we considering "not accepting work items the community wants to work on" ?
<cel> ... Wayne, did you have comments on the proposal to accept pkh as a work item and withdraw did:tz?
<dmitriz> (incidentally, we should probably not use 'grandfather clause' terminology, and substitute with 'legacy')
Topic: BBS+ signature scheme for LDP using JSON pointer normalization
<cel> ... This is interesting because BBS uses a multi-message payload to sign documents, currently it is obtained using JSON-LD processing (URDNA2015). This proposal is to use JSON Pointer Normalization instead, to merge the document into a form usable in a multi-message format.
<cel> ... JSON Pointer is on IETF standards track... looks similar to JSON Path... A complex JSON document can be flattened into a single JSON document.
<cel> ... The POC document shows how a document can be converted... Whether it is JSON-LD compliant or not.
<cel> ... The linked data proof specs specifies some terms around canonicalization algorithm, which can be used to specify how the document was canonicalized before signing, in addition to signature algorithm and other items.
<cel> ... Thus far this has been the RDF canonicalization, with the exception of JCS...
<cel> ... Using this, the signature suite could be extended...
<cel> ... Because JSON Pointer operates on JSON documents, it works on both embedded and wrapped signatures.
<cel> ... So it can be used with different signature suites.
<cel> ... There are no work items in DIF right now that are relevant to this specific work item - the linked data proofs.
<cel> ... However, there efforts to bring this... to JOSE. No dependency in required work.
<cel> ... Any other questions from the community?
<cel> ... I think we'll give this the 7-day review and then can open it as a work item.
<cel> ... Thanks for coming today, and for being brief and on-point.
Topic: VC Guide
<cel> ... Next: VC Guide. Are Michael Herman or David Chadwick on the call?
<cel> ... Need a new repo. Trying to migrate to ReSpec.
<cel> ... It's just to have a separate repo that can be linked from the VC HTTP API.
<cel> ... It would still be discussed on those calls by that group, just need a separate repo.
<cel> ... As part of trying to make it more intelligible... business partners needed more context...
<cel> ... That weekly meeting is largely about technical stuff. There is a parallel work track, people working to make use cases supported by that API be explicit so you can point to use cases from the main meetings.
<steve_gance> (scribe lost internet for 10 minutes)
<heather_vescent> Steve, Cel took over scribe for you.
<steve_gance> Google doc now, will be moved to respec.
<kim> I think we should have that person write up their concern. this is a huge deviation from how we've accepted work items in the past
<steve_gance> Jaun: Part of the problem is that businesses don't address the concern, e.g., goggle cloud wants to make something that doesn't work for anyone else. Concern that multiple companies can also do things that are too narrowly scoped to benefit the larger community...
<heather_vescent> OK, so it's clear we need to decide on scope first, then review these work items.
<mprorock> would like to yield time to wayne
<heather_vescent> I was wrong in thinking we could decide on these work items with the non-specific guidance at this time.
<orie> playing games with "rehoming work" is a slippery slope that will fracture the community and cause needless pain... the scope of ccg work should be limited only by the tools we have at our disposal... not political or economic interests of companies or non profits or governments.
<heather_vescent> it wasn't a concern about accepting work items.
<heather_vescent> Juan + Wayne, can you add your intent to the github thread?
<kim> Just to be clear, not saying btcr should be retired, just saying that if anything, it should be retired due to inactivity, NOT because it uses the bitcoin blockchain
<kim> And Ryan's comment is addressing the inactivity concerns
<steve_gance> BTCR has a 2.0 that we are working on. We are in the middle of scheduling additional work. Some of the people on this call are active on this DID method...
<steve_gance> I don't think BTCR being here is a burden.
<juan_caballero_(spruce)> i think that BTC might be quite different from ETH and TZ in that it doesn't have development funds, which make feel even further from the allegation of being specific to a bundle of shared economic interests
<rgrant> Not just across companies, but across DID Methods!
<orie> sorry gonna need to drop, please don't decide to exclude folks who want to work together while i'm gone ; )
<steve_gance> My inclination would be along an inclusivity path. There is a lot of discussion that could happen, let's move it to github and bring it up as needed.