W3C home > Mailing lists > Public > public-credentials@w3.org > November 2021

[MINUTES] W3C CCG CCG Verifiable Credentials for Education Task Force Call - 2021-11-08

From: CCG Minutes Bot <ccgminutes@gmail.com>
Date: Wed, 10 Nov 2021 13:11:03 -0800 (PST)
Message-ID: <618c3567.1c69fb81.6b030.7733@mx.google.com>
Thanks to Nate Otto for scribing this week! The minutes
for this week's CCG Verifiable Credentials for Education Task Force telecon are now available:

https://w3c-ccg.github.io/meetings/2021-11-08-vc-education 

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
CCG Verifiable Credentials for Education Task Force Telecon Minutes for 2021-11-08

Agenda:
  https://lists.w3.org/Archives/Public/public-vc-edu/2021Nov/0015.html
Topics:
  1. Introductions & Reintroductions
  2. Announcements & Reminders
  3. Work Items
  4. Use Case involving Children Under 18
Organizer:
  Kerri Lemoie
Scribe:
  Nate Otto
Present:
  Kerri Lemoie, Deb Everhart, Nathan, Hakan Yildirim, Taylor, Matt 
  Lisle, Phil Long, Matthias Gottlieb, Nate Otto, Dmitri Zagidulin, 
  Sharon Leu, David Ward, Wesley, Kayode Ezike
Audio:
  https://w3c-ccg.github.io/meetings/2021-11-08/audio.ogg

Kerri Lemoie: https://www.w3.org/community/credentials/join
Kerri Lemoie: https://www.w3.org/accounts/request
Kerri Lemoie: https://www.w3.org/community/about/agreements/cla/
Kerri Lemoie: https://w3c-ccg.github.io/meetings/
Nate Otto is scribing.

Topic: Introductions & Reintroductions

Topic: Announcements & Reminders

Kerri Lemoie: https://lists.w3.org/Archives/Public/public-vc-edu/
Kerri Lemoie: 
  https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0035.html
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: 
  https://docs.google.com/document/d/11I96C6QMzx9Yv0mvM3hAnc3jB5ER69qmzQTeY1a8M8s/edit
Kerri Lemoie:  If there are more than two nominations, we'll have 
  a Q&A on the 22nd followed by voting
Kerri Lemoie:  Co-chair is a great role to be involved in if you 
  want to be deeply involved in this work.

Topic: Work Items

Kerri Lemoie:  Nathan is here from Learning Economy. First I will 
  talk about where we're at.
Kerri Lemoie: https://w3c-ccg.github.io/vc-ed-use-cases/
Kerri Lemoie:  We've been working on populating the use case 
  document
Kerri Lemoie: https://www.w3.org/TR/vc-use-cases/#user-roles
Kerri Lemoie:  The template is based on the VC use cases document
Kerri Lemoie: 
  https://docs.google.com/document/d/1O98lt85PS8ozyMtKQMPdZPLnzpNI30bEgYH1Dq-C-IQ/edit#
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: 
  https://docs.google.com/document/d/10Sj4FcbxkbUIC2yVv_XKF-6U6zDzwdIE1l83CAiP2JQ/edit
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: https://github.com/w3c-ccg/vc-ed-use-cases/issues
Kerri Lemoie:  I've also been reviewing the Use Case Issues in 
  the above link and reaching out to the authors.

Topic: Use Case involving Children Under 18

Kerri Lemoie: https://github.com/w3c-ccg/vc-ed-use-cases/issues/8
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: Applicable standards: DIDs, VCs, OB, Universal Wallet 
  Interop spec.
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.
Kerri Lemoie: Torus: 
  https://docs.tor.us/customauth/what-is-customauth
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
Kerri Lemoie: Ceramic: 
  https://developers.ceramic.network/learn/welcome/
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.
Kerri Lemoie: IDX: https://developers.idx.xyz/learn/welcome/
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
Planned for move to Ceramic
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
GitHub.
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: This is a skill attestation VC.
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: yes, exactly.
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)
No meeting next week
Received on Wednesday, 10 November 2021 21:12:19 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:24 UTC