Re: JFF Plugfest question

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
[image: 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
>
> calendly.com/ian-idatafy
>
>
>