The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2018-04-05

Action Items
  1. Serge will contribute a use case paragraph to Peer Claims Paper
Joe Andrieu, Christopher Allen, Kim Hamilton Duffy
Kim Hamilton Duffy
Kim Hamilton Duffy, Nate Otto, Serge Ravet, Val Thomas
Audio Log
Kim Hamilton Duffy is scribing.
Nate Otto: We'll have a short call because a small group due to IIW
Nate Otto: I'm Nate Otto from Concentric Sky; Kim is scribing
Nate Otto: We'll look at paper from RWoT: Open Badges are Verifiable Credentials
Nate Otto: Let's do intros
Serge Ravet: Excited to join Open Badges and Verifiable Claims
Val: working with government of Canada. Usecase for VC / Blockchain prototype was accepted
RandyMcDonald: primarily interested in use cases for education development
Section: Reviewing Open Badges are Verifiable Credentials paper from RWoT
Nate Otto: Feel free to speak up any time
Nate Otto: Providing a short overview of concepts
Nate Otto: Review roles of host, displayer, verifier
Nate Otto: Paper reviews various threads such as VCs, DIDs, DID layers, and discuss how they work together
Nate Otto: We're building general purpose technologies, can use for different types of claims. would like to develop critical mass for technologies/standards that work well together, to build network effects
Nate Otto: Also important is usability, privacy protection
Nate Otto: Paper has examples of expressing claims in different formats
Nate Otto: Motivation - OB and VC are complementary, should fit together nicely.
Nate Otto: Similar data models, signature and verification methods
Nate Otto: Blockcerts OB extension draft uses LD signatures and verification
Nate Otto: 2 Different communities building software that's not currently compatible. can harness efforts better by ensuring we're aligned
Nate Otto: What is the core kernel of value within each initiative?
Nate Otto: OB - defined achievements. Ontology for specific achievements that matter within a community, and criteria to qualify
Nate Otto: BadgeClass is a defined credential; 2.0 also includes VCs as endorsements
Nate Otto: VC specification has no rich vocab about what sort of claims you express, defined achievements
Nate Otto: Has strong general structure for signing and verification
Nate Otto: OB has strong adoption, millions of issuances
Nate Otto: Paper describes 2 different options for joining
Nate Otto: For joining VCs and OBs
Nate Otto: First, make a claim that a recipient "holds" a credential
Nate Otto: "Holds" is a term from VC community, meaning recipient holds a credential
Nate Otto: The claim is "recipient holds the credential"
Nate Otto: Option 2 -- claim is an OpenBadges Assertion.
Nate Otto: Subject is the id of the assertion, not the subject
Nate Otto: Possible with option 1 to use hashed email (original id system from OB)
Nate Otto: I.e. "this recipient goes with this claim"
Nate Otto: In order to make work well with wallet software, we need to understand VC wallet expectations
Nate Otto: There are cool advantages to identifiers like DIDs
Nate Otto: If we're successful, probably most implementations will use DIDs in the future, but will remain compatible
Nate Otto: Gives 1 layer of correlation protection
Nate Otto: "Claim recipient holds a credential" vs "claim assertion exists"
Nate Otto: Paper is verbose because we're discussing 2 different methods and implementation
Nate Otto: Next phase is prototyping; prove that 1 can work well. Start with option 1 bc better aligned with VC ecosystem; expecting id of recipient. Won't be able to authenticate a user with an assertion
Nate Otto: Expect that if option 1 prototypes are successful, we'll just junk option 2 and remove all references in the paper.
Nate Otto: Let's look at a couple more use cases
Nate Otto: Recipient id'd by DIDs
Nate Otto: OB uses OB identity object, frequently email address (can be hashed)
Nate Otto: Hashed provides a little bit of privacy. Not perfect, can still be correlated, but helps
Nate Otto: ID string as IRI format
Nate Otto: Can use DIDs in OB via type "id"
Serge Ravet: We still have 1 issuer/1 recipient
Serge Ravet: Other use cases require intermediary
Serge Ravet: Recipient signs badge before training. After training, issuer signs. To make fully valid, line manager has to sign
Serge Ravet: In this case, it's a workflow for recognition
Serge Ravet: Extension -- perhaps it expires after 1 year and line manager needs to resign
Serge Ravet: We might want to expand vocab as well
Kim Hamilton Duffy: Yes there are multiple signatures in a Verifiable Credential. Called chained signatures. Can be ordered or not ordered. [scribe assist by Nate Otto]
Kim Hamilton Duffy: I'm thinking through Serge's scenario a bit more. [scribe assist by Nate Otto]
Kim Hamilton Duffy: Maybe the line manager's claim is the one that has the expiration date that gets renewed later [scribe assist by Nate Otto]
Kim Hamilton Duffy: This is a really good example to test our assumptions. [scribe assist by Nate Otto]
Val: to add to Serge's example. From work force side of things, if we think about VCs as learning outcomes (received training, attained knowledge).
Val: in workplace, there's the additional level of applying skills (i.e. not just received learning)
Val: this is getting a lot of interest wrt workforces of the future
Val: applying the knowledge becomes an additional credential that can travel with the individual
Nate Otto: Not sure how to structure this, i.e. who is issuer, is there a chain of claims?
Nate Otto: Peer Claims paper:
Nate Otto: Above is peer claims paper. feel free to add use cases
Nate Otto: Workflow involving multiple steps (self assertion and recognition by peers
Kim Hamilton Duffy: +1 To that
Nate Otto: Turn this into a paper, examples
Nate Otto: Have to keep pipeline full
Nate Otto: Let's write up over next 2 weeks
Val: fed gov project is called "talent clouds"
Val: goal us to create discoverable skills. They can test these as part of that effort
Kim Hamilton Duffy: Many of the existing examples are driver licenses or passports. [scribe assist by Nate Otto]
Serge Ravet: Is anybody working on contracts on VCs?
Kim Hamilton Duffy: This opens us up to claims that are not just on the single-issuer-single-recipient spectrum [scribe assist by Nate Otto]
Kim Hamilton Duffy: I would want to look into that [scribe assist by Nate Otto]
Serge Ravet: Learning contract would perhaps be a better model
Kim Hamilton Duffy: I agree -- that naturally seems to have the concept of a lifecycle built in, whereas a credential is more of a static thing. What we're all talking about is something with more possible states [scribe assist by Nate Otto]
ACTION: Serge will contribute a use case paragraph to Peer Claims Paper
Nate Otto: Rest of the paper covers DID as an issuer
Serge Ravet: Confirmed!
Nate Otto: Shows verification via LD signatures, and Blockcerts specifically
Nate Otto: Validator is the key component to prototype
Nate Otto: For issuing, the issuer needs a DID. for prototyping, we can work around. Hard part is to authorize an issuer to issue badges but not do other things. Out of scope for this paper, but comes up more in peer claims paper
Nate Otto: Above is the hard problem on the issuer side
Nate Otto: Host/backback needs to understand new vocabulary
Nate Otto: Hard parts are validator. understand new structure. look for holds, etc. Over the next month, Nate plans to prototype
Nate Otto: Hope to have feedback soon thereafter regarding option 1 success
Nate Otto: If we prove it's a good way to deliver OB, that opens up to other use cases e.g. workflows
Nate Otto: Displayer needs to understand new display. Probably easiest to transform into existing structure. This would make cost for existing implementations zero
Nate Otto: Next steps are prototyping validator support for option 1, issue blockcerts to verify, engage with RWot to verify other signature methods
Nate Otto: We'll prototype in at least 1 backpack
Nate Otto: Did authenticator that uses 1+ method
Nate Otto: Gov of BC has authorized a project. Hired Markus Sabadello to build DID auth method
Val: being led by John Jordan
Val: called Von network
Val: using a developer exchange, using hyperledger
Nate Otto: We might be able to collaborate and use their DID auth prototype
Kim Hamilton Duffy: For next meeting, would it be worth going into the peer claims paper a bit? [scribe assist by Nate Otto]
Nate Otto: Yes
Nate Otto: Next meeting, we'll talk about peer claims with Serge's additions