Annie Janssen: Hi, Annie Jenssen - product manager at Parchment. Parchment is primarily an e-transcript company, we have a conusmer company - parchment.com. We have lots of highschools using transcripts - I manage consumer-side of things. Website where highschoolers can log on. Right now adding other credential types. We've partnered with CLA so students can order their credentials, diplomas, certifications, other types of academic credential. ✪
Manu Sporny: Great, welcome to the group. Are you joining the group long term or are you just joining in? What do you hope to get out of the group over the next couple of meetings? ✪
Annie Janssen: I'm joining the group - joining community groups to get an idea of what's going on in the Credential landscape. Working on consumer side, want to make sure I'm in the loop with everything that's going on in the credentialing world. [scribe assist by Manu Sporny] ✪
Manu Sporny: Awesome. Any other questions for Annie before we move on? ✪
Manu Sporny: We need to another round of pings to make sure people have seen the recruiting questionnaire and they will it out. ✪
Manu Sporny: The other thing that is happening right now is this case that we're making to W3C that credentials are worth doing. The first two blog posts are done. ✪
Manu Sporny: We've got a bunch of background material in the second post that strengthens the arguments made in the first post. ✪
Manu Sporny: I've circulated this with people that will be on the call to discuss in the next couple weeks. ✪
Manu Sporny: If you can send me feedback so I can make changes/updates to it that would be great. Initial response from W3C staff has been that it's good and they are appreciative of all the background research that went into it. ✪
Manu Sporny: For those joining late, we've got another 60 orgs that haven't responded yet and we need to ping those. ✪
Manu Sporny: We need Matt Stone, John Tibbetts, Eric, to re-ping people on the list. ✪
Manu Sporny: We need responses to the questionnaire. ✪
Richard Varn: I got a phone call, Gary from ETS and I, and we talked with Accenture and they'll run it up the poll and get back to us about joining. They were worried about time commitment and I told them to not worry about committing a technical expert for every meeting, etc. ✪
Richard Varn: We met with IMS Global and met with someone who is running their credential effort there. They are having initiatives about competency based education another on credentials. It was "Carla Casilli". ✪
Eric Korb: Manu and korb had presented to Carla. ✪
Eric Korb: Carla is have a session at IMS next week on Tuesday. ✪
Richard Varn: She's inviting the right people, etc. She mentioned you've talked with her. ✪
Manu Sporny: Eric and I did a presentation with her around July 9th. ✪
Richard Varn: They will kick off their calls and discussions soon. ✪
Manu Sporny: Thanks for the update Richard, fantastic news on Accenture. ✪
Topic: Roadmap
Manu Sporny: There's one huge multimillion dollar tech company I'm speaking with right now -- they've said they are interested in the work, hopefully they'll join and I can talk about them soon. ✪
Eric Korb: I've been working on vocabs [scribe assist by Eric Korb] ✪
Brian Sletten: I was planning on working on the Use Case document this week. ✪
Manu Sporny: Eric has been working on the glossary. ✪
Manu Sporny: The last document, the Capabilities, kind of sprang out of the detailed blog post, the credentials retrospective. One of the things the W3C staff asked for was a list of capabilities that an open credentials system should have. Because we hadn't written that list down yet, we were able to chat with a few of you offline and come up with that list. The credentials retrospective post above in IRC has a list of goals for a credentials ecosystem and a list of capabilities for that system. ✪
Manu Sporny: There are things like using an extensible data model, ensuring that multiple market verticals can create their own credentials without central coordination. Web-based PKI and digital signatures. These are all capabilities we believe the system should have. We analyze other existing technology matches those capabilities or not. ✪
Manu Sporny: Quite a bit of work has gone into that and I think that will be the first very rough draft of those things split out by area. ✪
Manu Sporny: 4 Bigs areas: Issuing, storing, managing lifecycle, and consumption of credentials. ✪
Eric Korb: @Brian what doc file are you using? Happy to contribute a few use cases. [scribe assist by Eric Korb] ✪
Manu Sporny: We've got features underneath that that we can get from the blog post. ✪
John Tibbetts: I have one suggestion, about the blogs. I thought the post on successes and failures was compelling. But I think what's missing (but not from this document, this is about "what's out there")... if there was a follow on document that says "Here's how the technologies we're working on would deal with this." A sentence or two about what parts of the technology would address the capabilities and so forth would be good. ✪
Manu Sporny: I absolutely agree, but let me give you some background. When I talked to the W3C staff members, and the best way to address it is to say the problem exists, list the problems, then go into all the things people are scared about when talking about credentials, loss of privacy, lack of anonymity, problem solved before, etc. Then talk about all of the things that have been tried before and why they aren't an acceptable solution ... and then leave it there. Don't talk about the solution the CG has created yet because we need to first get people on board that there is a problem and that we need a solution. They've got products, etc. that need these things. Once people are on the same page for the basic philosophy for what we're trying to do. Then we can talk about how the proposal we have, at least from the CG, addresses those capabilities. ✪
Manu Sporny: The W3C staff thought that getting into the CG's solution too quickly that people would fixate on that and it would detract from getting consensus on the high level vision and capabilities. ✪
Manu Sporny: I will try and write the CG solution blog post and so folks like you can take that post and show it as a proposed solution. ✪
Eric Korb: Ek feedback on blog post: Do we need to distinguish between identity and credentials? Is there one? [scribe assist by Eric Korb] ✪
Manu Sporny: Yes, there is a strong distinction that we make in the technical work between identity and credentials. We've also been trying to be very careful to not say that we're trying to solve the identity problem on the Web because it's got huge scope. We're just trying to talk about issuing, storing, consuming credentials. ✪
Eric Korb: Concern that W3C sees it as the same [scribe assist by Eric Korb] ✪
Manu Sporny: Maybe we can try to make that more clear in the blog post. ✪
Manu Sporny: We're going to have to try and make that point clear to them. ✪
Manu Sporny: They've also said they don't want to call it "credentialing" and instead use "verifiable attributes" because it's too generic but that's even more generic to me. ✪
Manu Sporny: Login systems in the blog post are viewed by the browser manufacturers as credentialing systems, some call them light-weight identity systems. I think the credentials CG is the only standards-related group that has a glossary and has gone through the technical differences of specific systems on the Web like persona, etc. and distinguished them from Mozilla Open Badges and other credentialing systems, etc. In the blog post we talk about anything that could be considered an identity/credentialing system in order to case a pretty wide net to catch things people might often bring up. For example, we're talking about credentials and people might say "Oh that sounds like Oauth" and we put that tech in the post even if that technology isn't a good fit for the depth of the problem and what we're trying to get to. ✪
Topic: Credentialing Capabilities and Current Proposal
Manu Sporny: We just want to make sure we address common things that are brought up even if they don't fit. ✪
John Tibbetts: If we walk down the capability list and then say a sentence or phrase for how our proposal addresses the issue. ✪
Matt Stone: I'd like to know in addition to that, some level of certainty that we know about this spec ... is it well understood or do we have open issues that need to be solved, etc. ✪
Manu Sporny: So I'll do "What is our solution, how does it rate on the scale, and how sure are we/what tweaks need to be made with our solution?" ✪
Manu Sporny: The goals are meant to be fairly high-level, they are from our vision statement. ✪
Manu Sporny: The distinction that we're making is that ... that people have asked. ... what's the difference between a "goal" and a "capability" and a "feature". ✪
Manu Sporny: Capabilities are things that the system should do. When you're talking about a credentialing ecosystem, it should be able to do these things, issue, store, manage credentials, etc. ✪
Manu Sporny: Features are not capabilities, it is just a talking point around a piece of software. It's a thing a software product has. Marketing folks can talk about those features. Today we're just going over the capabilities. The things we want a credentialing ecosystem to have. Keep in mind that this list may not be complete and may need to be refined. ✪
Manu Sporny: As we go over the capabilities we'll talk through them, refine them, and they'll eventually find their way into a capabilities document. ✪
Manu Sporny: "Extensible Data Model" -- this has to do with choosing a way of modeling the data that will allow arbitrary statements to be made. ✪
Manu Sporny: This is a fundamental aspect of the W3C's Linked Data/Semantic Web movement. There are open world and closed world systems. The Web is an open world system; anyone can say anything about anyone else. The fundamental data model for doing that at W3C is called the Resource Description Framework (RDF), very flexible, very will understood, under development for 15 years. There are still fights over what the right solution for the Web should be, academics vs. technical experts etc. XML tree model vs. RDF vs. whatever. ✪
Manu Sporny: We've tried to get the right practitioners into our camp and we're using RDF via a JSON-LD syntax. We have a number of reasons why we're using that. ✪
Manu Sporny: Any organization or person should be able to make any claims about any other org or person. ✪
Manu Sporny: "Choice of Syntax" - So the data model is an abstract thing, concepts related to other concepts, this person knows this person who is in the organization and they know another person who has a high school transcript that has this piece of information, etc. It doesn't say how we express it to a computer. ✪
Brendan Benshoof: The core of the issue here seem less in the representation and more in how statements translate to a real state of affairs in the world. ✪
Manu Sporny: So this is about syntax. Syntaxes come and go. There's XML, then HTML, then JSON, then this then that. If we're going to pick something that will be long lived then we should decouple the syntax from the data model that expresses it. Today we're going to pick JSON-LD to express the data model, but if it goes out of favor by 2025, then the data model doesn't have to change. ✪
Manu Sporny: There's a subject, predicate, and object ... in the data model. "Jane likes cookies". Every language works like this. RDF works like this; it's a very flexible data model. We're making an assumption that JSON-LD is great today but it may go out of favor in 10 years. We don't want our solution to fall apart if the syntax goes out of favor. So we create this separation to avoid that. ✪
Manu Sporny: "Decentralized Vocabularies" - A vocabulary is a language that you use to describe something. The language that is important to a Pharmacist or Medical board, is very different from the language someone that is issuing a plumber's license of an electronic transcript speaks. The terminology that they use is very different. We shouldn't require those industry vertical to come to a central place to agree on the language. They should be able to develop their own language independently and innovate in parallel. It enables market verticals to be able to come up with their own solutions and talk about their industry how they want to and not worry about how Google or IETF or whomever wants to talk about their industry. ✪
Manu Sporny: So these vocabularies allow us to create this architecture and then let the people who come up with the credentials to decide the language that's important to them and they don't have to coordinate with us. It may seem like it's common sense, but if you look at, for example OpenID Connect specs, it tells you exactly how you express X, Y, and Z. If anyone in Finance wanted to start talking about insurance IDs, KYC stuff, etc. they'd have to go to IETF and lobby them to have it added to the vocabulary. The IETF should not be in control of how the education, pharmaceutical, etc. verticals mark up their vocabularies. ✪
Eric Korb: Keep going! great to hear you speak [scribe assist by Eric Korb] ✪
Nate Otto: +1 Decentralized vocabularies are great. ✪
Manu Sporny: Apologies if this is a firehose of information, but it's taken us 4+ to get through all of this and it may take time to sink in if it's new. ✪
Matt Stone: +1 Decentralized vocabularies are essential ✪
Manu Sporny: It was so easy for us to integrate and interoperate with mozilla open badges stuff because we've taken this open world approach. ✪
Manu Sporny: This design approach is the reason for that. ✪
Manu Sporny: Web-based PKI. This might be a bit harder to grasp for people who aren't familiar with security. I'll try to explain. Most PKI systems, like those developed in 80's, 90's. They require an X.509 certificate, if you've seen the pad lock on your browser, etc. you're using this infrastructure. In the beginning this infrastructure this was very secure; it was difficult to issue "root" certificates for issuing these for websites. But now the number of orgs issuing root certs has grown to some 280 orgs/etc. The problem is that the US gov't can issue certs for any org on the planet ... and so can China, India, Pakistan. There are times when US and Chinese interests aren't aligned (or whomever). So when you're inside China you get a chinese certificate and they snoop all your traffic, etc. Nation states do this all the time. The other problem with this system is that there has to be a root of trust. In general, your organization has to depend on some other organization for who you can trust. So you have to trust both China and the US to use your web browser in some circumstances which leads to problems. What we're setting up doesn't require you to have this big list of certificates in the same way; you can be picker with who you trust. When you get a credential in this system, there will be multiple signatures on it; one from the recipient, one from the issuer, possibly ones from endorsers. The traditional way this worked was that the system that was verifying the signatures needed to have all of the certificates for all of the organizations out there on your system already. ✪
Manu Sporny: And that meant that centralization was encouraged so you just trusted some big players. ✪
Manu Sporny: Here the playing field is more level where you can decide who to trust. All of the information you need to verify the credential is in the credential or linked to it via the Web. You can have small players claim keys and use them. And the infrastructure is much more scalable as a result. ✪
Manu Sporny: This is important for scalability and a lot of the OpenID Connect and JOSE specs dont' have this stuff. You have to do key management and you can't do it on the fly with the Web. ✪
Matt Stone: If I'm a consumer, if I get a credential in, would I see a list of signed by "company A, person B, endorser C" and they might be any. And it's up to me to decide if I trust those parties? ✪
Brendan Benshoof: +Q What are we doing to allow ease of use for consumers interacting with the PKI? ✪
Manu Sporny: Yes, in general. A credential consumer that receives the credential can decide who they want to trust. They can push the responsibility off to another organization if they want to or do it themselves. As a person receiving a credential, all of this is kind of hidden from you. It's all machine to machine communication that leverages all of this. ✪
Matt Stone: Let's say I'm a chief medical officer at a hospital and I want to see that they are board certified. They send me a certificate. It's signed by X, Y, and their medical school. ✪
Brendan Benshoof: +Q How are we connecting Public-keys to identities on the issuer's end?? ✪
Manu Sporny: Yes. That's the idea. In the current technology multiple signatures aren't implemented yet. ✪
Dave Longley: Is the question about multiple signatures, or is it about who signed the credentials? [scribe assist by Manu Sporny] ✪
Dave Longley: The technology would do the verification of the signatures, and tell you whether or not the signatures are valid and were signed. You can figure out as a user, who did the signatures and who signed it. [scribe assist by Manu Sporny] ✪
Dave Longley: You have a private part of the key, and a public key and can push that out to the Web. [scribe assist by Manu Sporny] ✪
Brendan Benshoof: This means a lot of companies/Industries who previously did not employ security professionals in this context will need to (or oursource)? ✪
Dave Longley: This has a lot to do with it being a web-based system. [scribe assist by Manu Sporny] ✪
Eric Korb: Suggestion that we add - "multilingual" or does JSON-LD do that natively? [scribe assist by Eric Korb] ✪
Manu Sporny: In the system that is being proposed here is more flexible than the existing system and it allows you to do adhoc verification. ✪
Manu Sporny: Yes, JSON-LD does multilingual capability. The data model is multilingual. ✪
Manu Sporny: You can express the name of a credential in every language that has a BCP47 code in the credential itself. ✪
Manu Sporny: "Choice of Storage" -- has to do with letting you store your credential wherever you deep fit. At Google, Facebook, a home server running at your house, in your watch, the recipient controls it and no org can stop them from moving them around. It has a strong analogy with phone number portability. ✪