<phil_l_(p1)> Scribe list is not public (at least not accessible to me) (FYI)
Nate Otto is scribing.
Topic: Introductions & Reintroductions
<kim> Lohan Spies from South Africa interested in VC / OB intersection
<kim> Doug Belshaw
Doug Belshaw: Here from the North of England to find out what's happening at the intersection of Open Badges and Verifiable credentials ✪
<kim> Jackson Morgan
Jackson Morgan: Have been talking with Dmitri, Brandon, Philipp at MIT about wallet work. ✪
Marty Reed with RANDA: mentioning we've been working in a small group on Tuesdays on the Complex Credentials work. Other people who want to join that let me know. ✪
Colin Reynolds with Learning Economy Foundation: I've been following VC-EDU stuff for months; now I'm able to join the calls. Been working on the complex creds work. ✪
Don Presant: with Learning Agents (product CanCred, partner Open Badge Factory) ✪
<kerri_lemoie> Great to have everyone here!
Kim Hamilton Duffy: Announcing I have taken a role at Centre Consortium, and Dmitri is taking over my role at DCC. He's eager to continue the work that DCC has been doing here. ✪
Kim Hamilton Duffy: No new announcements, so the announcements page just lists the recurring meetings. We should update it to add the Complex Credentials meeting times. Add to pull request, anyone. ✪
Kerri Lemoie: This last link is a link to the pull request for the proposal, where you can make comments (if you have a GitHub account) voicing your support or with questions. ✪
Kerri Lemoie: Thanks Anthony for sharing the screen ✪
<taylor> VC-Edu teamwork FTW 🙌
Kerri Lemoie: Today we'll review the proposal that Concentric Sky is making to the IMS Global Open Badges Working Group for what could be a next version of Open Badges, to make them a schema for using Verifiable Credentials. The next steps on this will be taken by the IMS group. ✪
Kerri Lemoie: Today we'll take a high level approach, and then there will be a conversation inside the official IMS process on Thursday, where decisions about this proposal will be made. ✪
Kerri Lemoie: Open Badges, is a recognition system for using digital badges for skills and achievements learned anywhere anytime, it's nearly exactly 10 years old! ... "baking"... often verified via hosted publicly available data at a specific URL... ✪
Kerri Lemoie: With Open Badges 1.1 we moved into JSON-LD. 2.0 in 2016/17 added some metadata. 2020/21 "2.1" Badge Connect protocol. ✪
Kerri Lemoie: Why did we make this proposal? We believe in open standards and interop. We want to connect ecosystems, because we want educational credentials to be understand, used, adopted. This could give learners better access to opportunity. ✪
Kerri Lemoie: The contents of this proposal are based on thinking from this community from the last several years. It is similar to a RWoT paper by Kim and Nate from 2018; We have contributed to examples and prototypes and related work, like DID support in badges since then. ✪
Kerri Lemoie: Overview of design goals for the proposed V3. ✪
Kerri Lemoie: This includes merging in some compatible properties from recent CLR work. Introduces the new-to-OB use case of a direct "skill assertion" ✪
Kerri Lemoie: Align Open Badges with the VC data model, connect with a broader ecosystem of VC wallets ✪
Nate Otto: Image linking to a baked image is optional. Issuer doesn't need to do baking themselves. Any holding entity can bake it (thereby converting from json to image) [scribe assist by Kim Hamilton Duffy] ✪
Kerri Lemoie: I linked to the required and optional properties from the existing 2.0 spec for comparison. ✪
Nate Otto: The issuer doesn't currently need to offer a baked badge, but if they do include an assertion-level image it should be baked. Various holders over time could produce a baked image if needed. ✪
Kerri Lemoie: Let's look at the structural updates in the proposal. ✪
Kerri Lemoie: The 2.0 Assertion has a badge property: BadgeClass, that has an issuer/creator. 3.0 proposal has an issuer at the assertion level and a "creator" at the badge level, opening up use cases for authorized parties other than the badge creator to issue assertions of it. ✪
Kerri Lemoie: Recipient IDs. Email has been historically strongly used. There is the potential over time to replace email addresses for recipients with DIDs, which open up new capabilities. ✪
Nate Otto: It is likely that email address will continue to be a recipient identifier format in some way to reduce disruptiveness ✪
Kerri Lemoie: This opens up the possibility for badge creators to delegate responsibility for badge issuance. Details TBD on the trust model ✪
Doug: There has been talk about Creative Commons licensing of badge data for years, is that capability implied by the issuer/creator distinction you're mentioning? ✪
Kerri Lemoie: That sounds like a great comment to be considered in the proposal. TBD, there is some more work to do to figure out exactly how the delegation is declared. ✪
<anthony> don't forget ESCO on the skill descriptors :-)
Kerri Lemoie: Better integration with CLR: Achievement Types can be defined (a list of strings that describe credential purposes like "Badge", "Degree", "Certificate"), and ResultDescriptions: a method of describing the possible results that could be achieved and the actual results that were achieved, against a rubric etc. ✪
Kerri Lemoie: We introduce the concept of a Skill Result, which uses the CLR Result Description structure to describe a specific result against a skill that the badgeclass purports to recognize. ✪
Kerri Lemoie: Skill Assertion makes this use case more direct. You can assert the achievement of a single skill without requiring the issuer to define a whole defined achievement (badge class). No need for the skill author and the credential issuer to have a pre-existing relationship ✪
<phil_l_(p1)> The RSD itself has a CC by 4.0 description associated with it.
<serge_ravet> the achievement of a single skill should sound very suspicious if not connected to other skills (i.e. as part of a "practice")
Nate Otto: You explained it great. Recognition of skills is a popular use case. Right now, you'd need separate issuers to create a badgeclass to describe same skill; this proposed new use case allows creating of an assertion that goes directly to a skill definition [scribe assist by Kim Hamilton Duffy] ✪
Nate ... and then many skills can be recognized over time. Multiple skill results in one assertion is fine as well. ✪
Kerri Lemoie: Lastly, Verifiable Presentations. Badges were typically shared via URL to HTML pages displaying the content. With VCs and VPs, learners can bundle credentials together and provide proof that the presenter has control of the credentials, which is something we haven't exactly had in badges before. ✪
Kerri Lemoie: We envision verifying apps being able to request credentials for certain skills, which learners could select from their wallet. The verifying app can verify the authenticity of the credential and the authenticity of the recipient's control cryptographically, without relying on a web server which might be unavailable. ✪
Anthony Ronning: 2 Points. First is about the use of schema's hasCredential. Schema's description might be a bit of a mismatch, and we might make an unresolvable ontological loop. 2nd: With the skill assertion, it's interesting to go through result description ✪
Anthony Ronning: Did you consider using hasCredential to a SkillCredential directly? ✪
Kerri Lemoie: This isn't final, but this will be refined a little more. ✪
Nate Otto: SkillResult: This reuses a structure from CLR, open for discussion, but it allows you to specify a level of performance. ✪
Kerri Lemoie: What's been proposed is a breaking change, which has occurred before. The verifier app (that IMS global produces) can be used to update badges to latest version / preferred version that the client wants to see. ✪
Serge Ravet: I don't understand the part of the argument about verification? The utility of a 4-5 years old credential if if becomes unverifiable, may just be another sign that the credential is no longer the most relevant for the learner. If you're still mentioning your diploma after 30 years in the workforce, may be evidence that you haven't done much else in life. ✪
(We might want to clean up endorsements just a tiny bit; it is effectively already a verifiable credential claim type though, since 2016, so it's using some pre-standardization conventions.) ✪
Doug: I get where you're coming from, Serge, but a counter example: if you work for an organization but fall out with the people who worked there, but they're trying to get rid of the evidence you worked there, having some kind of proof that could survive that attempt might be good. ✪
<ozgur_y> Thank you for the work and presentation!
<phil_l_(p1)> Complexity is common to nascent innovations. I'm sure with time will decompose the steps so that more options will exist to do different parts of the workflow of VCs. And things will get simpler.