The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back


Credentials CG Telecon

Minutes for 2021-02-10

<heathervescent> We will be starting momentarily, giving folks a few minutes to join.
Mike Prorock: Correction: Traceability Vocab
Manu Sporny is scribing.

Topic: Introductions / Reintroductions

Heather Vescent: Anyone new that would like to reintroduce themselves?
Heather Vescent: Anyone on the call that would like to introduce themselves?
Heather Vescent: Anyone that hasn't introduced themselves in a while that would like to introduce themselves?
<dmitriz> oh cool!! I know Highland Sw!
Chris Winczewski: Hi, Chris Winczewski, we were Learning Machine, now we're Hyland Credentials - been in the community for a while -- good to be here.

Topic: Announcements and Reminders

Heather Vescent: We have Thoughtful Biometrics workshop for date change. Kaliya, what's the new date?
Kaliya Young: March 8th, 10th, and 12th
Kaliya Young: We're inviting folks who work as biometric scientists, identity manage and civil society concerned about the previous two.
Heather Vescent: Any other anouncements?
Kaliya Young: Internet Identity Workshop April 20th - 22nd -- it's coming up.
Heather Vescent: An email went out yesterday about CCG Election.
Heather Vescent: I wanted to go over a brief timeline.
Heather Vescent: If you look at election timeline, we had to wait to announce until the charter was updated and time to register issues ended yesterday - election will open on March 10th... one month from now, starting from yesterday until Feb 23rd is nomination period. Anyone can nominate themselves -- send name, affiliation, and statement.
Heather Vescent: In order to vote, you need to be a member of the CCG by yesterday... if you joined today, you won't be able to vote or self-nominate.
Heather Vescent: The nomination period will conclude, midnight pacific on Feb 23rd. The following day, Feb 24th, we'll have candidates speak at CCG meeting. Voting will open on March 10th. You'll have one week to vote. Voting will close on March 17th. We will be using ranked choice voting.
Heather Vescent: Details on procedure will be provided before then -- ranked choice voting cornell is useful.
Heather Vescent: We hope to have votes by March 22nd -- new chair starts on March 24th -- this is a 3 year term... When Chair seats expire, there will be new votes.
Wayne Chang: Two weeks for charter amendment passed w/o strong objections. We've made updates to the draft based on concerns, moving forward to move with Ivan to update charter on website. Just giving an update.
Manu Sporny: Quick note about voting site: opavote that is useful for doing rank choice voting, works well and is free. [scribe assist by Heather Vescent]
Heather Vescent: I hope we have various people interested in running for co-chair -- very interested to see who is interested. I personally would like to see multiple nominations -- would like to see voting among multiple choices.

Topic: Progress on Action Items

Heather Vescent: 179: Https://github.com/w3c-ccg/community/issues/179
Heather Vescent: A couple of weeks ago, during Verifiable Request meeting, proposed work item was proposed -- in last week or so, Gabe who proposed this, initially proposed as being a lead -- he's unable to do that. I don't think we have two formal leads on this. Wanted to alert the community that if there are not two leads from different orgs that want to take a lead, this is likely going to be closed w/o becoming a new work item.
Heather Vescent: Is there anyone on the call that would like to become a co-owner for this work item?
Heather Vescent: If we do not have some new leads to take this work item on in the next 14 days, we'll close this issue until someone is able to take the lead on this.
Heather Vescent: 136: Https://github.com/w3c-ccg/community/issues/136
Heather Vescent: The only other issue I wanted to bring up was issue 136 -- learnings from last co-chair election. Lots of discussion on this thread, we used this thread to resolve the concerns on election charter amendment, since we did that -- I will publish it onto the website.

Topic: Updates on Universal Wallet

Heather Vescent: We have Orie Steele and Mike Prorock here to discuss.
Orie Steele: We've made progress on universal wallet interop - healthy chatter on Github issues, potential integration points w/ Hyperledger Aries - some specs in OpenID on credential issuance for JWT and Linked Data Proof credentials. There are threads on those issues in the repo.
Orie Steele: We have also published some react/storybook components - there's been updates to React components that implement some of the interfaces. Sample implementations and plugins have been updated. Mostly updated to newer cryptographic dependencies.
Orie Steele: One of the most exciting updates is encrypted data vault replication -- replicates between local wallet and remote wallet. EDVs being worked on as joint work item for CCG/DIF. Universal wallet uses EDVs for backing storage and sync.
Manu Sporny: What's the timeline & roadmap? [scribe assist by Heather Vescent]
Orie Steele: What we're looking to do is describe in JSON-LD connection points between VCs, DIDs, key management software, and EDVs. We're aggregating JSON-LD and JSON objects and describing them in the spec.
Orie Steele: As people find what they want to express, we'll make sure there's a place that documents that. It's a CCG work item, I would expect at some point, we'd want to put it into a more rigorous standards process. I don't know what the timeline for that is. We might want to do other things before we do that.
David Chadwick: You probably know that in the SSF project, there is a universal backup service being developed -- one of the issues being raised, what happens when wallet backs everything up to universal backup service, how do they recover the wallet? They said that's still an item to be developed.
David Chadwick: Any thoughts on that?
Orie Steele: Yes, the feature I explaiend about EDVs is one solution to that problem -- you can replicate local wallet content to a remote server. you can replicate that with keys that are not just in one place, but encrypt that content for multiple recipients, if you include local phone-bound keys... if you only do that, you're screwed when phone is destroyed.
Orie Steele: However, with multiple recipients in EDVs, you can ensure that both your desktop and phone has decryption keys.
David Chadwick: Oh, so if I had laptop and phone, I could backup from one to the other.
Orie Steele: Yes, although that's a feature of EDVs -- not of Universal Wallet specification.
David Chadwick: So, hardware keys on phone and desktop are not an issue, as long as you have one of them.
Orie Steele: Yes, although key management is out of scope for EDVs.
<rouven> +q - re. secure wallet work
<davidc> ssf -> eSSIF
Michael Herman: Orie, you and I are on Encrypted Data Vault, still in early specification stage, yet less familiar with Universal Wallet effort -- sounds like you're fairly far along with implementations of EDVs, how do both of those things come together.
Orie Steele: EDVs were originally funded as a part of DHS work a few years ago -- Digital Bazaar was the initial author and vendor that implemented EDVs. Transmute implemented before the work was moved to CCG/DIF -- we implement the same version of EDV API. That's what we've built Universal Wallet functionality around. We're trying to keep the APIs aligned.
Orie Steele: As you're aware, what we have works for at least 3 vendors. From a timing perspecitve, there are still features we're working on, and will continue to work on those, any changes we make to specification will have to be implemented by all three vendors.
<michael_herman_(trusted_digital_web)> Thk you Orie
Orie Steele: While we wait for those changes to happen, we do have working implementations.
Wayne Chang: Two things - first, highlight importance of working on these specs wrt. governments that work for them. Recently, Experian pulled otu of a deal and left 2 million accounts unaccounted for. I think the work we're doing here is important.
Wayne Chang: A part of the vocabulary useful to folks here -- MUD test -- matthew greene came up with this term. It means that if you slipped and fell into the mud, all devices ruined, would you be able to recover your data.
Wayne Chang: If you have true custody of it, you can't recover -- whether or not that's approrpirate for all use cases, whether you need guardianship, that's a separate topic, but interesting wayt to think about this.
Adrian Gropper: Those of us that see the world in terms of authorization servers, look at mobile wallet and custodial wallet differences, how does Universal Wallet spec deal with (or doesn't deal with) custodial wallets.
Orie Steele: Great question, it doesn't care about wallet -- cares about profiles and grouping of content -- you can group things in personas, it has things you only share with certain other people/orgs.
Orie Steele: There is certain other content that you'd only share w/ you best friend.
Orie Steele: The purpose of Universal Wallet is to describe wallet content in JSON-LD -- it doesn't have an opionion on what kind of wallet you have -- just the contents of the wallet.
<phil.l> A naive question: to what extent are the EDVs referred to here compatible (?) with Solid's Personal Online Data Stores (PODS) or are these orthogonal solutions?
Adrian Gropper: In today's GNAP meeting, issue came up -- how will GNAP be sure that we're not locking out SSI type initiatives by being too HTTP-centric. So, the question I have -- if the custodial implementation of universal wallet is custodial based, how do we square that circle? How do we then present relationship between DID Comm and other messaging protocols in context of what we're doing here.
Orie Steele: The interfaces for wallet interfaces are abstract, you can implement over anything -- we don't know how those wallet interfaces would be implemented, don't know if they're all exposed or not exposed externally/internally... we just describe the interfaces wrt. wallet content.
Orie Steele: For example, we don't say how you get a Verifiable Presentation to a verifier... it speaks to contents of wallet and key material.
Rouven Heck: There is a new WG Charter at DIF -- wallet security, all about things around wallets. Authority in germany that issues passports, they want to understand what wallet security features are supported -- hardware wallet, key exposure, these questions came up -- we want to get a broad audience involved -- there's a mailing list now -- we'd like representaiton from community on this.
Heather Vescent: How should folks respond to that? Directly to that document?
Rouven Heck: Yes, providing feedback on document would be good.
Rouven Heck: Sending questions to mailing list might also be good.
Rouven Heck: I'll send email to mailing list.
Heather Vescent: Yes, that would be good.
Manu Sporny: The universal wallet spec threw me. It sounds more like a "what's in your wallet" specification. Is that the purpose to document what you put in a wallet? So when you move your wallet from one provider to another, the providers have an idea how to handle the data in the wallet, based on the format? [scribe assist by Heather Vescent]
Orie Steele: The introduction says what you just said -- content for digital wallet and interfaces to wallet content -- it might may make reference to DIDComm or HTTP, it's purpose is to explain how key material is related to VCs. Your wallet might have keys -- unify those data models -- some discussion in moving those out to separate specification, not now, but maybe later.
Orie Steele: If you move wallet content from one wallet to another -- how did you express taht to user before you made that transfer, or are you going to require user to understand what they're going to lose when they transfer.
Orie Steele: What wallet vendors support what interfaces? Some will support credit cards, others cryptocurrencies, others both.
Orie Steele: You would not want to transfer from one vendor to another w/o losing what you're giving up.
Orie Steele: Yes, interfaces describe that, but in the abstract... most of spec provides consistent definitions about what's in a wallet.
<orie> Thanks!

Topic: Traceability Update

Mike Prorock: Traceability Vocabulary - I'll cover that.
Mike Prorock: This kinda kicked off with the start of the DHS SVIP program -- Transmute started it during last year - 4-5 companies engaged and getting good visibility from GS1. Key goals is to standardize a set of vocabularies that are common across supply chain vendors.
Mrporock: Easy way to think about that -- no reason to redefine location or address when it's already been done in GS1 or schema.org -- a way of consolidating that information, and provide additional vocabulary when there are gaps, especially on the JSON-LD side... for example, agricultural inspection, chemical testing, contamination testing, etc.
Mrprorock: Similar use cases around oil and gas, steel, timber, etc.
Mrporock: We are heading towards an annual major release schedule... Q1 2021 will pin a version of this... end of this month to allow clean set of versioned vocabulary objects to be used across VC HTTP API across supply chain companies.
Mike Prorock: I'll pause here for any questions.
Wayne Chang: As an implementer, what are the best places to get started on traceability vocab -- what would be interesting in whole flow of issuance, storage, verification.
Orie Steele: You may also want to look at:
Mike Prorock: Yes, over VC HTTP API or Linked Data (JSON-LD) -- been bumping up documentation quiet a bit -- if I add "new inspection type or shipment type of X" -- the way to start is JSON Schema definition and series of steps where JSON Schema being used thanks to magic from Orie, generate JSON-LD file then generate test suites through the path - validation, etc.
Mrprorock: Schema to JSON-LD to Schema doing it in a programmatic way that will scale -- other benefits that we see internally, generation of data for demonstration purposes.
Mrprorock: re-use generators, generate valid and invalid test cases for Linked Data to generate sample data to work with -- demonstrate use cases.
Mike Prorock: If you find any issues in documentation, please note it -- we've been trying to make this approachable to enterprise.
Manu Sporny: Seems like its on the trajectory to grow to size of schema.org. What's the thinking on how to manage that growth? [scribe assist by Heather Vescent]
<michael_herman_(trusted_digital_web)> Have you looked at the UBL 2.2. specification for the 80+ most common business documents: http://docs.oasis-open.org/ubl/os-UBL-2.2/UBL-2.2.html#S-UBL-2.2-DOCUMENT-SCHEMAS
Mike Prorock: Yes, good question -- we don't want to duplicate things that are done elsewhere. How do we reuse, point back to where something exists -- back to GS1 or schema.org or EPCIS and leverage that.
Orie Steele: Re UBL yes, we looked at it, but feel free to open an issue to discuss its inclusion :)
Mike Prorock: There is also this notion of common elements across supply chain -- places, locations, bills of lading, and then there are subject matter terms -- this has not been standardized as a group -- but way it's leaning -- we will start seeing patterns that have "Inspection" and then subtype "Agriculture Inspection" then subtype "Contamination Agriculture Inspection".
Mike Prorock: So, this gives ability to speak an API wrt. "Inspection", but specialize "Steel Inspection" -- commodity specific, trade specific segmentation.
<orie> Use w3id.org.
Wayne Chang: Just wanted to mention about how -- infrastructure task force, next week or following -- figuring out how to manage context in vendor neutral way -- whether we collaborate with w3id.org, could talk w/ W3C Management -- potential of interop profiles, GS1, or other groups in other sectors. Companion interop specifications -- vendor neutral way to host everything that governments and large enterprises can depend on.
Wayne Chang: Potential work item -- fantasy work item for me -- specify orchestration of these VCs using domain specific language... Business Process Modelling Notation -- they must have this field, have this family, could model overall flow.
Wayne Chang: There is PetriNets, that is isomorphic to business process modelling notation -- interesting work item for orchestration.
<orie> We've using BPM before... its pretty great
Orie Steele: The way to collaborate on these items, go to github, ask questions, discuss.
Mike Prorock: +1

Topic: Secure Data Storage Working Group

Dmitri Zagidulin: I'm Dmitri Zagidulin, working on Confidential Storage Spec alongside Kaliya, and Tobias... as well as Editors -- Orie, Manu, and Daniel.
Dmitri Zagidulin: Most of activity that takes place is in that Github repository - we have weekly calls on Thursdays at 4pm ET.
Dmitri Zagidulin: That's a link to the specification
Dmitri Zagidulin: That's a link to slide deck that introduces SDS work... talks about what problem we're solving, layers, what charter is, etc.
Dmitri Zagidulin: Structure of authorization -- many are familiar with WG, so what's new?
Orie Steele: And here is an open source EDV client: https://github.com/digitalbazaar/edv-client
Dmitri Zagidulin: We now have an example implementation in confidential storage repo itself -- we have an open source implementation -- tests and test vectors to ensure we're interoperating. Conversations so far have been about authorization methods and replication use cases. This weeks call is going to be on interface between lower level EDV spec and higher level Hub spec.
Dmitri Zagidulin: We're trying to nail down interop layer between the two so two layers can work in parallel
Dmitri Zagidulin: Touching really quickly on Michael's question on state of spec vs. implementation.... like many standards groups -- we've come together after implementations have been made... implementations are informed by implementation experience... The group has laid down use cases, separate use case document in spec repo -- have discussed on previous calls other components/layers - are moving towards finalizing remaining pieces of EDV spec.
Heather Vescent: Feel free to ask questions.
Dmitri Zagidulin: Please join the group, join the calls, contribute to the repo.
Wayne Chang: I'd love to zoom out a bit, contextualization of the work -- what other parts of the ecosystem would that work interact with and in what way?
<orie> /me wonders when WebKMS will be updated...
Dave Longley: For example: Where do you put your wallet contents/VCs/capabilities? ... one answer is: in EDVs.
Dmitri Zagidulin: Our work very much depends on having some other components -- key management, you need to manage encryption keys -- we leave key management out of scope -- other WGs/Task Forces can specify / recommend what KMS interfaces are -- what are recommended key suites, that's one set of specs that we intersect with but do not specify.
Dmitri Zagidulin: There are wallets as well
Dmitri Zagidulin: Also, authorization specs -- so far main authz specs in consideration are GNAP, and Authorization Capabilities (zcaps), and HTTP Signatures for proof of possession.
Dmitri Zagidulin: So, in summary, wallets, key management systems, authorization specs.
<orie> thanks manu!
Heather Vescent: Ok, to engage follow up with SDS WG.
Heather Vescent: Thanks all, have a great day.