Reintros: Drummond from Evernym, Chief Trust Officer, chair governance wg, working on DID spec for long time (editor), involved in other standards in ccg ✪
Christopher Allen: 88 -- Ongoing prob on how/where to store context for docs. where do DID methods store ...e.g. edu verifiable claims TF ✪
Orie Steele: Wg...locs....holding off on pr ....to keep evolving ....we can close and reopen when clear path fwd.... how best to contribute to json-ld .... ✪
Christopher Allen: Verifiable claims wg moving to....charterized....what is final approval? [poss JAN] ✪
Christopher Allen: Need process ..repos/issues need to cont in wg area. discussions/non-wg docs are in ccg. 09 JAN, end of day ET is last vote ✪
Christopher Allen: Must get votes. ...process flows, discussions convos will happen here but it's up to members in formal wg to accept them as poss items to add to official wg ✪
Christopher Allen: People on old list not in active wg. has that email been sent? ✪
Dan Burnett: No. mailing list is still active, not closed. try now ✪
Christopher Allen: Housing schema for curren json-ld sigs ✪
Orie Steele: We have a work item for transmute + workday to use json-ld schema and context ...transmute's work w customs....ex is self-hosted in repo... ✪
Christopher Allen: Doesnt conform to context...valid context to sign it not there ✪
Christopher Allen: Process things ...need to revise in charter.... do in start of yr....need chairs to faciliate...need election...term is 2yrs...been in place for 3....need to update ccg processes ✪
Dave Longley: [scribe assist by Christopher Allen] ✪
Dave Longley: The pastebin did is correct and conforms to context....json schemas is soemthing diff....we have ld vocab ✪
Christopher Allen: 1-Yes on context. 2- not a signed doc. ...to support it. have newer code... ✪
Joe Andrieu: Chris said 2 things: 1- update charter; 2- elections. plan is jan. ✪
Sumita Jonak: I am curious as to what the requirements are to formally be a part of the election process. USAA is still pending membership... hesitant to scribe because we're lurking. What are the requirements? [scribe assist by Manu Sporny] ✪
Christopher Allen: You don't have to be a W3C Member, you just have to be a CCG member, which anyone can do. [scribe assist by Manu Sporny] ✪
Christopher Allen: Don't have to be w3c member for ccg. can join as indiv ✪
Christopher Allen: Existing repo under DB...should be moved since approved as work item. ✪
Joe Andrieu: Look at DB repo, few misconfigs, don't worry, will fix.... intention is to move into repo ✪
Manu Sporny: What we care about with any specs is that the IPR is clear. history of doc, mods/issues/etc must be preserved. ideally would transfer ownership from db to ccg. It's easy to do; could fix in header of spec. w3c ipr regime. click button then pull into ccg repo. web kms repo might cause issues. coord offline ✪
Christopher Allen: Can delete it if needed (web kms?) ✪
Manu Sporny: Many ways to move to preserve history. ✪
Manu Sporny: Orie from Transmute joining as editor ✪
Manu Sporny: May be useful to go back over spec. ✪
Joe Andrieu: Understand how web kms intended to fit into arch ✪
Manu Sporny: Ecosys that we're putting together has variety of components: aries...agents....digital wallets...personal data store...id hubs...enc data vaults... aspects not talked about , decentral kms. web kms. key mgmt part. clear: don't have strong feeling about web kms. it is 1 way of doing it, optional, not the only way. interoperable km. ✪
Dave Longley: We have JavaScript open source BSD-3 licensed libraries for Web KMS here: client (https://github.com/digitalbazaar/web-kms-client/tree/http-sig) and switch, a component to plug into a server (https://github.com/digitalbazaar/web-kms-switch/tree/http-sig) ✪
Manu Sporny: Sec 1.2 has use cases/reqs. why are we doing this spec? already km apis exist ...webauthn uses hw backed keys for dig sigs. fido keys. ...personal hw via web. web kms complementary to FIDO. look at azure, digital ocean....propreitary hw secure kms, interfaces are non-standard. so web kms tries to build UI into propreitary and open ones ✪
Manu Sporny: Kms = black box that verfies sigs, protects keys, enc data, decrypt. simple/straightfwd ✪
Manu Sporny: Near impossible to exfil priv keys from kms. math proves it. ex: dig sig was generated on yubikey. all matters for high-risk use cases for $$$$$. or medical lics, or academic creds, barred med lic, ....in a nutshell that's web kms. ...ways of securing tx ✪
Christopher Allen: Same terroritory as ss keys, recovery (indiv + socioal), support multi-sig...cooperate ...quorum....multi-people/multi-sig...or just wrapper around FIDO api. ✪
Manu Sporny: Mostly just wrapper around FIDO apis....aws, azure. foundational layer. multi-device sig...recovery....hae to care about those use cases. stuff done igher in stack, built on top of web kms ✪
Christopher Allen: What's in your wallet, topic paper. has diagrams on pieces in id wallet. unclear where kms fits in that diagram. iterate on it and need to understand the larger wallet arch fit for web kms ✪
Manu Sporny: Need a good diagram to show where web kms fits ✪
Jonathan Holt: Resservation: web wrappers around tools, pki, responsibility to do it right ✪
Adrian Gropper: Separation of consent as relates to access. Curious if any ix between web kms and storage Access control protocols, or is it separate? verifiable credential visibile at level ✪
Dave Longley: Web kms client ...switching btwn kms modules... responding to CA wrt who has key recovery control. concept of key stores in web kms w controllers to specify and how youmanage them is handled at diff layer. works cleaning w auth capabilities, sign w diff keys, perform diff ops w diff keys, delegation, http api or via web app to invoke diff kms apps ✪
Orie Steele: Yes please! single interface for things that do key management and signing... write one integration, portability across phone, browser, azure, aws, google, etc.. ✪
Manu Sporny: Jonathan, correct -- huge responsiility to design correctly. heavy security eng. not web only. orie/i have been talking: poss to define api, local, used by local apps that everyone can propgram...goes to mobile, uses SE to do something. works with SE to invoke key on remote sys (another web kms) looks like local call but is to someting you control or trust. from dev persp, you don't care if api is reaching out ... it is beyond http api. interest in plugging into FIDO. ✪
Dave Longley: WebKMS + EDVs layer and play nicely. ✪
Manu Sporny: Not http only, local apis too. adrian, sep of concerns ...we want it betwn various subsys. expect ares agent or digital wallets will IX w web kms to do digital signing , issuing creds, accessing data hub or crypto auth ✪
Dave Longley: WebKMS + signing VCs layers and plays nicely. ✪
Orie Steele: WebKMS + Agents as well. its the solution to the non standard key and signature interfaces we are all using today. ✪
Web kms designed to play nicely with all these systems. Having a standard way reduces dev burden and inc adoption rate ✪
Dave Longley: +1 To manu. standard interface to hook up kms mod in background ✪