W3C home > Mailing lists > Public > public-credentials@w3.org > June 2020

[MINUTES] W3C CCG Verifiable Credentials for Education Task Force Call - 2020-06-08 12pm ET

From: W3C CCG Chairs <w3c.ccg@gmail.com>
Date: Tue, 09 Jun 2020 19:24:20 -0700 (PDT)
Message-ID: <5ee04454.1c69fb81.ecfa3.07f5@mx.google.com>
Thanks to Nate Otto for scribing this week! The minutes
for this week's CCG Verifiable Credentials for Education Task Force telecon are now available:

https://w3c-ccg.github.io/meetings/2020-06-08/

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
CCG Verifiable Credentials for Education Task Force Telecon Minutes for 2020-06-08

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2020Jun/0004.html
Topics:
  1. Introductions & Reintroductions
  2. Educational Credential roundup
Organizer:
  Joe Andrieu and Christopher Allen and Kim Hamilton Duffy
Scribe:
  Nate Otto
Present:
  Kim Hamilton Duffy, Nate Otto, Juan Caballero, Allan Third, Jim 
  Kelly, Chris Winczewski, Hans Pongratz, Leonard Rosenthal, Jim 
  Goodell, Joshua Marks, Hamza Ikram, Laura Jaurequi, Stuart 
  Freeman, David Ward, Adam Lemmon, Lluís Alfons Ariño, Victoria 
  Feng, Tzviya Siegman
Audio:
  https://w3c-ccg.github.io/meetings/2020-06-08/audio.ogg

Kim Hamilton Duffy: https://www.w3.org/accounts/request
Kim Hamilton Duffy: https://www.w3.org/community/credentials/join
Kim Hamilton Duffy: 
  https://www.w3.org/community/about/agreements/cla/
Kim Hamilton Duffy: https://w3c-ccg.github.io/meetings/
Hamza Ikram: Present +
Nate Otto is scribing.

Topic: Introductions & Reintroductions

Kim Hamilton Duffy: Victoria Feng
Kim Hamilton Duffy: XDemic
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.

Topic: Educational Credential roundup

Kim Hamilton Duffy: 
  https://docs.google.com/document/d/1pt-VNnjoYgl23Mlu0Tjyax5RgANPBfDijERz0SNYfSo/edit?usp=sharing
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: 
  https://github.com/w3c-ccg/vc-examples/blob/master/docs/edu/university-degree-verifiable-credential.json
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.
Juan Caballero: https://www.w3.org/publishing/groups/publ-wg/
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
Perspective.
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.
Kim Hamilton Duffy: XADES, ...
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]
Kim Hamilton Duffy: ...Baking badge as PDF
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.
Received on Wednesday, 10 June 2020 02:24:35 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 10 June 2020 02:24:36 UTC