Kerri Lemoie: Reminder to join the mailing list. Tomorrow's CCG call will feature a topic that's been on the mailing list about delegation of rights. ✪
Kerri Lemoie: Reminder there will be no meeting next week on Nov 15. Nominations of cochairs are still open, nomination period will be open until the 22nd. ✪
Kerri Lemoie: We do a self-nomination, send an email to introduce yourself. ✪
<kerri_lemoie> self-nomination email to public-vc-edu@w3.org
Kerri Lemoie: We're aiming to get to something that looks like the VC use cases document ✪
Kerri Lemoie: The main VC use cases document only has roles for Subject, Holder, Issuer, Verifier. As each person has been submitting or presenting or finding use cases.... asking everybody for stories... we will populate this document. ✪
Kerri Lemoie: You can send email to the group, and it will populate this document as well ✪
Kerri Lemoie: The main VC use cases document is very general, cross industry to things like supply chain. Education is different, and needs adjustments and accommodation in education, training and achievements, which is still a broad spectrum of achievements ✪
Kerri Lemoie: I added "Access to LMS & Roles" as a component of a use case ✪
Kerri Lemoie: We often talk about ed credentials in terms of diplomas and licenses, rather than access that could be granted for a credential, like signing into the LMS ✪
Kerri Lemoie: Feel free to add your notes and comments. ✪
Kerri Lemoie: Feel free to riff in here freely; we are a ways away from final and stable ✪
Kerri Lemoie: Link credentials to verified issuers (accredited by specific parties) is an important use case in education ✪
Kerri Lemoie: How are we translating human trust to technology trust, what kind of governance will we put into credentials ecosystem to make sure credentials can be trusted. I think this section is critical for us to get into. I put a note here that we should do a topic on DIDs and governance, and look at the wallets serving the education markets. ✪
Technology Needs section was added - these needs have been coming up, like the need for paper or printable credentials. Folks have been asking about image/file embedding (how do you embed an image in a credential?) ✪
Kerri Lemoie: We have embedding data inside an image (for example Open Badges historical "baking" protocol) ✪
Kerri Lemoie: Others have talked about how they want to do that too, to embed data into a PDF or other presentation or a certificate ✪
Kerri Lemoie: Displaying online is important, being able to share by URL ✪
Kerri Lemoie: Accessibility (i18n) is important, we aren't talking about it enough. ✪
Kerri Lemoie: So we have a substantial amount of content here, but lots of gaps to fill. ✪
Kerri Lemoie: For now, it's important to keep discussing and reaching for filling these categories out. The more we can share about these things that affect your projects, the better it will be for your projects. ✪
Kerri Lemoie: Any questions about this document or where it's headed? ✪
Sharon Leu: It is excellent to include accessibility, there is a temptation in tech to do a11y after the fact. ✪
Sharon Leu: There are a bunch of requirements that are different for higher ed vs K12. I can take a look at language that the federal government usually writes in. I know this will be different for non-US use, but section 508 is important for US as well. ✪
Kerri Lemoie: This document describes a high school program for college application. ✪
Kerri Lemoie: CommonApp is the application that is being used most frequently. This use case for high school student open badges and college application was developed with Phil Long ✪
Kerri Lemoie: I thought about the roles. How does an after school program develop a badge system, that presents badges and pathways that are discoverable online. A student goes through a process of getting the mobile app for her credentials, then selects and shares relevant credentials with the college application platform from among the badges she earned from the after school program. ✪
Kerri Lemoie: Once the college application platform analyzes the data and verifies its authenticity, they interpret what it means for the student's eligibility and qualifications. ✪
Kerri Lemoie: It's important that the application platform can verify that the badges are the recipient's. ✪
Kerri Lemoie: What could go wrong? Lots. The student could lose her phone. Verification might not work. Data could have changed. The Open Badges type schema might not be supported by the platform, so even if the credential was verified, the specific educational claims that are being made are not understandable to it. ✪
Kerri Lemoie: The other things I have on my list to think about are (1) the collection of various credential formats in one wallet, not wrapped like an "LER Wrapper", more like individual credentials in different schemas from different platforms. Can we get these translated into common formats? ✪
Kerri Lemoie: (2) Technology-limited users. What if users don't have smartphones? Attestations, on the job training, are other use cases we could look at. ✪
Kerri Lemoie: I asked Nathan if he could come here today and walk us through this use case from the perspective of our template format. ✪
Nathan: Nathan here from Learning Economy Foundation. Nate is killing it on scribe. 100 wpm 98% accuracy wow. ✪
<kerri_lemoie> Nate's a pro at scribing!
Nathan: We're a foundation trying to accelerate the world toward educational infrastructure. We're the guides of _____ spec. Pluggable support for a wide range of technologies. Noone's sure what will and won't stick, so it's important to build for various connections and implementations. ✪
Nathan: We've partnered to transform a workshop series (unintelligible) formal application to demonstrate ... gamified ... Playbrary is a collection of activities for learners age 5-12 to do at home with their guardians. ✪
Nathan: The activities are oriented toward 5 categories of skills ✪
Nathan: There are some unique requirements from this use case and the child demographic, so we're using some experimental technology to support this. There's support for learners to not have to manage their keys on their devices. Students should co-own credentials without needing to store them on their devices. ✪
Nathan: "As a child I want to earn credentials I earn through a gamified learning experience and have these credentials persist afterward" ✪
Nathan: This involves a mobile application. Torus (sp) key management system that allows users to log into dApps with an email password, enables noncustodial key management. ✪
Nathan: We are a node within Torus that allows users to log in with our credentials, and we pass these credentials to real time compute jobs that create key material and provide it back to our system, allowing us to instantiate the universal wallet on a client device without having us or a child manage the key material. If the device is lost or our system is compromised, not a problem. ✪
Nathan: Second technology is called the Ceramic Network, for hosting sharing streams of data built on top of IPFS ✪
Nathan: It links IPFS content identifies together (using ___) so each piece of data has an immutable identifier... Ceramic allows for interesting patterns around revocation. Standard revocation pattern is to have a register where a relying party would have to query a registry to make sure the credential has been revoked. In this case, the issuer doesn't need to change the registry, they can change the VC itself within Ceramic. ✪
Nathan: All content within Ceramic is actually owned by DIDs ✪
Nathan: We chose Ceramic because part of the requirement was that we don't store the credentials in our system. This was the easiest to spin up for users with this capacity. ✪
Nathan: We also use IDX, a DID-based ID protocol on top of Ceramic, a DID-based index that allows you to apply content to a user. Only the user can add things to their own profile. ✪
Nathan: Goal of the primary actor... more formal: Alice wants to play a game that will help her learn important skills to use in the future. less formal: actually... just to have fun. It's up to the developers to make sure Alice has fun and achieves the learning goals. ✪
Nathan: Actors: Alice (child), Alice's guardian (within our system for various reasons, especially for secure data compliance in the EU and US we can't store any data about a child without consent from the guardian, so we have child accounts and guardian accounts), the mobile application at large, a LEGO Foundation wallet, a Torus node, A Ceramic node ✪
Nathan: Preconditions: essentially the system has set up a custodial keypair and a DID Document for the LEGO Foundations. LEGO has asked us to be custodians of their key material. System is able to instantiate a universal wallet instance using the Lego Fdn materials. Alice has created a child account. Guardian has created a guardian account, and the system has generated a Torus keypair for the child. ✪
Nathan: On Issue of a VC, flow of events, step 1, alice completes a course or quest, a unit of learning that warrant issuing of a credential. (2) system determines VC has been earned, (3) system makes request to our backend servers to issue the credential. This uses a universal wallet instance that is instantiated for the issuer. Client will ask a credential be issued against a template we're managing. These are currently stored in our system but ✪
Nathan (4) Lego wallet constructs and signs the VC. (5) publishes to the Ceramic network. If you're familiar with the Universal Wallet Interop spec, it's based on plugins, so our goal is to build an ecosystem of plugins that support exchange through various mechanisms. We've introduced certain functionality to store VCs in Ceramic among other things to the wallet. As of now, it's done on a fork, but we plan on formalizing an contributing back on ✪
Nathan: (6) Service returns VC and its unique identifier to the client. (7) client validates the VC with the child (sometimes omitted), 8: alice stores a reference to this credential within DID profile in IDX ✪
Alice's wallet is the only entity that can modify Alice's profile in IDX, so it's important that her wallet is the thing that adds this credential reference to a field in her profile. ✪
Nathan: On retrieval of credential, there is a straightforward workflow: (1) Alice accesses her wallet through a gamification-themed "treasure" page. (2) Alice's wallet retrieved credentials referenced in IDX user profile, fetches these credentials from ceramic network, and displays the credential image property that is deeply nested in the credential. ✪
Nathan: The image property is essentially aligned with the Open Badges v3 proposal. This is essentially Open Badges wrapped in VCs with a very basic Achievement type at the moment. ✪
Nathan: Points of failure, there are various failure vectors: our app goes down, node failure in Torus or Ceramic (less likely) ✪
Kerri Lemoie: We covered a lot of technologies that are new to me. I'm curious as to how you got to all these solutions (in progress etc etc you may wish to present the wallet when you're ready) ✪
<phil> For the child to find the credential attractive is the UI representing them or transforming them from the native OBV3 JSON-LD?
Nathan: What I described here is existing functionality in the application. We'd be happy to demo in a couple weeks. To drill into the VC... I wouldn't call it a misalignment, but we haven't had as much time to focus on the actual data model, we've been focused on building the technologies around it. ✪
Nathan: Our very first use case.... the doc I just went through can support any VC in our system. The first I went through is for "quest", a collection of courses someone takes: We issue an achievement credential. There's no exam, we're not actually trying to understand a skill. ✪
Nathan: Learners can obtain a LEGO playset by providing their VCs to LEGO ✪
Nathan: There are plenty of discussions around how to extend this into more formal skill attestations. That will really be helped by good alignment in this community about schema. ✪
Kerri Lemoie: Is this the sort of thing where a parent could walk into a LEGO store and the clerk could scan the credential and redeem the playset reward in store? Nathan: Yes that's the idea. ✪
Kerri Lemoie: Could this wallet be used by just the parents, or by older students, or is this locked into just the minor/guardian use case? ✪
Nathan: This goes beyond this use case. Universal wallet is universal.... we're trying to merge credentials and tokens and whatnot... Everything we introduce are patterns that are extensible to support the universal wallet as far as it can go. ✪
Nathan: The way it works now is that children have their wallets, separate from guardians. These wallets could be "ejected" once they hit the age of 18 ✪
Nate Otto: What does "ejecting" mean in terms of relationships between these entities? ✪
Nathan: As I mentioned, the wallet is attached to key material that is generated, so by eject, there likely needs to be some process that decouples the wallet from the initial email/password. As of now, those capabilities are not in place. Nothing in the wallet has to change, these are wrapper layers on top. ✪
Phil L: One thing I'm trying to get straight: It sounds like much work has gone on to build the backend and interactions to enable tracking the learner's progress on quests and recognize it when it's been completed. It's not clear to what extent that the child is engaging in the quest in the wallet. ... It sounds like 98% of what you describe, the child doesn't need to engage .... ... even recognition can be presented back to the wallet can be ✪
Accepted by the guardian, is the child directly interacting with the wallet? How much is the wallet itself for the child something that they proactively engage in, or is it more of a backroom process? ✪
Nathan: The wallet exists for the child, it's a mobile app that is a gamified learning experience mobile app, but management of the wallet is not in the forefront. The child is not likely aware that they're dealing with the wallet. Correction to one thing you said: It's not just that there's a wallet for the guardian who is acting on behalf of the child. The child is accepting credentials themselves; credentials are being added to the wallet. The ✪
Guardian's wallet can't be used at the LEGO Store for the relying party scenario, because the credential is actually owned by the child's wallet. ✪
Nathan: Focus is not yet on owning your own credentials and what it means. The redeeming of the playset after completing quests is more forefront. ✪
Phil Long: The storage location is in the Ceramic node.... are you going to do some UI representation to present to the child the elements of their awards? ✪
Nathan: Just like any standalone wallet app (even ones on the crypto side), they display materials based on the data model and their display capabilities. For unique entities and other things, the wallet might choose to display them specially. All the patterns are standard.... we try to isolate on the experience, so that even if we were to eject the wallet completely out of the gamified application, everything we built goes with it. ✪
Nate Otto: Is it possible for an external issuer to offer a credential to the learner? ✪
Nathan: Yes, it's very pluggable. If another issuer were able to instantiate said wallet (because it's open source), they could issue a credential to Ceramic. The key is they can't actually associate a credential with a user's wallet. The child has to essentially approve it. If they have some mechanism of engaging with the subject, the subject could represent it in their profile (hmm) ✪