VC & Open Badge Linkage

From IIW

VC & Open Badge Linkage

Tuesday 3G

Convener: Gabe Cohen (Workday)

Notes-taker(s): Orie Steele, Nikhil Wadwa

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Open Badges - http://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html

VC Data Model - http://w3c.github.io/vc-data-model/

Spec to be hosted here - http://github.com/workdaycredentials/specifications

Slides here -- http://docs.google.com/presentation/d/1XJjyt04BaCtSLE1_KMa4ysOgh3vsDeK48d-jEPheKP8/edit?usp=sharing


  • IMS Global is the standards body behind badges
  • Badgr and Credly have platforms for hosting badges
  • Pretty picture with JSON data
  • Millions of badges in the world today
  • Used at Companies and heavily in the education space
  • Workday implemented badges according to the Open Badges spec
  • We’ve represented the image and the data that backs a badge in the evidence field
  • There’s a notion of a badge class
  • Metadata about a badge, image, and who issued it
  • This data is hosted on a website
  • The credentialing space W3C and DIF, etc.
  • VCs are much less mature than the badging specification and are more security oriented
  • Today you can issue badges to emails, phone numbers, and URLs
  • We are introducing DIDs for issuers and recipients


Today badges can be issued to

Emails

Phone numbers

URLs

Workday implemented badges based on OpenBadge specification

Open Badges support JSON-LD,


Can be used to represent many things, including Amazon Web Services Solutions Architect A Badge Class describes metadata about the credential and issuer.

Badges are meant to be public, so privacy concerns are low. Badges are more informal than VCs, still verifiable

Verifiable credentials are supported in workday mobile app How can Badges be VCs?

Plan to add DID support to OpenBadges Badges are less serious than traditional VCs, still badges are verifiable

Issuer and Holder can be the same, and be a DID.

Plan to merge VCs and badges to use best of both worlds and drive more adoption Badge and Credential are linked. Badge is public, Credential has sensitive details, and goes to the holder. The spec defines how badges and credentials are linked. New changes to spec:

  • The evidence section allows you to issue/ verify the challenges
  • The BadgeClass contains the endorsement
  • Nothing has changed in the credential


  • Comparison of Badges and VCs
  • Badges are discoverable and sharable with lower trust “fun”
  • We would like to bridge them together by using the same identifier between the badge and VC
  • We can extend the badge representation to hold the full set of claims
  • All badges are VC backed
  • Extension represents claim data
  • Make use of the holder’s DID Doc
  • Expose a service endpoint to interact with the holds to run a proof request for the VC
  • Is a challenge is for authenticity of the badge? - Orie Steele
  • Trust is based in the hosting of a badge
  • The VC provides a better trust mechanism
  • Extension that brings in claim data into the open badge
  • And a link to challenge the VC if needed
  • Endorsement linking them in the existing badge class

A VC could carry a number of badges - VCs could be likened to containers

Education industry has responded positively to the container model

The credential service can facilitate selective disclosure.

  • E.g. job experience can be published publicly, and can be challenged for salary range
  • users can treat the badge as a presentation layer around the VC - and attributes of the VC can be selectively disclosed by the user

Verifiable Credential Service is a kind of “inbox” that will forward requests to a user mobile device. IMS Global has a group tackling autonomy of skills

Adding DIDs to badges allows students to carry their achievements with them - and the ability to combine them with VCs is important as well

DIDCOM working group at DID still hasn’t got to credential exchange

Having a DID present in a badge raises correlation aspects - we are exploring a few different models related to that - this is also an ask by the IMS folks

Credentials could be used to establish reputation - badges could also be received anonymously

Presentation of ones identity is typically used for trust access - more privacy based secure thing would be instead of establishing identity - establish proof of permission to access

Badges and VCs should move towards allowing the user to share whatever they want

Placing selective disclosure in user hands is important - e.g. piano player badge / selectively show or hide experience

Work will take place in Aries wg around cred exchange/mobile in coming months

  • You can add a service to your DID Document to present an endpoint for challenging for the VC
  • Is this a Workday proprietary service or part of the ID Hub? - Orie
  • This could be an endpoint to an agent that can respond to requests
  • Will forward the request to their wallet
  • You mentioned that there was a 1-1 linkage, but badges. A VC can hold more information than a badge. This reminds me of a container. Once they standardized on the containers they could be transported anywhere. Are VCs like containers that can carry any data type? - Timothy Ruff
  • This specification is not published yet.
  • Open Badges are more well known than VCs. The industry is more matured in the OB area.
  • RWoT embedded a badge inside of a VC.
  • Are you using the badge as a presentation layer of the VC?
  • Is the badge signed? - Orie
  • No, the badge trust is oriented in the hosting domain.
  • The VC has done discoverability. You want it in a public space with a limited amount of data.
  • Is there anybody from Learning Machine or Highland working on this? They seem to be in the same space.
  • We’ve talked to Kim Duffy (coauthor of RWoT paper).
  • This was presented to Kim’s W3C working group.
  • VCs have concrete use cases. Badges tend to be used for more silly purposes as well as things like Skills. This makes bringing them together more difficult.
  • Orie - always look for the badges attached to a Github repo. Look at testing badges and others to judge the maturity of the project.
  • The way that we do TLS might have to shift from having a client that can do proof requests. - Tim
  • Transmute has a GitHub DID method. We like GitHub actions. One of the things that we looked at was using the portable web wallet and checking that into a repo and then checking in the public key into the repo and have it sign commits with that key. Turn on only accept commits from certain issuers. You can generate VC pieces to automatically update the badge.
  • Are you guys working with the ILR wallet spec?
  • We are aware of what’s happening there. As far as our contributions, we are working with them in their CLRs.
  • In the stacked credential content/scope, you have there VCs with skills and then based on an aggregation of skills, you can earn something. I think that this is what credentials engine is doing. The linkage is the standardization. - Matthew Hailstone
  • IMS Global has a group focusing on accreditation (autonomy of skills). CASE competencies and academic standards exchange.
  • Most of the BC gov case has to do with licenses. You might have a badge you were licensed. I haven’t seen anything with a community holder in that system.

- Sam Curren

  • With VCs the user controls where the VC is held. Are you saying that the Open Badge provides visibility and the VC does not?
  • Badges have a “backpack” that is similar to a wallet, but Is hosted.
  • The DIDComm group has yet to get to credential exchange. If you have an endpoint, you can send a message encrypted with a key. The verifier asks what they are willing to prove, and the holder can accept. This is coming, but isn’t there yet. One of the downsides is that it makes the credential correctable. In the case of a badge issued to a DID. There could be one persona, or it could be that each badge is issued to a unique DID.

- Sam Curren

  • The proof of control over a DID is an ask from the IMS group.
  • You present a challenge that needs to be signed with the DID. Generally called DID Auth. One of the things that the VCs offers the badge world, you can have anonymous badges. Maybe this turns badges into a form of reputation. Being able to present the silly things as a form of reputation is interesting.
  • For resource access we tend to prove who they are vs do they have permission. I can prove who I am and then they can look up my permissions. Or the permissions can be baked into the VC.
  • Having a wallet that can hold both public and private data could be huge.
  • I like that Badges could be a public presentation of a Credential. - Sam Curren
  • It feels like Badges are institution centric. This allows a more user centric approach. Allowing me to receive badges that I can choose selectively to display. - Sam Curren
  • Selective disclosure would be very valuable. If I move to a new town and spent a lot of time in the PTA, I might not want to expose that if I don’t want to get sucked back into the PTA.
  • IIW presentation on selective disclosure that might be interesting.

-Tobias Looker

Retrieved from "https://iiw.idcommons.net/index.php?title=VC_%26_Open_Badge_Linkage&oldid=22813"