Phil Long: Direct link to Join the T3 Innovation Network https://app.t3networkhub.org/ - no cost and pre-req to get the invite to the open meetings for reviewing the new network charters. ✪
<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 https://openbadgespec.org/baking✪
<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. https://pypi.org/project/openbadges-bakery/✪
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. https://badgecheck.io ) -- the validator begins by extracting the assertion data from the PNG or SVG. ✪
<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
<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.
<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!