Kim Hamilton Duffy: We are just at time now. I'll go ahead and get started with boilerplate. ✪
Nate Otto is scribing.
Topic: Agenda review
Kim Hamilton Duffy: Scribe selection. Change scribe appointments. We have one today, Nate Otto (ottonomy). Then we'll move onto introductions, reintroductions, reminders, progress on action items ✪
... Main topic today will be Gabe Cohen from Workday will be presenting their credential schema draft. A few colleagues from workday joining as well.
Kim Hamilton Duffy: Any comments or proposed changes to agenda? ✪
Kim Hamilton Duffy: Announcements and reminders are kind of light for a moment. As you know, we've decided to do our call for scribes in advance. There is an incentive mechanism you can find out about if you volunteer to scribe. Hopefully this will save some time. ✪
... we're still having the dedicated DID calls on Thursdays, focus on DID Resolution. The zoom room is there.
... Those are Thursdays 8pm UTC (1pm PDT)
Kim Hamilton Duffy: A few words about those calls. DID Resolution is not in scope of the working group meetings. These breakout meetings are intended to discuss things not in scope for the official workgroup meetings. ✪
Kim Hamilton Duffy: If anyone has anything to add about that, please speak up. ✪
Dmitri Zagidulin: What is the relationship to the DID working group? ✪
Kim Hamilton Duffy: You reminded me that if you're calling into DID working group, remember schedule is interesting. 4th Tuesday of every month that there is an alternate timezone friendly time. Dan, can you speak to that? ✪
Dan Burnett: Actually it's the 4th and 5th tuesday where it is timezone shifted. 4th week of month is convenient for US/Asia pacific. 5th Tuesday when occurs is convenient for Europe/Asia pacific. There is a call this week in 6 hours. There is a call next week at a time convenient for Europe and Asia Pacific but not North America ✪
Kim Hamilton Duffy: Last announcement. The Chairs are going through and closing out action items and work items. Anything that has lingered for a while, we're going through to make sure things are getting the attention they need. If they find tasks or people, we'll do a matchup and get things moving along. ✪
Kim Hamilton Duffy: I'm not sure we have anything interesting to review this time. The one we have right here is actually not correct. I forgot to close one out. So, a good one to bring up: I wanted to call out this thing we discussed last week, which is the tracking of the Verifiable Credentials Maintenance Charter. We called this out last week. manu had sent out a proposed charter. We discussed it as a group. The Verifiable Credentials Working Group is done, but how ✪
Do we keep the VC Data Model up to date; the idea is we do that in the context of the CCG. Do we need to do anything at this point? ✪
Manu Sporny: Just getting consensus that the community is OK with the charter that is being proposed would be good. ✪
Manu Sporny: We could do it two ways. During the call, we could say "hey is everyone ok with the charter". If it looks good, send to mailing list for further discussion with 7 day time block on it, as feedback to the W3C management. I have not received any objections to the maintenance charter at this point. It didn't sound like there was anybody proposed. The CCG is the body that kind of figures out what has consensus. So I think we're done. To be truly done ✪
With it, I think we should get some feedback from the group on this call or the next call. ✪
Kim Hamilton Duffy: I'm thinking I like the idea of sending out the "Any Objections" call over email. I can send that out, so if we want to flip that around formally, we'll kick that process off now by sending this email to the mailing list. If you have questions, concerns take them to replies on the mailing list. ✪
Kim Hamilton Duffy: Do we need official owners of the group? ✪
Kim Hamilton Duffy: In general for work items we have an assignee. What do we call that? ✪
Manu Sporny: I'm imagining by default this will be the chairs of the working group. Dan, myself, anyone else who wants to be in the critical path. ✪
Kim Hamilton Duffy: Assigned to myself to send out call for objections. manu, you have the charter, so I can link to that. ✪
Manu Sporny: Do you want to kick that off on the call with a proposal to show support for the maintenance charter? ✪
Manu Sporny: I will find the link and we can do that later in the call ✪
Kim Hamilton Duffy: Let me check the agenda; that was the only issue before we move on, so if you want to send that ASAP we'll make sure to do that in a break before the end of the call ✪
Kim Hamilton Duffy: Now we're ready to move onto the main part of the agenda. Let me queue it up. Gabe from Workday sent a credential schema draft. I wanted to invite him to the group because there is some interesting discussion in there. ✪
Kim Hamilton Duffy: Let's go back to maintenance charter for a second. ✪
Manu Sporny: For those of you who weren't on the previous call where we discussed this, there is a proposal to renew the VC working group as the VC maintenance Working Group. The purpose is to maintain the specificaiton; make sure all IP processes are up to date, make sure bugfixes are released in a timely manner, and make sure work on the spec proceeds over the next 2yrs ✪
Manu Sporny: We did review this before; it has been circulated on the mailing list. We are just checking to see that nobody would object to the creation of that group. Particularly important because this group is responsible for checking consensus and getting support in this area ✪
Ted Thibodeau: Manu -- link to the source? (immediately noticed a typo in the mission -- `is maintain` should be `is to maintain`) ✪
Ted Thibodeau: Manu -- never mind, I see the link in the doc ✪
Dan Burnett: Just a reminder this is a maintenance working group; it is not intended for any substantial new work on the spec. Only bugfixes and whatnot. We are not permitted to expand the scope beyond the scope of the original working group. This in no way prevents us from rechartering the group to do substantive work in the future. ✪
Dan Burnett: Just wanted to make sure people knew this is intended for maintenance work ✪
Ted Thibodeau: Just a quick comment. Manu you said explicitly and carefully maintenance, but everything in this doc leaves out "maintenance" ✪
Manu Sporny: That is wording I deferred to Philippe. The very end of the doc says "This group is in maintenance mode". That might have special meaning to W3C Management, so I wanted to keep it intact. I think Philippe wanted to keep the option open that the group could be rechartered to do more than maintenance without trouble; i.e. without changing the name. I think it's clear in the mission that it is to maintain. ✪
Manu Sporny: Up to you TallTed if you want to suggest another clarifying intention sentence. ✪
Ted Thibodeau: I'm concerned with two different groups with the same name two years apart with different purposes ✪
Ted Thibodeau: The way we explained this is working groups typically just continue, but the understanding is that they are in maintenance mode only. But Philippe said that they preferred over time to have it be a bit clearer that it is in maintenance mode to adjust wording in the charter to say that. As manu described, he didn't want to go as far as changing the name of the group. If the name of the group was still Verifiable Claims working Group there would be no ✪
Change to the name. We're trying to follow what Philippe considers best practice today. ✪
Kim Hamilton Duffy: There may be some issues that TallTed just mentioned, but if you are ok with proposal type +1. You can type -1 if you are against it, and please write in your objection ✪
Kim Hamilton Duffy: We have Gabe Cohen from Workday. He's going to present their draft schema. Here is the link to the proposal that he sent out to the list. Just to queue up how that will happen, I will ask Gabe to walk us through the document. Now is your good chance to get an overview if you haven't read it. ✪
Kim Hamilton Duffy: Specifically we wanted to know if there are areas they wanted feedback from this community; for community, we wanted to discuss and have a QA session. ✪
Gabe Cohen: I'm here with a few of my coworkers at Workday. I presented at IIW a few weeks ago. These schemas are stored on our ledger, used on our platform, used for validating and giving the data shape to all our credentials. ✪
Gabe Cohen: I noticed a reference in the VC Data model the possibility of using a JSON schema for schema, but no examples. ✪
Gabe Cohen: We are in production and we have a need to issue credentials against schemas ✪
Is there accompanied any video to this presentation? Which I dont see now ✪
Gabe Cohen: We have a few pieces of data, and then the schema itself. The "pieces of data" are LD-like but not JSON-LD, just using JSON-schema ✪
Gabe Cohen: The model shows the fields in this version of the schema. The model 1.0 happens to reference a JSON-schema, but in future could reference an LD schema or both. ✪
Gabe Cohen: The next thing is the DID of the author. A next step is to reference a shared DID, but for now single. In future, there could be a github-like Pull Request model for collaboration. ✪
Gabe Cohen: Next is a version of the schema. The version changes when a new schema is released, but everything else stays the same (identifier may change?) ✪
Gabe Cohen: Next is authorship and timestamp of when the schema is authored. Next the schema itself, which is a draft-7 JSON-schema. We like the use of JSON-schema because we don't have to resolve additional documents about what a credential should look like. It also helps on issuance when we need to know what fields to fill out. ✪
Gabe Cohen: As a recommendation, we said that additionalProperties which is required by JSON-schema should be set to false always to promote consistencies between different issuing parties ✪
Gabe Cohen: The main theory driving use of JSON-schema is to allow things to be pretty flexible on the platform. ✪
Gabe Cohen: We could call out later on extensibility. We could potentially "tag" schemas for searchability in platforms; you could extend the model to do that. One thing I didn't mention is signing. Before we write the schema ... so there's no confusion about it being a linked data signature. I guess that's pretty much it. Colleagues, anything to add? ✪
Dave Longley: +1 To Kim, JSON schema is for validation, JSON-LD is for semantics, they serve different purposes ✪
Kim Hamilton Duffy: Clarification question, basic: One of the things that was surprising to me was seeing that this seemed to be a contrast between JSON-LD and JSON-schema. They serve different purposes; are for different things. JSON-schema is about required properties, where JSON-LD roots the document semantically. I'm curious to get some more backstory. Am I missing out on something that contrasts them? ✪
Kim Hamilton Duffy: I thought of JSON-schema as an additional optional later; curious about your thoughts on JSON-LD ✪
Gabe Cohen: We kind of wanted to "just" use JSON-schema, and go about agreeing on what a name is in a different manner by having the concept of "authoritative schemas" on our platform, and having the community agree there. It's lighter weight to have schemas the community agrees upon. ✪
Gabec coworker: nobody in our group had any familiarity with JSON-LD. We had familiarity and tooling support for JSON, so we leaned toward JSON-schema as a mechanism to define shape. As you use the same "shape" over time, you naturally get to a consistent vocabulary ✪
Gabec coworker: we wanted to have immutability of schemas. There's nothing that prohibits us from using LD in the future or providing a secondary layer of semantic meaning on top of schemas; it could be argued that consistent use of attribute keys in a schema can substitute and can build semantic consistency. ✪
Orie Steele: Thanks for presentation; I attended IIW. We at Transmute also use JSON-LD and JSON-schema together. Exciting, particularly, self-documenting JSON-schema. Similar to "snowplow". That's another technology to look at for those interested. My main question is ... inaudible.... credential format. ✪
Orie Steele: The object members secured by the schema members in many ways have terms overlapping with LD Signatures system. Which means that you are using a JSON LInked Data Signatures? If you are not, you should be much more clear about not doing that. Personally I would love to see support for LD SIgnatures + JSON-schema in one format. My proposal would be to add explicit support for JSON-ld to the spec itslef. ✪
Dave Longley: Note that JSON-LD 1.1 supports JSON literals -- can mark `schema` with that and it will sign with a JSON-LD signature ✪
Orie Steele: ... Inaudible... If that doesn't work, one of the things that is super confusing about LD, is people do half-implementations of it, and then it weakens the spec by muddying the waters. I'd want to use the spec with the implied assumption that it would use JSON-LD. ✪
Gabe Cohen: That's valuable feedback. We're happy to support Linked Data Signatures. We would appreciate some suggestions on how we could define another signature format that is clearly not linked data to avoid signatures ✪
Manu Sporny: I want to focus on some of the good things we agree on. Clearly the community needs a specification for how to specify credential schemas; hopefully doing it in a way that the entire community gets behind. This is a super solid start at doing that. The way the data is laid out, the fact that you're using LD Signatures; the fact that you are doing cryptographic hashing of schema/storing it ledger. These are all good capabilities we've talked about. ✪
Manu Sporny: If the group feels this is a solid place to start, is this a CCG work item, a DIF work item? How do we get together to collaborate on this? ✪
Markus Sabadello: ... Identifiers for locating schema on the ledgers. You're taking DID of the author of the schema, then creating a DID URL to identify the schema to locate. The way you do this is interesting... there may be other ways to do it,maybe by using path or query components of did URL as opposed to matrix ...inaudible. ✪
Markus Sabadello: Use of "method specific parameter" is not perfectly correct, just small detail; but fascinating that you're doing it with DID URLs ✪
Gabe Cohen: One of our architects pointed it out to me last night. I think this is a generic parameter ✪
Manu Sporny: You were saying you are looking for guidance on how to do the work. This seems to have community work item all over it. You're getting feedback that this looks awesome; it would be great if we could pull it in and incubate it. For example, VC working group could spin up out of maintenance mode to do something and moved through standardization process pretty quickly. Rough outline of this document is pretty good. ✪
Dave Longley: +1 It seems like a few minor tweaks could bring this inline with other techs/specs, the community could help with that. ✪
Manu Sporny: The stuff we need to hone in on is the details. Matrix parameter format maybe, use of LD maybe... some general terms that are used, like name of author. I don't see a lot of controversial stuff here, so we could probably move it through community fairly quickly. That's just a suggestion; I'm seeing a fairly clear path through. +1 to this being a CCG work item to put this on a (maybe)fast track to standards process. ✪
Manu Sporny: Other comments are about what Orie and kimhd said about proof formats, conflict resolution. There's a knowledge gap there that community could help fill. JSON-schema and JSON-LD were always designed to be complementary. It should be easy to mix in JSON-schema and JSON-LD and put them together. In our work in last 12 years we have combined these in customer projects... in a way that doesn't require LD processing ✪
Manu Sporny: We were very careful in how we designed Verifiable Credentials spec to not require JSON-LD processing. I see a way to use JSON-LD so it wouldn't impact you in a "now everybody has to know it" perspective. With plenty of upsides like being clear about semantics and shape of thing without being clear about it. ✪
Manu Sporny: You can still use framework of JSON-LD without added complexity of processors. Other thing about proof. If you use the ED___ verification thing, you're kind of asking for interoperability pain down the road. But you can define your own thing. If you want to create a WorkDaySIgnature2019 that didn't use JSON-LD at all, you can do that today with the specs. ✪
Manu Sporny: You've got multiple people in the community who would be happy to help with that. We've had 15 years of quite a bit of iteration and design work in background. ✪
Manu Sporny: A couple other things. Gabe, don't know if it was you or Joe or ... but a couple things said about semantics become clear over time. That's problematic. The whole reason JSON-LD came about is because semantics did not become clear over time, and we had a bunch of systems bumping into one another. Whether or not you buy into that, there are ways that reduce the chances of interoperability concerns over time. There is a lot of really great detail ✪
Stuff to talk about here; community has some good answers about how to generate interoperability over time. +1 from me. ✪
Orie Steele: +1 For community to adopt work item. ✪
Gabec coworkers: one question, I did see in VCDM spec it points to another vocabulary for linked data signatures. Not sure on status of proposal or document. Says clearly that the type of signature suite should be defined in that other document. You said we were free to develop our own signature suite. Certainly we can fit it in the data model, do we need to have a proposal for disambiguating. If we're not using linkeddata it seems inappropriate to submit ✪
Dan Burnett: A change in direction first... BTW this sounds good; lots interested. This might be a premature question; just want to make sure that you guys are comfortable that if this goes into community group and into standards track, if you would have any problems committing to a RF license for anybody who implemented and made use of this? ✪
Nate Otto: One example from past work of spec that has used JSON-LD + JSON Schema... Extensions mechanism for Open Badges 2.0 [scribe assist by Manu Sporny] ✪
Nate Otto is scribing.
Nate Otto: We do have a variety of vendors and data interop between them... developed own JSON-LD Context files and JSON Schemas... pass through standardized verification mechanism... it's possible to see that a badge has an extensions and get semantic anchoring, which then references JSON Schema and method for anchoring what part of the badge should be validated against the schema. [scribe assist by Manu Sporny] ✪
Nate Otto: Works pretty well, we have some extensions that Badr team that has done, others have also been successful at that before. [scribe assist by Manu Sporny] ✪
Anyone from Sovrin on this call? Doesn't Sovrin also have some way to define credentials on chain? ✪
Manu Sporny: I think gabe asked with respect to LD signatures, where do you define your own suite. Does it need to be in the LD security context or can it be elsewhere? This raises the general question of extensibility through registries and the type of extensibility through JSON-LD. With JSON-LD you do it in a decentralized manner; the registries are optional. The CCG maintains them, but it's completely optional, because the fundamental LD technology allows you ✪
Manu Sporny: If you wanted to, you could extend in a way that is a bunch of proprietary workday extensions; if you wanted to produce your own signature mechanism, key format, etc, you could do that without interacting with this community. If you want to do it in a way that will not lead to interop conflicts in the future, all you need to do is specify one context, the workday context and put all your terms in there. Then you don't have any conflicts and you can ✪
Manu Sporny: It may get to the point where other people find it useful and can pick it up. With decentralized extensibility, nobody has to ask permission to do their own thing; but if their own thing becomes useful to the community, we don't have to do anything in the future if you do it with LD. Whereas without you have to spin up a working group to standardize it. ✪
Manu Sporny: Summary: 1 option: do your own thing, don't worry about interop. 2 option: super lightweight, just define your own JSON-LD context, make it a URL and put it there at the top of your documents; then Workday is not prevented by anyone in the community, but you're guaranteed good interop in the future. Option 3: Go all the way and implement JSON-LD deeply and be more fully aligned with the ecosystem; your tools may be more deeply pulled into the ✪
Community. There are three enhancements. Hopefully that answers where does it go question. ✪
Kim Hamilton Duffy: Thanks for presenting. Gabe on queue ✪
Gabe Cohen: We would love to be able to open source all of this; working with legal to do that. ✪