Re: JFF Plugfest question

Hi Ian,

Thanks for posting your question to this list.

For the plugfest, you may use the badge examples provided here:

https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/ <https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/>

but you may also use ones that you generate.

The requirements are:

• Display: VC (Open Badge 3.0)
• Display includes: VC required fields plus badge image, issuer name, achievement name, achievement description, achievement criteria
• Optional: issuer logo & other Open Badges v3 terms

A stretch goal would be to do the verification of the VC prior to displaying it in the wallet. 

A couple of clarifications to Nate's responses:

- For the badge image, we determined as a group that minimally the badge image url should be available but some may choose to reference the url and display the image. If you decide to do more than that, great - we’ll be excited to hear about it.

- For achievement.id <http://achievement.id/> - that is considered an optional additional field for this plugfest. 

Thanks,

Kerri


> On May 31, 2022, at 1:49 PM, Ian Davidson <ian@idatafy.com> wrote:
> 
> Thanks Nate.  That is very helpful.  We'll aim to include an image if we can in this timeframe.  If anyone else can comment to confirm this meets the requirements of the plugfest that would be appreciated.
> 
> On Tue, May 31, 2022 at 9:41 AM Nate Otto <nate@ottonomy.net <mailto:nate@ottonomy.net>> wrote:
> Hi, Ian
> 
> I am not in the know, but I suspect that that would work to show interoperability. As to your other message, I would recommend that you add support to show the actual badge image <https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/images/plugfest-1-badge-image.png> referenced in the JSON rather than a generic one, but I'm not involved with deciding whether you get a passing grade if you fail to show the right data in terms of image. When displaying a badge in Open Badges format, it's useful to show a few of the relevant fields from within the "achievement" as well.
> 
> For example, for a relevant snippet of the example JSON:
> 
> "credentialSubject": {
>     "type": "AchievementSubject",
>     "id": "did:key:123",
>     "achievement": {
>       "type": "Achievement",
>       "name": "Our Wallet Passed JFF Plugfest #1 2022",
>       "description": "This wallet can display this Open Badge 3.0",
>       "criteria": {
>         "type": "Criteria",
>         "narrative": "The first cohort of the JFF Plugfest 1 in May/June of 2021 collaborated to push interoperability of VCs in education forward."
>       },
>       "image": "https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/images/plugfest-1-badge-image.png <https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/images/plugfest-1-badge-image.png>"
>     }
>   }
> 
> I would recommend a display that includes these properties of the defined achievement: Name, Description, Image; the Issuer Name, and the issuanceDate of the VC.
> 
> Example image of a layout that shows these things: https://ibb.co/C0N1qr1 <https://ibb.co/C0N1qr1>
> <Screen_Shot_2022-05-31_at_09_20_20.png>
> 
> An aside: 
> 
> Another thing to note from the above image is that the "achievement.name <http://achievement.name/>" in that display is a link to a page where the full details of the credentials are available. There was one OB 3.0 required property that didn't make it into JFF's example JSON, which is "achievement.id <http://achievement.id/>", a unique identifier for the defined achievement itself, as offered by a particular issuer. This is expected to be an IRI, either a URI or an "urn:uuid" scheme identifier. Back in Open Badges 0.5 in the very early days of the spec, this property didn't exist, and that meant that achievement data was machine-readable but not "machine-actionable". If a processing system processed two badge awards to two different recipients, there wasn't a canonical way to tell whether these were the "same" achievement or not. Later versions of Open Badges (1.0, 1.1, 2.0, 3.0) include the achievement.id <http://achievement.id/> canonical identifier, so that we can serve use cases comparing a particular badge award (credential that makes the OB "achievement" claim) against requirements.
> 
> This serves use cases like: 
> * You must hold the 3D Printer Authorization badge in order to use the 3D printer in the Maker Lab
> * You must complete 3 of 5 of these badges to meet a particular requirement on a learning pathway
> * A badge is endorsed by a third party endorser as a high quality achievement, fit for purpose
> * Comparison of two "versions" of a badge: are they the same badge?
> * Comparison of two learners: have they earned the same badge?
> 
> Achievement.id is the backbone of the "defined achievement" pattern that Open Badges implements, just as the id is critical to the Open Skills Network's concept of the Rich Skill Descriptor (RSD). It has a single canonical ID so that it can be referenced in other systems.
> 
> Nate
> 
> On Sat, May 28, 2022 at 3:12 PM Ian Davidson <ian@idatafy.com <mailto:ian@idatafy.com>> wrote:
> Hello,
> 
> I'm organizing SmartResume's participation in the JFF plugfest, and Sharon suggested I email this address with my question.
> 
>  want to make sure we're working to show the right VC.  I see a sample open badge as a VC in this W3C link you provided: https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/ <https://w3c-ccg.github.io/vc-ed/plugfest-1-2022/>
> 
> Is that the credential we should ingest and show for the plugfest, or is there a different one?
> 
> - Ian
> 
> -- 
> Ian Davidson
> Chief Growth Officer, iDatafy
> 213.359.3109
> ian@idatafy.com <mailto:dave@idatafy.com>
> SmartResume.com <http://smartresume.com/>
> 
> calendly.com/ian-idatafy <https://calendly.com/ian-idatafy>
> 
> 
> 
> 
> -- 
> Ian Davidson
> Chief Growth Officer, iDatafy
> 213.359.3109
> ian@idatafy.com <mailto:dave@idatafy.com>
> SmartResume.com <http://smartresume.com/>
> 
> calendly.com/ian-idatafy <https://calendly.com/ian-idatafy>
> 
>