W3C home > Mailing lists > Public > public-credentials@w3.org > July 2021

[MINUTES] W3C Call - 2021-07-19 12pm ET

From: W3C CCG Chairs <w3c.ccg@gmail.com>
Date: Tue, 20 Jul 2021 12:18:44 -0700 (PDT)
Message-ID: <60f72194.1c69fb81.85b46.b89a@mx.google.com>
Thanks to ottoonomy and Nate Otto for scribing this week! The minutes
for this week's  telecon are now available:

https://w3c-ccg.github.io/meetings/2021-07-19-vc-education 

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

----------------------------------------------------------------
 Telecon Minutes for 2021-07-19

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0108.html
Topics:
  1. Introductions/Reintroductions
  2. Introductions & Reintroductions
  3. Announcements & Reminders
  4. Do we need IRC still when we have Jitsi?
  5. Need IRC w/Jitsi?
  6. Open Badges 3.0 proposal review
Organizer:
  Wayne Chang and Heather Vescent and Mike Prorock
Scribe:
  ottoonomy and Nate Otto
Present:
  Kerri Lemoie, Phil L (P1), Marty Reed, Steve Gance, Adam Lemmon, 
  Doug Belshaw (WAO), Simone Ravaioli (Digitary), Serge Ravet, 
  Gerard Pruim, Sharon Leu, Geoffroi Garon-Epaule, Mark Miller, Dan 
  Blickensderfer, Nate Otto, Ozgur Y, Kim Hamilton Duffy, Don 
  Presant, Kimberly Linson, David Ward, Jackson Morgan, Taylor 
  Kendall, Damon Tindall, Colin, Anthony Ronning, Lohan, Keith 
  Kowal, Stuart Freeman, Brent Zundel
Audio:
  https://w3c-ccg.github.io/meetings/2021-07-19/audio.ogg

<doug_belshaw_(wao)> Hey all
<phil_l_(p1)> Hey Doug - good to see you here!
<phil_l_(p1)> Hear you fine
<kerri_lemoie> Thanks for your patience. Getting started 
  momentarily
<doug_belshaw_(wao)> Could you paste it in the chat please?
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/
Kim Hamilton Duffy: 
  https://docs.google.com/document/d/1dxjsfu1MDPlfb5Q3Ry-KEDYX2gj5WNkFqw1esyki-sQ/edit#
<phil_l_(p1)> Scribe list is not public (at least not accessible 
  to me)  (FYI)
ottoonomy is scribing.
Nate Otto is scribing.

Topic: Introductions/Reintroductions

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.

Topic: Announcements & Reminders

Kim Hamilton Duffy: https://w3c-ccg.github.io/announcements/
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.
https://www.eventbrite.com/e/user-experience-in-ssi-an-iiw-special-topic-12-day-virtual-event-tickets-159946001797
On Thursday this week, there is a user experience group half day 
  experience in self-sovereign identity (8am PT - 1pm)
<kerri_lemoie> Thanks! @Lohan

Topic: Do we need IRC still when we have Jitsi?

Topic: Need IRC w/Jitsi?

Nate Otto:  It is convenient to scribe in IRC, though I haven't 
  tried it in the web interface.
Kim Hamilton Duffy:  Is there a specific proposal to stop 
  mentioning IRC, or is this just to get community feedback?
<lohan> Would really love to get a calendar invite for future 
  events.
Kerri Lemoie:  We don't need it anymore probably, so we could get 
  rid of it if we need.
Kim Hamilton Duffy:  Ok vote for support with +1 to keep 
  mentioning it, -1 to stop mentioning IRC
Nate Otto: +0
Kim Hamilton Duffy: -1
Anthony Ronning: -1
Marty Reed: -1
David Ward: +0 As long as documentation about it can still be 
  found easily.
Kim Hamilton Duffy:  The sense of the group is clear and 
  apathetic. We will do nothing differently.

Topic: Open Badges 3.0 proposal review

Kim Hamilton Duffy: 
  https://github.com/concentricsky/openbadges-specification/blob/feature/ob3/proposals/OBv3p0/Proposal-Open-Badges-3.0.pdf
Kim Hamilton Duffy:  The link to the presentation is here. 
  Turning over to Kerri to present.
Kerri Lemoie: Slides: 
  https://docs.google.com/presentation/d/1p8fEERiu2mwG_AVD9U6yavfEeF5Uk_Db7Ep-dh5v3Vk/edit#slide=id.p
<kerri_lemoie> PDF proposal: 
  https://github.com/concentricsky/openbadges-specification/blob/feature/ob3/proposals/OBv3p0/Proposal-Open-Badges-3.0.pdf
<kerri_lemoie> PR to IMS Global: 
  https://github.com/IMSGlobal/openbadges-specification/pull/303
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> 2.0 
  https://www.imsglobal.org/sites/default/files/Badges/OBv2p0Final/index.html#Assertion
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.
https://github.com/IMSGlobal/openbadges-specification/pull/303#issuecomment-882651373
<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.
https://kayaelle.medium.com/the-future-of-open-badges-is-verifiable-bce27664a668
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.
Doug: What about breaking changes? Impact?
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.
<phil_l_(p1)> Great job Kerri and Nate!
<doug_belshaw_(wao)> :clap:
<serge_ravet> Thank you for the great work Kerri!
Everybody go comment on the PR
<colin> 👏 👏
<geoffroi_garon-epaule> Great job !
<phil_l_(p1)> :clap:
<taylor> Great work! Thanks 🙏
<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 simplier.
Received on Tuesday, 20 July 2021 19:18:59 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 20 July 2021 19:19:00 UTC