The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

CCG Verifiable Credentials for Education Task Force Telecon

Minutes for 2021-06-07

  1. Introductions & Reintroductions
  2. Announcements & Reminders
  3. Switch to Jitsi
  4. Open Credential Publisher and holder-to-holder use cases
  5. Open Badge Assertions and Verifiable Credential Assertions
  1. Switching to jitsi on upcoming call
Kim Hamilton Duffy, Kerri Lemoie, Anthony Camilleri
Kim Hamilton Duffy
Kim Hamilton Duffy, Taylor Kendall, Phil Long, Eric Kuhn, Jim Goodell, Nate Otto, Keith Kowal, Kerri Lemoie
Audio Log
Kim Hamilton Duffy: Agenda: TODO
Kim Hamilton Duffy is scribing.

Topic: Introductions & Reintroductions

Eric_Kuhn, Microsoft Decentralized ID, K-12, Microsoft EDU team on integrated

Topic: Announcements & Reminders

<jarlath o'carroll> @Eric is that session recorded and published somewhere?
<phil-t3> Thanks @Taylor
<anthony_camilleri> One more, OECD is doing a digital education policy conference starting tomorrow. Free registration:
Eric Kuhn: Looks like their youtube channel only had the main stage recorded
<jarlath o'carroll> OK @Eric - thanks, would have liked to have seen/heard it
Jim Goodell: Register to participate in the June T3 Network Charter Review sessions at:
Jim Goodell: Officially JOIN the T3 Innovation Network through the T3 Network Resource Hub at:

Topic: Switch to Jitsi

RESOLUTION: Switching to jitsi on upcoming call

Topic: Open Credential Publisher and holder-to-holder use cases

Can we join any of the vc-http-api use cases?

Topic: Open Badge Assertions and Verifiable Credential Assertions

Nate Otto: What does a validator need to know:
1. Id from recipient, and validate
2. Id from issuer and validate, can I trust?
3. Does it recopgnize some kind of skill that's recognized in my system
4. Timely (expired)
5. Richness of badge meatdata
Keith Kowal: Why putting open badges in VCs? are they inteded for public consumption?
Phil Long: Direct link to Join the T3 Innovation Network - no cost and pre-req to get the invite to the open meetings for reviewing the new network charters.
Kerri Lemoie: Example Open Badges 2.0 Assertion:
Nate Otto: IMS Global Open Badges 2.0 Specification:
Nate Otto: Example Open Badges with VC Assertion:
Nate Otto: W3C Verifiable Credentials Data Model:
<brent_shambaugh> yes
<phil-t3> Is everyone clear on what Kerri means by a ‘baked badge’?
<eric_kuhn> no
<phil-t3> @Eric - the image of the badge has the actual data for the image embedded in the image itsellf.
Nate Otto: A "Baked badge" is a PNG or SVG image file that has the open badges metadata in it according to the OB Baking Spec
<ottonomy> For PNG and SVG there is a specific protocol for embedding this metadata in that file. The validator can then pull that data out of the file so your badge data can travel with you between file systems.
Nate Otto: There are libraries in multiple languages. I maintain one in python for instance (openbadges_bakery). It's a pretty simple operation on top of a PNG chunk editor library or XML library. -- like 100 lines of code or so in the "bakery" layer.
Nate Otto: Any role *could* bake a badge, but typically the issuer does so in order to deliver it to the recipient/subject. Validation can start from a file (e.g. ) -- the validator begins by extracting the assertion data from the PNG or SVG.
I hoped Nate would use the term interloper
<anthony-camilleri> I am missing badgeclass from the slides. Where has it gone?
Nate Otto: I think hasCredential should be direct to a badge, not hasCredential: { badge: {} }
<anthony-camilleri> strongly agree with self-contained.
<david_ward> Being self-contained probably also means that the badge class also needs to be embedded.
<anthony-camilleri> I tend to think of the badgeclass in a VC context as an externally hosted template, which then is written entirely into the credential.
Phil Long: +1 @Anthony and @Eric on there is no dependence on the issuer being contacted for the verification to be done.
Nate Otto: On baking: there's no need for baking in the VC ecosystem, but if any issuers wanted to use that method for data flows where users download as a file and upload to another open badges app as a file, it could easily be done. But if we can pull off good interoperability just within VC protocols for connections between issuers, wallets and verifiers, it would be great to stay in that realm.
<eric_kuhn> spot on Keith
<anthony-camilleri> @nate: I actually think we need to evolve the concept of baking in the VC context. Allowing the Issuer to specify displayproperties/visual representation rules for credentials is an essential part of many use cases. But maybe we should be able to bake to a variety of screensizes/formats/platforms depending on use case.
<jim_goodell> I need to jump. Great conversation!
<phil-t3> I like the idea of enabling the giving the holder the opportunity to decide what they want to share on any …’portal’… site of their choice, but the richer data that is hoped provides greater clarity about what the learner knows and can do something the individual presents
<phil-t3> That is ‘presents’ in the VC sense.
<ottonomy> That said... As Kerri is mentioning the VC .id property could be a hosted and shareable HTTP URL that represents the badge as opposed to using a learner-controlled presentation service.
<anthony-camilleri> within VC logic, isn't any share supposed to be a VP, including a public share?
<anthony-camilleri> or do I have a misconception here?
<ottonomy> I think issuer sharing of the VC directly would be indeed thought by some to be an anti-pattern.
<eric_kuhn> sharing from a user to an RP uses a VP
Kim Hamilton Duffy: +1 Kerri
<ottonomy> At some point, probably in a future call, if we want to address it directly, Keith's other point that "VC attributes could solve for" a bunch of use cases that we are thinking about using this Defined Achievement claim for..
<phil-t3> @Anthony - great question. At the present time a VC is intended to be a direct to the RP exchange, as Eric notes, with the added feature of progressive disclosure up to simply saying yes or no to the presence of an attribute (a ZKP approach).
<ottonomy> Having a claim schema that is actually implemented in an ecosystem where issuers are using it and verifiers are consuming it for some kind of business value is the real prize. That is better than having bespoke claim type attributes for each possible credential that could be issued.
<phil-t3> One of the challenges we’re encountering is the notion of a layer of publicly shareable data vs. data that is private (it may contain PII, or could lead to identity discovery, etc.)
<david_ward> The ability to use an Open Badges "backpack" as a publicly sharable "resume" can be useful to people.
Keith Kowal: +1
<eric_kuhn> David, another option is using the concept of an Identity Hub and including your VCs in your hub that other users could query to see your 'resume' or public profile
<kate_giovacchini> Thanks all! An interesting conversation as always!
<phil-t3> Cheers!