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 ✪

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] ✪

Nate Otto: Not sure how to structure this, i.e. who is issuer, is there a chain of claims? ✪

Nate Otto: Peer Claims paper: https://bit.ly/peerclaims-rwot6 ✪

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 ✪

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] ✪

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 ✪

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 ✪