Alka Gupta: Hi, Alka Gupta from GlobalID. I think Greg Kidd introduced what we do a while ago. This is my first call, happy to be here and see where the group is wrt. progress. ✪

Manu Sporny: We're going to move the agenda around a bit to dovetail things together. We're going to start with Blockchain. ✪

Manu Sporny: A number of us are still trying to get cleared to discuss this publicly, but in general, we are inviting a number of organizations involved in blockchain and identity and credentials to present in 30 min chunks over the next two months. ✪

Manu Sporny: https://github.com/WebOfTrustInfo/ID2020DesignWorkshop ✪

Manu Sporny: The primary purpose is to get some cohesion around identity and blockchain as it applies to verifiable claims. We might get some ID2020 discussion. How do you make sure someone is control of their data? What are the technical solutions? We're not reliant upon blockchain but we think there a number of technologies that could be useful to us in the world of verifiable claims. ✪

Manu Sporny: Any questions about this? ✪

Nate Otto: Is there any orgs you can announce that will be participating in these presentations? ✪

Manu Sporny: ID2020 is being host by the United Nations to have pilots running by 2020 and have the under identified have credentials by 2030. A number of the verifiable claims folks are going to be participating to help define what the architecture looks like. We'll be publishing papers and discussions afterwards. ✪

Shane McCarron: I know the W3C is holding a blockchain workshop going on and I was wondering if there is cross-pollination going on. ✪

Manu Sporny: Yes, there is. Several of these people are submitting position papers. The W3C is looking at non-financial industry use cases. Clearly there are financial industry uses case, but they want to discuss others. ✪

Dan Burnett: Data Model doc: http://opencreds.org/specs/source/claims-data-model/ ✪

Dan Burnett: I've put a link for the document. This is document is a reverse engineering of some concrete examples that the Credentials Community Group created. We've supported JSON, JSON-LD and WebIDL. We've tried to capture that data model and show how it can be represented in different serializations. ✪

Manu Sporny: We're talking about section 4.1.2 now - Expressing Claims in JSON ✪

Manu Sporny: Now we're moving to section 3.3 ✪

Dan Burnett: The spec talks about expressing basic claims in section 4.1.2 - that's the simplest example. I've been working from examples for most of this. So, let me know if I got something wrong. The other change is moving the word credential back into the document. I also mention identity, it's going to be hard to get away from that. Any comments on the spec so far? ✪

Manu Sporny: Thank you for working on this Dan. It's a great direction. At some point, we're going to have to tell the WPIG we are ready to take a voting package to the W3C membership for a vote. What should we focus on for the next month to do that? Where are we with the spec now? Can we hand it over to a WG? Of not, what should we focus on to get there? ✪

Dan Burnett: There is a bunch of linking/editorial cleanup that I'll be doing. It needs and introduction and abstract. I plan to write a first draft of that so people can review. It's important for people to look at the data model and how it is going to be expressed in those formats. We need to make sure there is nothing missing or wrong. ✪

Manu Sporny: Thank you, Dan. ✪

Manu Sporny: It's worth mentioning that the content in this document is something that we should have agreement on in the CG and VCTF. We are agreeing on that this is what things should look like. The best thing that could come out of this is a bunch of large organizations saying this is the best way to proceed. That they would be willing to deploy it to there customers. ✪

Manu Sporny: If you are on this call and are from a large organization, let us know what you think, especially if you disagree with the direction we are taking we. We do not want that to come out later. We want to address the issues upfront. ✪

Dan Burnett: One other thing I did want to bring up. This document does talk about identities (something we said we weren't going to talk about). The reason it is in there is because the credentials/claims dataset makes reference to that. Should that stay in? Should the identity pieces be moved? I don't have a strong opinion on but I suspect others will. ✪

Nate Otto: My question is on expressing claims in JSON vs JSON-LD. What is the benefit we see for expressing this in regular old JSON? ✪

Eric Korb: @Burn typo "4.2.2 Expressing Claims in JSON-HD" should be "JSON-LD" ✪

Dan Burnett: @Erkorb thanks ✪

Manu Sporny: What is the value of plain JSON claims and how do you do signatures on that. In the survey feedback we put out, there was one large telecom company interested in self-claims that doesn't need digital signatures. If the model is flexible enough to do self-claims (things you type into a form), they had use cases that worked with self claims. The value is dependent upon the use cases. ✪

Nate Otto: And a second question: How do you perform a LinkedDataSignature2015 on plain JSON data? [scribe assist by Nate Otto] ✪

Dan Burnett: @Erkorb unless we want to move to Hi-Def JSON . . . (joking) ✪

Eric Korb: Burn, +1 ;-) ✪

Manu Sporny: That's where it came from. It also came from we have LinkedData Signature stuff and that stuff is controversial in the crypto community. There is a subset that thinks we should use JOSE (JWS, JWT, etc.) If people want to do that, they can. More recently we have changed the LInkedSignature specs to allow the use of JWT-based signatures. They are ugly and nasty, but our hope is to stave off some of the arguments against the VC work because we are saying ✪

Manu Sporny: LinkedData signatures are a nice way to represent them. ✪

Manu Sporny: We're not picking a winner. ✪

Dan Burnett: The definition for an "id" for an Identity should indicate that the identifier doesn't have to be long-lived, but can be (want to be clear that the data model supports both long-lasting IDs and ephemeral ones ... so varying levels of privacy and limited disclosure implications) [scribe assist by Dave Longley] ✪

Nate Otto: Interesting to hear manu say that the LinkedDataSignature2015 spec can be flexible enough to use JWT as well as the core linked data signature method. I agree that would look pretty ugly, but that is an interesting avenue to keep this work open to. ✪

Dan Burnett: @Dlongley okay, will add that. Feel free to submit a PR with precise text if you have it, but if not I'll write it ✪

Manu Sporny: The other question was how to transfer that into a LinkedData signature. You suggested adding a context and that is spot-on and then you can take a signature. We're thinking about a new signature mechanism around JOSE/JWT. If some of the IETF people or others will assist, then we will support it. If it doesn't happen, we'll only have JSON-LD and LinkedData signatures. ✪

Dan Burnett: Yeah don't have anything precise :/ [scribe assist by Dave Longley] ✪

Nate Otto: I think it is important to keep this open to people who don't want to use JSON-LD. ✪

Dan Burnett: This is the second question we got about this. These examples that we show are just examples, not normative. We currently show a signature mechanism with regular JSON. Can we show something else? ✪

Nate Otto: +1 To showing an example of the simplest claim possible wrapped in JWT. ✪

Manu Sporny: That format doesn't exist yet. We have some ideas but don't want people to reject them outright because we haven't thought it through. We can show the non-Base64-encoded version and that would be a good compromise. ✪

Dan Burnett: I would welcome an example from someone. ✪

Nate Otto: Yes, it'll be ugly in the document, (with base64decoded version as well), but that might help people understand why we want to use the LinkedDataSignature2015 instead. ;) ✪

Manu Sporny: https://web-payments.org/specs/source/ld-signatures/ ✪

Manu Sporny: http://json-ld.org/playground/ ✪

Nate Otto: Awesome! Thanks for adding the signed tab to the playground! ✪

Manu Sporny: The LD Signatures spec has more complete examples of what a LD Signature looks like. If you go to the JSON-LD playground, it has support for signatures. You can copy and paste from the signature tab. ✪

Eric Korb: NateOtto, +1 good for comparison ✪

Dan Burnett: That's probably less controversial than plain JSON with a LD Signature. ✪

Manu Sporny: We should definitely demonstrate both signature mechanisms in the spec and be real examples of what we expect them to look like. ✪

Manu Sporny: Any other questions on the specification? ✪

Manu Sporny: This came about after a few of us took a look at the CTI vocabulary. We were trying to take the CTI work and express their credentials using the VC data model. What we hit was a terminology and modeling issue. The way that the CTI uses the term credential is slightly different to the way we use in the CG. ✪

Manu Sporny: We think that there might be a pattern emerging (banking, healthcare, education) use the term credential in slightly different ways. The question is, should we stay away from the term 'credential' and let people use it the way they mean it or should we take on the work of aligning the meanings across these industries. ✪

Manu Sporny: If we don't use it, different verticals can use it. The pro is that verticals figure it out themselves. The con is that there will inevitably be two market verticals that use the term in contradictory ways. ✪

Dave Longley: It would be good if the core, generic format for verifiable claims had a clear use of the term Credential (or a replacement term or set of guidelines) going forward. ✪

Manu Sporny: If we establish our meaning and discourage reuse in the market vertical, at least there is one group trying to shepherd the term through in the use on the Web? The downside is that we won't talk with one of the verticals or they'll just do their own thing. ✪

Nate Otto: Could you highlight what the two definitions are and what their conflict is in more detail? ✪

Manu Sporny: We think this is going to continue to happen. Should we stop using the term or should we encourage the CTI to stop using it. Or is there some middle ground? ✪

Dan Burnett: Dlongley, right now the core doc says that Credential is just the name for the container. Are you saying that is not clear? I think it may be less than we want to say, but I don't believe it is unclear as written. ✪

Stuart Sutton: I think you paint the picture correctly. I think you paint the picture of variation in multiple verticals correctly as well. I think that trying to get the verticals to define the term in the same way may be a fool's errand. The amount of pushback that the CTI group is getting to not calling it a credential is significant. ✪

Stuart Sutton: There is murkiness around what is meant. It is used to describe the thing that describes the substance of the credential. The thing that someone holds is also a credential. There are relationships between the claim and people are also called a credential. ✪

Dan Burnett: I don't think it's unclear, i'm just speaking to difference in definitions for "Credential" w/CTI and potentially other groups (saying we should define it and tell people how to use it with verifiable claims) [scribe assist by Dave Longley] ✪

Stuart Sutton: If we look at organizations that span these groups, they have a lot invested in their literature and how they use the term. ✪

Stuart Sutton: I think the problem with VCTF putting a stake in the ground is that it narrows the definition to a set of claims. Credentials exist independent of claims. That is where the pushback from the credentialing community comes from. ✪

Dave Longley: To speak to the idea of credential requiring claims to exist. Looking at the CTI work, we took it from the other direction thinking claims were out of scope. The VCTF takes the position that you have something that is tied to you. The CTI talks about more abstract things like types of degrees. A personal holding on to the degree doesn't hold the abstract thing. It is more like a certificate. ✪

Dave Longley: https://docs.google.com/document/d/1lKBhagznl4THYQ-Tth8NXXNae5g2XC7S0iEbnPscvmg/edit?usp=sharing ✪

Dave Longley: That's some of the struggle we've had about using the CTI terms in the VCTF work. ✪

Nate Otto: From the badges space, we find that the term "credential" is already very overloaded, and it will be difficult to try to carve out a space for our usage in those overlapping conversations. I like the term, but it is already used in all the ways described and organizations have deep investment in using it as a generic term. There's a big conversation on "are all badges credentials? can all credentials be expressed as badges?" Many different education ✪

Nate Otto: Providers and assessors are picking their own names for what the artifact that they're delivering is (microcredentials, nanodegrees, badges). Use of "credentials" is very common. I think either we operate in this overloaded space (which is possible) or we avoid it by picking a different term. ✪

Dave Longley: Please look at this Google Doc that discusses some of the issues. ✪

Dave Longley: CTI talks about certificate type in the abstract (MBA). In the VCTF work, we're talking about actually getting a credential indicating that you've earned a certificate of this type. ✪

Eric Korb: I echo what Dave has said (we've been collaborating). I'm supportive of the CTI work and the VCTF work. It works to connect them. I support the using the term Credential as a class. ✪

Matt Stone: -1 Certificate ✪

Manu Sporny: Some communities use the term in the abstract sense (CTI) others use it in the concrete sense (VCTF). There are a couple ways out of this. We have no ability to change what the CTI is doing. One option is no change. We use the term credential. We have a strong definition. We don't change and figure out how to model the CTI work. Option two is change the use 'ClaimSet' which is awkward. Or we use the term 'certificate' for the concrete holding and [CUT] ✪

Nate Otto: -0.5 Certificate ✪

Manu Sporny: Remains more abstract. ✪

Dave Longley: To be clear we would map the CTI "Credential" to "CertificateType" in our VCTF JSON-LD context ✪

Shane McCarron: +1 To bagel ✪

Matt Stone: +1 To sharing bagels ✪

Richard Varn: We're not going to solve this issue. Certificate isn't going go down well with the education space. We're building a standard that will be implemented. We're giving name to those things that will be supported by the standard. ✪

Dave Longley: "IdentityCredential" is another thing we've discussed, has both advantages and disadvantages. ✪

Nate Otto: What RichardVarn is describing is essentially the approach taken by Open Badges vs the broader generic term "digital badge" ✪

Shane McCarron: VCredential... not terrible ✪

Richard Varn: If we use an augmented form of the term (e.g. vCredential) we can indicate specifically one of our terms. ✪

Manu Sporny: That is helpful and I can see how it might work. ✪

Nate Otto: +1 To something like "OpenCredential", "vCredential", "IdentityCredential" ✪

Manu Sporny: I like the augmented Credential as well... ✪

Matt Stone: It is folly for us to overthink what a professional or enduser might use to make their statements. They'll use the language of the vertical they are in (degrees or board certification or resume or cv). It's irrelevant to us what they are going to say about their individual verticals. ✪

Brian Sletten: What about iCredential? *ducks* ✪

Dan Burnett: WebCredential ✪

Stuart Sutton: +1 VCredential ✪

Dave Longley: I agree that we shouldn't focus on the end user, just want something that makes sense to the community ✪

Manu Sporny: We're seeing support for modifying the term. ✪

Manu Sporny: We have consensus around NOT using the word certificate! :P ✪

Dave Longley: We're already using "IdentityCredential" in some prototypes we've built that use the Credential Management API ✪

Stuart Sutton: As a member of this group, I support a modified term and avoid a common term like Certificate. ✪

Dan Burnett: I would avoid "vCredential" because some of them will not be verifiable, and it may be confusing to talk about vCredentials and Verifiable vCredentials. Maybe something like "web credential"? ✪

Manu Sporny: I think this modified form would address CTI's concerns with the use of that term. ✪

Dan Burnett: I am happy to change it to "X Credential" until we figure out what we want X to be. ✪

Eric Korb: VerifiableCredential ✪

Brian Sletten: +1 ✪

Nate Otto: +1 ✪

Manu Sporny: +1 ✪

Dave Longley: +1 ✪

Shane McCarron: +1 ✪

Dan Burnett: No, NOT VerifiableCredential ✪

Dan Burnett: +1 Proposal ✪

Dave Longley: +1 To burn ✪

Stuart Sutton: +1 ✪

Eric Korb: +1 ✪

Shane McCarron: I like "vCredential (tm)" ✪

Stuart Sutton: +1 To burn ✪

Eric Korb: Burn, okay "bagel" then, grins. ✪

Matt Stone: -1 Verifiable - it excludes self asserted claims ✪

Nate Otto: Good chat, all. ;) ✪

Dan Burnett: Shane and erkorb, see my reasoning a few lines above as to why v or Verifiable as prefix is problematic in the text of the document. ✪

Shane McCarron: Burn thanks - I had missed that ✪

Manu Sporny: We'll figure out what the modifier is later. We should have a voting package for the WPIG before the meet at the end of June. That gives us a month and a half. It's doable, but we need to make better progress. ✪

Eric Korb: +1 Great call ✪

Matt Stone: Thanks everyone ✪