<phil-t3> Is everyone clear on what Kerri means by a ‘baked badge’?
<phil-t3> @Eric - the image of the badge has the actual data for the image embedded in the image itsellf.
<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.
<anthony-camilleri> I am missing badgeclass from the slides. Where has it gone?
<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.
<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!