The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

CCG Verifiable Credentials for Education Task Force Telecon

Minutes for 2020-03-23

Agenda
https://lists.w3.org/Archives/Public/public-credentials/2020Mar/0064.html
Topics
  1. Introductions and Re-introductions
  2. Guest expert Orie Steele presents open source libraries and VC-EDU demos
Organizer
Kim Hamilton Duffy, Joe Andrieu, Christopher Allen
Scribe
Stuart Freeman
Present
Leonard Rosenthal, Orie Steele, Kim Hamilton Duffy, James Chartrand, Adam Lemmon, Stuart Freeman, Nate Otto, Chris Winczewski, Juan Caballero, Nick Hathaway, Joshua Marks
Audio Log
Stuart Freeman is scribing.

Topic: Introductions and Re-introductions

Kim Hamilton Duffy: S_Gallant is Scott Gallant introducing himself
S_Gallant: 20+ years ed tech, heathcare interop
... webshield, also does privacy consulting
Kim Hamilton Duffy: Nick Hathaway introducing himself
Nick Hathaway: Elcocker, 25+ years ed tech experience, working on wallets
Kim Hamilton Duffy: Lauraj is at UWashington
Lauraj: business analyst at U washington, higher ed vc use cases
Kim Hamilton Duffy: Joshua Marks PCG
Joshua Marks: Ims global comprehensive learner spec

Topic: Guest expert Orie Steele presents open source libraries and VC-EDU demos

Joshua Marks: Is there we screen share for this call?
Kim Hamilton Duffy: There are a few libraries that orie called attention to, signature suite, and vc demo
Joshua Marks: Is there a screen share for this call?
... repo of vc examples, we might consider adding our stuff to
Orie Steele: Transmute, works on decentralized identifiers
... demo regarding working with dhs
... open source interop with credentials
Kim Hamilton Duffy: Reminder, links are here: https://gist.github.com/OR13/0b8be9d8c43c2acd2d7cf09f6887a8a0
Kim Hamilton Duffy: Note: if you're using Brave browser, you may have to "lower your shields" for these sites
Kim Hamilton Duffy: Verifier repo: https://github.com/w3c-ccg/vc-verifier-http-api
Kim Hamilton Duffy: Issuer repo: https://github.com/w3c-ccg/vc-issuer-http-api
Kim Hamilton Duffy: Credential handler api?
Orie Steele: Api for interacting with creds on websites
Orie Steele: Other apis are being developed such as did-com
Kim Hamilton Duffy: And badge connect
Leonard Rosenthal: Looking at chapi, appears to be tied to browser implementations
Kim Hamilton Duffy: Stuartf I'll see if we can get another volunteer
Orie Steele: This is addressing long standing issues in the browser space, very browser oriented
Leonard Rosenthal: Server-to-server in the future>
Kim Hamilton Duffy: Stuartf -- one other thought, you can dial in by phone. I can scribe for you while that's happening
Kim Hamilton Duffy: Let me know
Orie Steele: Chapi requests could be put over other media, but hasn't been done yet
Nate Otto: Re server-to-server transmission [scribe assist by Kim Hamilton Duffy]
Kim Hamilton Duffy: ...Spec that operates over OBs called BadgeConnect, part of OB 2.1
Kim Hamilton Duffy: ...Will be publicly available soon
Kim Hamilton Duffy: ...Oauth2 + auth grants to enable users to provide permissions to transfer creds from service to service
Kim Hamilton Duffy: ...Badgeconnect is s2s
Kim Hamilton Duffy: ...Id provider can also be resource for credentials
Kim Hamilton Duffy: ...Need to know domain name of badgeconnect host
Kim Hamilton Duffy: ...Once it has permission it can send creds
Kim Hamilton Duffy: ...Api is fairly extensible
Error: (IRC nickname 'andy_' not recognized)[2020-03-23T15:39:15.678Z] <andy_> Badge Connect API (aka OB 2.1) is public (still Candidate Final) at https://www.imsglobal.org/activity/digital-badges
Kim Hamilton Duffy: ...Content can be flexible
Kim Hamilton Duffy: ...Interested in broader conversation about compatibility, and IMS is interested in VC alignment
Kim Hamilton Duffy: ...If compatible, we should talk about how this would work
But yes
Orie Steele: Spec about badge connect is interesting, would like to check out reference impl and examples
... could be dropped into the demo we just saw on issuer side
... possibly a direct integration
Nate Otto: Badge Connect (Open Badges 2.1) is now in "Candidate Final (Public)" status available here: https://www.imsglobal.org/spec/ob/v2p1/ more links here https://www.imsglobal.org/activity/digital-badges
... vc signature suites being worked on by transmute
... same key to issue multiple types of credential with json web token
... or linked data
... gpg signature suite does the same but using gpg keys
Leonard Rosenthal: Any consideration or plan for ??? standard
... etsi standard
... EU standards must comply
Nate Otto: Discussion about selecting suites and how we can avoid confusing users about what can communicate with what
... what do we need in terms of agreements to assure that compatibility happens
Orie Steele: There's a risk that diff companies go off and do similar looking things that don't interop
... agree to a key representation
... number of reasons for everyone to use jwk
... works with JOSE, many things already work with this
Kim Hamilton Duffy: Thanks Leonard!
... agree on signature representation
... reccommend jose
... as a community identify software that is aleready widespread and adapt it instead of building whole new stacks
Leonard Rosenthal: Badge connect considereing signed software statement signed with jwk in jose
... key question "what should we do to select did methods and sig suites to ensure compatibility"
Kim Hamilton Duffy: Already it was unclear what the best choice
... ccg is acting as a gatekeeper where it shouldn't, we're not crypto experts
... vc data model spec complicated if using jots
Orie Steele: See the (harmful) optionality here: https://www.w3.org/TR/vc-data-model/#jwt-encoding
... we're green field so can save effort by choosing existing standards
Orie Steele: (Harmful is my opinion)
... what is the context of vc examples?
Orie Steele: Starting point is spec, look for examples
... make things that look like the example
... problem when the example is very hypothetical
... try to prepare examples with real sigs that really verify
... pick did method that you can actually implement, did:web is good for this
... anything that uses a browser can use it, no need for lots of blockchain signatures
... a few things you have to do, define the context and host it
... markdown file in link defines the format
... links have to be resolvable for the example to make sense
... context definition for this defines cmtr property
... can contain anything because this spec is in flux, as we become more confident in the structure become more specific
Leonard Rosenthal: Disagree, it's not required that the documents be available and resolvable
Orie Steele: @Context is REQUIRED :)
Leonard Rosenthal: Must be present but need not be resolvable
... curious about harmful nature of jwt optionality
Orie Steele: Jwt has reserved terms that come from jose, want to have short names and make sure no one overrides them
... when extended for vc having things always map resulted in having the data end up in various optional places
... makes implementation complex
... trying to verify means figuring out which options the issuer chose
Leonard Rosenthal: Ah - I see what you mean. I misread that part of the spec. I read it as requirement to use the JOSE/JWT naming and *not* the VC ones
Orie Steele: "For backward compatibility with JWT processors, the following JWT-registered claim names MUST be used instead of, or in addition to, their respective standard verifiable credential counterparts:"
Leonard Rosenthal: Yeah, missed that "or" - we should get that fixed :)
Kim Hamilton Duffy: If uris are missing and terms are defined, there may be security problems, or problems invalidating
Orie Steele: Yes :)
... longer discussion will follow up
Anybody here?