在 2021 年 6 月 7 日的W3C VC-EDU电话会议中，我们讨论了声明为W3C 可验证凭证(VC)的开放徽章。此电话会议开始了将 Open Badges 作为本机 VC（可能作为 Open Badges 3.0）的公开讨论，以通知 IMS Open Badges 工作组。我们为什么要讨论这个？为什么这有关系？它将如何运作？来自社区人士的反馈表明，首先从概念的角度回答这些问题会有所帮助。在稍后的帖子中，我们可以概述结构变化的外观。
Open Badges 是可以识别学习、成就甚至会员资格的数字凭证。它们看起来像图像，但图像内部是元数据属性（它的工作方式很像数码照片如何具有解释照片数据、位置等的元数据属性，以便在上传照片时，应用程序可以理解数据）。元数据描述了颁发徽章的原因、时间、收件人（通常是电子邮件地址）、成就的描述和标准，以及至关重要的是，如何验证此数字证书。
开放徽章的验证取决于徽章的颁发者。它可以通过以下两种方式之一完成：
——Open Badges 的元数据属性之一是断言 ID，它是一个 URL，在 .json 文件中托管元数据。如果找不到该 URL，则徽章不可验证
——发行者可以对徽章的元数据进行数字签名。这使用密码学来确保徽章数据没有改变，并且颁发者是颁发徽章的实体。用于签署徽章的公钥必须可追溯到颁发者。
Open Badges 平台主要发行托管徽章。这意味着验证方依赖发行者来托管数据。此外，发行者有一定的能力来跟踪徽章数据何时被访问以及可能被谁（或至少通过 IP 地址）访问。
对于迄今为止已颁发的 99% 的徽章，这很好。事实上，徽章通常是通过网页共享的，这些网页可以吸引人地显示图像和数据（而不是通过包含数据的 .json 文件或内部包含数据的烘焙图像）。因此，虽然 Open Badges 既是人类可读的，也是机器可读的，但人类可读的方法是最常用的方法。签名徽章更接近可验证凭证，因为它们也依赖于密码证明。
这两种方法都不能让学习者控制他们的数据，这是 Open Badges 2.0 和 Open Badges as Verifiable Credentials 之间的整体概念转变。
可验证凭证，如签名的开放徽章，由发行者签名并通过密码验证。去中心化标识符 (DID) 可用于识别发行者和接收者（在 Open Badges 2.0 中使用 DID 已经原型化）。此外，可验证凭证有一个称为“演示文稿”的概念，接收者可以对其进行数字签名，以证明他们是所提供的可验证凭证的接收者。总而言之，这意味着发行人和接收人都经过了验证。
可以从基于 Web、移动或桌面（目前大多数是移动设备）的钱包应用程序中显示、共享和呈现可验证凭证。收件人可以向验证第三方出示他们的一个或多个凭据，第三方可以在不依赖发行者的情况下验证凭据并使用数据。参与者不仅可以管理要验证的凭据，还可以控制共享数据的哪些方面。
例如，学生的数字钱包可能包含数字护照、代表已完成课程的 Open Badge 和代表学生 ID 的 Open Badge（均作为可验证凭证）。依赖第三方，例如寻求担任实习职位的潜在雇主，可能需要验证学生是否已年满 18 岁、已完成沟通课程并且是在读学生。雇主的网站应用程序可以要求学生使用他们的钱包提供这些离散信息，学生可以这样做而无需透露这些凭证中的任何其他信息，例如他们的出生日期、地址、照片，甚至他们所在的学校名称参加。所有这些信息都可以在不联系这些凭证的颁发者的情况下进行验证。Open Badges 2.0 无法做到这一点。
可验证凭证将学习者置于与发行者和验证者形成的信任三角的中心。他们还为收件人增加了一层额外的验证。Open Badges 可以利用这一点，成为第一个以教育为中心的数字证书规范，以促进个人数据保护和数据访问，并成为不断发展的交换可验证证书的生态系统的一部分。
值得注意的是，Open Badges 的人类可读性在 VC 版本中不会改变。颁发者仍然可以显示已颁发徽章的网页，并允许接收者从这些页面在线共享他们的徽章。不同之处在于，这些网页不依赖于机器验证或消费。
在即将到来的 6 月 14 日星期一（和大多数星期一）太平洋夏令时间上午 8 点/美国东部时间上午 11 点/英国夏令时下午 4 点/中欧夏令时下午 5 点，加入我们在下一次 VC-EDU 电话会议中的持续讨论。此电话会议是公开的，欢迎所有人加入。对于本周一的电话会议 (6/17)，缩放信息已更改：
https://us02web.zoom.us/j/89426035740?pwd=dmQ0QS9wMUdFaGo0eFcwbkplV3RjUT09
In the W3C VC-EDU call on June 7, 2021 we discussed Open Badges asserted as W3C Verifiable Credentials (VCs). This call began the public discussion of Open Badges as Native VCs (potentially as Open Badges 3.0) to inform the IMS Open Badges Working Group. Why are we discussing this? Why does it matter? How will it work? Feedback from folks in the community have suggested that it would be helpful to answer these questions first from a conceptual standpoint. In a later post, we can outline what the structural changes could look like.
Open Badges are digital credentials that can recognize learning, achievements, and even memberships. They look like an image, but inside the image are metadata properties (it works much like how digital photos have metadata properties that explain the data of the photo, location, etc. so that when the photo is uploaded, applications understand the data). The metadata describes why the badge was issued, when, the recipient (typically an email address), the description and criteria of the achievement, and, critically, how this digital credential can be verified.
The verification of an Open Badge is dependent on the Issuer of the badge. It can be done in one of two ways:
Primarily, Open Badges platforms are issuing hosted badges. This means the verifying party is dependent on the issuer to host the data. Also, the issuer has some ability to track when the badge data has been accessed and potentially by who (or at least by IP address).
For 99% of the badges that have been issued to date, this is fine. In fact, badges are often shared via web pages that attractively display the image and data (not by the .json files that contain the data or the baked image with the data inside). So while Open Badges are both human readable and machine readable, the human readable approach is what is used most often. Signed badges are closer to Verifiable Credentials because they also rely on cryptographic proof.
Neither of these approaches give learners control of their data and this is the overall conceptual shift between Open Badges 2.0 and Open Badges as Verifiable Credentials.
Verifiable Credentials, like signed Open Badges, are signed by the issuer and verified cryptographically. Decentralized Identifiers (DIDs) can be used to identify the issuer and recipient (using DIDs in Open Badges 2.0 has been prototyped). Also, Verifiable Credentials have a concept called “Presentations” which can be digitally signed by the recipient to prove that they are the recipient of the verifiable credential(s) being presented. All in all, this means that the issuer is verified and also the recipient.
Verifiable Credentials can be displayed, shared, and presented from wallet applications that are web, mobile, or desktop based (most are mobile right now). Recipients can present one or more of their credentials to verifying third-parties who can verify the credentials without depending on the issuers and consume the data. Not only can the participant manage which credentials are being verified, they can control what aspects of their data are being shared.
For example, a student’s digital wallet may contain a digital passport, an Open Badge representing a completed course, and an Open Badge representing a student ID (all as Verifiable Credentials). A relying third-party, such as a potential employer seeking to fill an internship role, may need to verify that a student is over 18, has completed a course on communication, and is a current student. The employer’s website application can ask the student to provide this discrete information using their wallet and the student can do this without revealing any of the other information in those credentials like their date of birth, address, photo, or even the name of the school they attend. And all of this information can be verified without contacting the issuers of those credentials. Open Badges 2.0 can’t do this.
Verifiable Credentials put learners in the center of a trust triangle with issuers and verifiers. They also add an additional layer of verification for the recipients. Open Badges can take advantage of this, be the first education-focused digital credential spec to promote personal protection of and access to data, and be part of the growing ecosystem that is exchanging Verifiable Credentials.
It’s worth noting that the human readable aspect of Open Badges would not change in a VC version. Issuers can still display web pages for the issued badges and allow recipients to share their badges online from those pages. The difference being that those web pages would not be reliant on for machine verification or consumption.
Join us for this continuing discussion in the next VC-EDU call this coming Monday June 14 (and most Mondays) at 8am PDT / 11am EDT / 4pm BST / 5pm CEST. This call is public and all are welcome to join. For this Monday’s call (6/17), the zoom info has changed:
https://us02web.zoom.us/j/89426035740?pwd=dmQ0QS9wMUdFaGo0eFcwbkplV3RjUT09