Re: JFF Plugfest question

Thank you Kerri!

On Tue, May 31, 2022 at 11:01 AM Kerri Lemoie <kerri@openworksgrp.com>
wrote:

> 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/
>
> 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 - 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> 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
>> "
>>     }
>>   }
>>
>> 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
>> <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"
>> 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", 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 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> 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/
>>>
>>> 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 <dave@idatafy.com>
>>> SmartResume.com <http://smartresume.com/>
>>>
>>> calendly.com/ian-idatafy
>>>
>>>
>>>
>
> --
> Ian Davidson
> Chief Growth Officer, iDatafy
> 213.359.3109
> ian@idatafy.com <dave@idatafy.com>
> SmartResume.com <http://smartresume.com/>
>
> calendly.com/ian-idatafy
>
>
>
>

-- 
Ian Davidson
Chief Growth Officer, iDatafy
213.359.3109
ian@idatafy.com <dave@idatafy.com>
SmartResume.com

calendly.com/ian-idatafy