Re: JFF Plugfest question

Thanks Kerri!

Nate, thank you for the example use cases (checking if somebody has
received a certain badge), that helps me understand what OBv2 and earlier
used it for.

So now that I understand that a bit better, I want to suggest that -- the
achievement.id field is a non-idiomatic way of fulfilling that usecase.
achievement.type would make a lot more sense, and would match the usage in
the general Verifiable Credentials community.
For example - in general VC usecases, the question asked by a relying party
"Does the user have credential X?" comes up all the time. Let's take your
example, where ordering a 3D printer requires the "3D Printer
Authorization" badge. The way that's usually done for regular VCs is by
using the vc.type, NOT vc.id. So, a relying party would query (using the VP
Request spec, or WACI-DIDComm spec, etc) asking "holder, please present any
VCs that are of type "3DPrinterAuthorization"."

Since we're dealing with Open Badges and the Achievement object, this would
translate directly as "Holder, please present any VCs that have an
achievement.type of '3DPrinterAuthorization'".
Incidentally, this is exactly why the 'type' property of a linked data
object can always be an array. All Verifiable Credentials are required to
be of type "VerifiableCredential", but ALSO of one or more subtypes that
they want. So, a VC would have type: ["VerifiableCredential",
""3DPrinterAuthorization"].
Similarly, this would translate to vc.credentialSubject.achievement.type:
["Achievement", "3DPrinterAuthorization"].

Basically, the 'id' field is the wrong mechanism for all the usecases you
mentioned. And, I totally get that this was historically the mechanism that
previous OpenBadge specs used. But, we have a chance to fix it in OBv3!






On Tue, May 31, 2022 at 2:02 PM 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
>
>
>
>