Victoria Feng: I am the CEO of Xdemic. We simplify the application process for international students who come to the US. I have my colleague Hamza Ikram here, who will be involved in this work. ✪
Jim Kelly: Reintroduction: I am the chairman of the board of PESC, which is a standards body, and an independent consultant. Former CEO, ECE Educational Credential Evaluators which was for evaluation of foreign credentials. My focus is international education and interoperability in all its forms. ✪
Kim Hamilton Duffy: Thanks. Look forward to a focus on PESC in a future call. ✪
Kim Hamilton Duffy: In the parent group of this, the CCG, there are a lot of people focusing on interoperability of Verifiable Credentials. When I say interoperability, I mean in the tech stack: what to choose for signing, claim etc. But also at the identity layer. In Verifiable Credentials, we've not been so focused on the schema as much as the wrapper (the envelope) ✪
Kim Hamilton Duffy: Here's an example that I pasted into IRC. It's a university degree credential, possibly informed by Open Badges, but streamlined for verifiable credentials. But it's not based in any education-community standard. We have an opportunity with the people on this call to make sure the samples are informed by the work of the people in education. ✪
Kim Hamilton Duffy: We've got conversation with networks as well as standards bodies. e.g. the T3 Innovation Network which is pushing ILR pilots. ✪
Kim Hamilton Duffy: A big focus at T3 with the "ILR Wrapper" is interoperability at the "envelope" layer, so that a "learner wallet" could accept a wide range of credentials and understand key metadata about the credentials. The much harder work of mapping the credentials to machine-readable content isn't included. The ILR Wrapper is a key first step to get everybody to talk in the same envelope, but it doesn't let you understand the claims. ✪
Kim Hamilton Duffy: The Credentials Community Group is not a standards group, but what it does is incubate proposals to turn over into standards development processes. What can we do to help that along, and how can we turn over our results as recommendations, not assuming that they are the final versions. ✪
Kim Hamilton Duffy: Through Verifiable Credentials, it is possible to version ways of using them over time, but we want to make sure that we have the best possible starting point to express educational claims. Also we should draw people's attention to which standards bodies people need to be working with and should draw inspiration from. ✪
Kim Hamilton Duffy: One thing I want to call out as out of scope is that while we want to create samples that are using best practices (e.g. pointing to competency frameworks and learning pathways), we're not building for an "end state" (for example in higher education) where higher education is fully reformed from design to delivery to recognition to be rooted in competency-based assessments so that in theory learners are getting these credentials as they ✪
Go: not just the end of course or end of program credential. ✪
Kim Hamilton Duffy: That's going to be a whole lot of work. We don't want to assume that we're at this end state. We want to build out credentials that people are using right now in prototype and go from there. ✪
Kim Hamilton Duffy: This is one of our first collaborative community work items. Let's set a few requirements. Must be a VC. Must use Linked Data deeply. Not just an XML string or a base64 string embedded in the credential. We want to talk now about payloads that are actually linked data and designed for interoperability. ✪
Kim Hamilton Duffy: There are interesting cases where you want to have a hybrid of machine readable data and some human-intended presentation, such as an image representing the accomplishment or a PDF. ✪
Kim Hamilton Duffy: We want to be international-aware. A lot of the networks like T3 are US-focused, but the standards that are coming out are intended to be globally useful. ✪
Kim Hamilton Duffy: We want to be able to understand what these credentials look like in a few different locales. For example in Europe, there is the EDCI. ✪
Kim Hamilton Duffy: Possible sources of inspiration: Nate Otto (ottonomy) and I did a paper a few years back modeling Open Badges as Verifiable Credentials. This might be interesting in some cases because OB already has strong adoption and an ecosystem. Maybe the best of both worlds. The ILR Wrapper effort has some samples that might be relevant for this use case. Anything like schema.org terms and types, someone called out some examples there. ✪
Kim Hamilton Duffy: CEDS is listed. And any others. I called out a few working examples. The one that has the most detail on it is is the "course/program certificate". It has a couple examples of what you see in the wild. This is a very common thing that people want to build samples for. ✪
Kim Hamilton Duffy: This has gone through some mapping from human presentation to data. What are the fields? I won't go to the details yet, let me go to the other examples first. ✪
Kim Hamilton Duffy: Second working example is a diploma. In terms of the content, maybe the format is roughly the same as ex1 but it's a different type of accomplishment. ✪
Kim Hamilton Duffy: Example 3 transcript. (more complex). Example 4 EDCI, required to be compatible with XML signatures for EIDAS. There may be some examples that come out of that for XML-based transcripts. ✪
Kim Hamilton Duffy: Example 5 is an "Open Skills Assertion", describing a competencies. This asserts a competency directly instead of through a "defined achievement" ✪
Kim Hamilton Duffy: So maybe we have something here that is a "really good start". This also points to the vocabularies and definitions that we could be using. For example the Credential Engine Registry and CTDL vocabulary, which you can use to browse types. ✪
Kim Hamilton Duffy: I want to pause here for feedback. ✪
Chris Winczewski: I don't have a strong opinion for what I'm about to ask because we use JSON-LD, but I know that in the VC data model, it was pretty contentious about the conclusion of JWT and plain JSON. Why are we mandating LD here? ✪
Kim Hamilton Duffy: Throughout the pilots there is a strong interest in LD, but we're not mandating. The hard part is the "semantically meaningful types". The difference between JWTs and LD signatures comes down to the signature schemes. That's not really the concern that people in our space are having. The main people using JWTs are using different types of claims where there is not necessarily a history of work representing credential types. I ✪
Kim Hamilton Duffy: It might be worth making a call out for what types of use cases we want to support? If people want to support JWTs in our community, there could be another work item for presenting these concepts in JWT and plain JSON instead of JSON-LD. ✪
Kim Hamilton Duffy: I'll track this as a question. A lot of this work is informed by pilots under way, (e.g. in DCC and T3). In that work JWTS haven't been called out yet as an important use case, but I'll add it to requirements and scope in case somebody wants to pick it up. ✪
Kim Hamilton Duffy: Let's dig into Example 1: This is a MicroMasters Certificate; and a UPenn certificate. The MicroMasters cert represents a completion of a series of courses, the Pennsylvania one represents one user's first coursera course. ✪
Kim Hamilton Duffy: Right now we're just looking at how would we model just this credential.k ✪
Kim Hamilton Duffy: We're asking what sort of vocabs we would map these terms to. We have a couple examples here. The first one uses the ILR wrapper with an Open Badges-vocabulary linked data claim as the payload. ✪
Kim Hamilton Duffy: Note that the "BadgeClass" is called out as a linked and separately hosted piece of linked data. That's shown in the next JSON example chunk below. ✪
Kim Hamilton Duffy: Another approach is the "Open Badges as VC approach". This looks a lot like just an Open Badge. We could update this example to say the badgeclass points to the same definition. The main difference would be that the first makes sense if you're doing ILR pilots; the second makes sense if you know Open Badges already. Perhaps you're working toward a state where Open Badges 3.0 (future) supports VC. ✪
Leonard Rosenthal: Somewhat orthoganal, but... In a scenario like this where you know you need human readable and machine readable, you don't want to separate those elements. You could have a single carrier, such as PDF, which I would select for both, and then you have a single machine readable and human readable document. ✪
Kim Hamilton Duffy: Yes, let me call out that these displays can be integrally linked. ✪
Nate Otto: There's a PR to embed open badges in a PDF [scribe assist by Kim Hamilton Duffy] ✪
Kim Hamilton Duffy: ...This means open badges can be bidirectional ✪
Leonard Rosenthal: JimKelly - can you post the link to that PR? ✪
Kim Hamilton Duffy: ...Another effort at IMS: leading with Gabe Cohen for DIDs in Open Badges ✪
Kim Hamilton Duffy: ...Some collaboration, may be interest in 3.0 version to support VCs ✪
Kim Hamilton Duffy: ...There may be pilots to support this in earlier form ✪
Jim Kelly: An alternative, perhaps the way the ILR team approached the way to have a machine-readable component in an ILR is to have two payloads of different format. One is computable JSON the other was the human readable presentation, which could be compressed via base64 or some other method. In that way the human readable component is transportable and storable, but the sum of the semantic knowledge would not be disrupted by it. ✪
Kim Hamilton Duffy: I tried to make an example of that approach with a PDF at one point, but looks like it got mixed up. I'll restore it. ✪
Kim Hamilton Duffy: I was curious to talk about what you're saying in the comments, considering JSON or JSON-LD versions. ✪
Jim Kelly: PESC has a JSON-LD task force that has been working for some time. They have published a method to convert XML to JSON on the fly. That's one thing. The discussion now is creating the recognition that there is the need for JSON (at least JSON) versions of our XML standards. We have quite a few standards. ✪
Jim Kelly: We're talking about starting with the college transcript & HS transcript and creating a JSON version in either JSON or JSON-LD. I don't want to set the wrong expectation; this process is just beginning. We have some tools that will help us create examples of the XML data in JSON, which we can then work to approve quickly. Hoping it won't be an extended process. ✪
Jim Kelly: I can't put a timeframe on it, but it's underway. I have high hopes that it will happen more rapidly than if we were building these standards from scratch. ✪
Kim Hamilton Duffy: That's interesting what you said about the first case, generating JSON or JSON-LD on the fly. Was that done for the...to be able to use JSON-LD signatures? ✪
Jim Kelly: That suggests you already are producing XML and have somebody else who wants it in JSON, or you have received XML and you want to receive it in JSON. It could be used to take the existing standard, convert it, and then plug it into a VC. That would be good to test. ✪
Kim Hamilton Duffy: I think that's the other fork of this effort, trying to do some detective work within W3C to find out what other efforts have been underway to do this work. We've been handwaving around "oh it's all RDF" for too long. ✪
Jim Goodell: I just wanted to ask JimKelly if the PESC workgroup would be interested in working with others from this community. It seems like the JSON-LD experts are in this community. Working together might accelerate the process. ✪
Jim Kelly: I would be more than happy to champion that effort. ✪
Tzviya Siegman: We have metadata in the publishing world in XML for ebooks and audiobooks. There will be some overlap in that community. We might want to explore where that exists. There is a lot of the same information that we'd need to convert to JSON from XML. The Publishing workgroup is what I chair with Wendy Reid and Garth Conboy. ✪
Kim Hamilton Duffy: One of the other discussions I wanted to tee up is from leonardr. We had just stated off-hand "PDF as not machine readable". We're aware of capability to store metadata in PDF, but your comments seemed to indicate a deeper level of storing metadata in PDF than we were aware of. ✪
Leonard Rosenthal: Specific for PDF, the thing is most people think of it as a pretty page without considering the semantics that are behind it. Just as with HTML, you have rich semantics for paragraphs and tables and sections, but you can also associate rich metadata onto any of those objects. You can attach schema.org data directly to individual elements. You can also link between them. Point to an embedded thing in another section, you don't have to ✪
Embed it twice by linking directly to the element. You can even link across documents. Everything is standardized by ISO or IETF (url & fragment) ✪
Kim Hamilton Duffy: One of the avenues of investigation I was doing was Hashlinks vs Trust URIs (sp). To get content integrity hashes on things. One interesting approach: Nano-publications. It's not just "human readable thing vs machine readable thing" each part of the document could have its own rich metadata. ✪
Kim Hamilton Duffy: The other area I wanted to highlight is working example 4. We had Anthony on the call to talk about the EDCI effort a few weeks ago, and how they are using XML verifiable credentials. It does require XML verifiable signatures to be usable for certain European Commission activities. This approach is interesting to me. We have a real world educational use of VC. It's using XML, but it isn't clear how they should do so from the official VC ✪
Kim Hamilton Duffy: From a VC perspective, what sort of guidance can we give for XML based standards now. This ex4 calls out a few use cases where there are deeper examples. ✪
Kim Hamilton Duffy: We're exploring how VC could work with legally binding signatures in Europe. There may be some other use cases along those lines. Please add those use cases if you can. ✪
Leonard Rosenthal: The EIDAS standards are based on -ADES standards. There is a new one being worked on for JSON. It's in process, it will take some time (this year?) to finish up, that could work to create a way to comply with EIDAS requirements and be JSON based. ✪
Nate Otto: Can contact Open Badge Factory for PR for OB-as-PDF [scribe assist by Kim Hamilton Duffy] ✪
Kimhd With nothing else, we can close early. We have a couple areas of investigation. The XML inquiry will take a while, but it would be good to keep adding any comments or discussion in the document. I will take a pass this week to incorporate some of the comments and track investigations. Also add any additional questions about scope or use cases. We will come back to this in the future. ✪
Kim Hamilton Duffy: We will check in on progress and report out regularly, even though we have a packed agenda of speakers the next few weeks. ✪
Kim Hamilton Duffy: Thanks everyone, see you next week. ✪