Add DID support to Open Badges

[decentralgabe]

badges-with-dids-workday.pdf

https://github.com/workdaycredentials/specifications/blob/master/specifications/badges-with-dids.md

As presented on Jan 23rd. Please scroll through the legal stuff to exhibit B.

Three callouts from the meeting to be addressed going forward:

• Changing the did property to id
• Not allowing HTTP URLs with the DID type
• Providing examples of validation/interaction with DIDs

I have not made any amendments, but we are open to working through all suggestions. Looking forward to working with you all to add this to the spec.

[ottonomy]

Thanks for making the amendments you referenced and providing examples. This should be a great start to our consideration. Hope to see you at the IMS summit next week!

[decentralgabe]

I did not make any changes yet, so hold your thanks 😄. Looking forward to meeting next week!

[ottonomy]

Oh, thanks for the clarification. I misread that and now I see you're correct that this remains as work items. I'd love to also work on defining a Badge Connect service as a service that might be discoverable on a DID document that implements Open Badges 2.1, so that an issuer could determine where to send badges if they want to award to a particular DID.

[kimdhamilton]

sorry I'm late to the party. From the PDF I see this example:

"recipient": {
   "type": "did",
   "hashed": false,
   "identity": "did:work:H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}

I'm not sure how this reconciles with the comments above ("changing did to id") . I'm guessing it means the following, i.e. add an id field, similar to VCs?

"recipient": {
   "type": "did",
   "hashed": false,
   "id": "did:work:H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}

Will identity still be a required field?

[decentralgabe]

I think it would make sense to see it represented like

"recipient": {
  "type": "id",
  "hashed": false,
  "identity": "did:work:H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}

The ask (I don't remember from who) was to change did to id for JSON-LD niceties

[kimdhamilton]

I see, I was focusing on the terms, not the types. This would cause the json-ld type to match @id (alias id), which makes sense.

I'm still hung up on the word identity, but baby steps are fine.

[decentralgabe]

Hi @ottonomy @jbohrer following up here to ask how I can help move this proposal forward

[ottonomy]

@glcohen great question as far as standardization goes. I support this work item being considered ASAP by the Open Badges Workgroup at IMS as a key part of a 2.2 Open Badges Specification release. I think there would be good agreement from members that this should be taken up in the workgroup without significant delay.

@ahripak you're the chair of the workgroup, so I think it's probably to you to organize agendas for the following:

• When can there be a discussion on scope and use case gathering for Open Badges 2.2, which upcoming meeting of the OB workgroup would be right for that?
• Given that it probably takes 18-24 months to develop a new spec version to publication, can we get on the agenda what mechanisms may be enabled to allow market adopters to pilot this capability and explore specification scope prior to it being finalized in an OB release.

@glcohen On behalf of Badgr Team at CSky, we're incredibly busy but very interested in picking up some interoperability pilot or proof of concept work around this collaboratively with other implementers in the space in Q2/Q3. What you could help with would be sending us a description of how your tooling would want to position in a proof of concept phase. Ours would likely be in both issuer and backpack/host roles. User authentication of dids with an appropriate resolver method chosen among participants in a pilot will be super important for that backpack role, so meeting among interested collaborators to agree on how authentication works with the chosen did resolver method(s) will be critical. Connected to this, we are also likely to be looking at how using the W3C Verifiable Credential envelope would work for a claim that consists of a achieved or holds relationship described in the paper from couple years ago referenced in this proposal. Anyone else interested in developing such pilots feel free to contact badgr@concentricsky.com

[AdamJLemmon]

Hey @glcohen @ottonomy , We're (convergence.tech) also very interested in this work item and looking at some scope for an interop pilot where possible. We've built some tooling for issuer / verifier roles leveraging the universal resolver as well as focus on ethr and sov.

[decentralgabe]

@AdamJLemmon that is great to hear! Is your tooling publicly available?

[AdamJLemmon]

@glcohen Not at the moment unfortunately, we should be releasing something fairly shortly though :)

[jbohrer]

Great to see this level of interest!

IMS recommends a Decentralized Identity Task Force be formed as a subgroup of the current Open Badges project group for the purpose of studying this topic and identifying recommendations for the OB project group. Deliverables of this task force may include use cases, sample code, and recommendations.

An announcement of this will be made during next week's OB project group call. Interested members will be encouraged to participate and lead this task force with support from IMS staff.