The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back


CCG Verifiable Credentials for Education Task Force Telecon

Minutes for 2020-08-24

Good morning!
Juan Caballero: Now we're curious what the F stands for
Juan Caballero: Good evening from Berlin!
Anthony Camilleri: Haha - Fisher. I just didn't like all the underscores
Kim Hamilton Duffy: Says something [scribe assist by Kim Hamilton Duffy]
Laura Jaurequi is scribing.
Anthony Camilleri: I always thought the text summaries were bot-written.... :$ ... will volunteer for scribe next time

Topic: Introductions & Reintroductions

Hello, all. I
Kim Hamilton Duffy: Philbarker
Hello. I'm having problmes with Linphone. I'm a member of Trust Over IP Internet of Education Task Force. I'll join chat for now
Kim Hamilton Duffy: Moving on to universal wallet

Topic: Universal Wallet

Kim Hamilton Duffy: Universal wallet proposes a data model interface (api) -- experimental implementation
...advantages: covered by w3c license agreement;
Orie Steele: +1 To experimental implementation -- title should include interop and experimental as it is transitioned to the w3c
Kim Hamilton Duffy: Wallet is like an SDK or api -- doesn't have to be used; can be applied to multiple use cases and interoperability
...can use spec without opensource implementation
...ip protected as well
Orie Steele: Yes, we probably should have named the spec, "Universal-Wallet-Interop-Spec" and the sample implementation "Experimental Universal Wallet Implementation", even if the software package does not contain the word "experimental".
...common for proposals to be discussed in DIF and IEEE
...credential exchange spec is in draft
...secure data store relevant to wallet storage
...Learning economy major contributor and open wallet architecture
Jacksohne: Speaking
...Learning economy building universal wallet out of necessity for interacting with partners
Orie Steele: Some more "experimental ui for the experimental wallet" here: https://material-did.com/?path=/story/universal-wallet-wallet-cards--unlocked :)
Kim Hamilton Duffy: Need code owner -- will be Nathan and T?...
Juan Caballero: I am here
Juan Caballero: Agenda is here
...get involved via ccg, github, etc. Also get involved in DIF; send questions to Kim
Juan Caballero: If anyone wants to propose an agenda item for a future DIF interop meeting or email me directly at communication at identity.foundation about it
Adrian Gropper: What makes this a "learner" wallet?
Kim Hamilton Duffy: Add yourself to the queue if you have strong objections to adding experimental implementation
Orie Steele: Asking about implementing a software implementation along side the spec? Should we move Transmute code to CCG?
Kim Hamilton Duffy: Speak up if you have concerns
...kim is supportive of experimental implementation -- very helpful to demonstrate POC;
...experimental implementation doesn't have to be used...
...we want open source and open implementation available to all learners
...not tied to a specific wallet vendor; interacts with many identity proof mechanisms
Adrian Gropper: I imagine a learner wallet is a customized version of a wallet that supports the "universal-wallet-interop-spec", which MAY use the "experimental-universal-wallet" [scribe assist by Orie Steele]
Adrian Gropper: Question -- what makes this a learner wallet vs. just a wallet
Kim Hamilton Duffy: Learning wallet a certain kind of universal wallet -- themed in different ways specific to learners
Orrie:types of industry specific wallets are conformant with standard but support open interop standards?
Adrian Gropper: Will there be anything different than the data model between patient walled and universal wallet?
Orrie: speculating about differences...
Kim Hamilton Duffy: Interesting that this has a data model and interoperable library / interface
...in addition differing credentials ...
Orie Steele: I consider defining abstract interfaces data model work :) but thats just my personal opinion. there have been concerns raised about the "interfaces" and if they can be generic enough to be supportive of all formats
Kim Hamilton Duffy: Modeling verifiable credentials next
Thank you. dropping for remainder.

Topic: Modeling Educational VCs

Sry my line is keep dropping
Kim Hamilton Duffy: Document has several working examples; action items moved to a specific section
...action item-- support xml serialization focus
Orie Steele: Interested to see the XML serialization of VCs added to the W3C VC Data Model.
...json too
..."has achieved" is being adopted
...better for broader types of achievements
...use of pdf's for the wrapper? follow up work item...
Orie Steele: I have done experiments embedding stuff in PDFs... CBOR-LD can help.
...issues in document -- working example 1
...ILR wrapper is referring to criteria in alignment framework --
...ctid supports versioning -- is advantage
Orie Steele: We should consider cannonical URLs for credential Ids, that support CTID, but also other formats
Nate Otto: Ctid = CT id, that's been assigned by a specific registry provider (CER). It serves as an identiifer or alternate identifier for a credential. It is possible to use the ctid to get information about the credential but ctid itself is just a uuid. It's great metadata to have for any ecosystem referencing credentials in the CER, but I don't think it serves all of the functions that you were mentioning in terms of versioning (i.e. 2 different versions of the same credential in the CER would have the same CTID). How I would think of it is a property on an achievement description (credential def) that is an alternate id for a credential with a specific registry.
Simone Ravaoli: +1 To Orie and Nate
Phil Long: +1 For Orie's suggestion
Orie Steele: It sounds like CTID is in the category of randomly, globally unique ID, and I would suggest that for purposes of consolidating the data model we consider a canonical URL representation for identifiers that support identifiers like ctid as argument but also extensible to support others
Nate Otto: +1 To Orie's proposal: It is nice to have a canonical URL identifier that when fetched can reveal more information about the credential definition that is the canonical representation of the credential.
Tzviya Siegman: Agrees with Orie about keeping it separate
Nate Otto: (I could describe OB's approach to version identification if somebody wants to q me for it https://openbadgespec.org/#version )
Anthony Camilleri: We have quite a bit we would like to contribute to this discussion. the appropriate thing is to just comment the doc extensively?
Nate Otto: Open badges use description -- does not need to know about versioning but needs badge class
Phil_Barker: On "resource" in ctid: Credential Engine uses ctids on Learning Opportunities and Assessments as well as Credentials
...url badge class can be the latest version or defined
...version can define the type of credential
Orie Steele: Yep, big +1 to being careful about forcing folks to worry about versioning if they don't need to.
Nate Otto: Where are we at with vocabulary "has achieved"?
Orie Steele: Schema.org will take PRs :)
Kim Hamilton Duffy: Ccg can be temporary landing place
...could also be schema.org
Phil_Barker: Is this relevant https://schema.org/hasCredential
Orie Steele: Schema.org has the benefit of helping align with SEO, which might be favorable, for reputation driving credentials
Orie Steele: Yep, +1 to bucketing in CCG and preparing to register a batch to schema.org
Tzviya Siegman: If more than one term in shema.org we should batch terms...
Anthony Camilleri: Not sure the super-personal data in credentials necessarily aligns with schema.org public data prinicples....
Juan Caballero: Thx all!