Harrison_Tang: Right so uh today we have a great session that I've been looking forward to for a month uh we're going to talk about verifiable credentials data model version 2 and we got Brent and Manu here to actually talk about what's new. ✪
Harrison_Tang: Before we uh go there just want to quickly go through some administrative stuff uh so first of all just a quick reminder on the code of ethics and professional conduct just want to make sure that uh know we made a we make a respectful comments and acknowledge each other's perspectives. ✪
Harrison_Tang: Also sends the contributions to adcg work guidance must be member of the ccg with 4 IP agreement signs so if you have any questions uh in regards to that or the w3c account just uh feel free to uh email or contact any of the cultures. ✪
Harrison_Tang: A quick call note uh all the meeting minutes and uh I uh and the meeting itself is being automatically recorded and the minutes are automatically transcribed we use GT chat to Q speakers during the call you can type in Q Plus to add yourself to the queue or cue minus to remove and you can do Q Plus to see who's in the queue. ✪
Harrison_Tang: Uh these uh transcriptions and recordings and actually uh things to uh monument and many others uh you know you you can actually see the video recordings as well and we try to publish it within the next uh 24 hours. ✪
Harrison_Tang: Right uh a quick moment for the introductions and reintroductions if you're new to the community or you haven't been active. ✪
Harrison_Tang: And then the Tuesday after that uh we uh got actually the CEO of I proof to talk about biometric authentication and lightness detection so this topic uh we talked about adding a little bit different topics other than just uh uh you know the verifiable credentials and those kind of topics and this is 1 of the uh tangential identity topics that we bring on. ✪
Harrison_Tang: All right uh last calls for introductions reintroductions announcements or work items. ✪
Harrison_Tang: Cool so uh let's get to the main agenda uh again uh this is. ✪
Harrison_Tang: 1 of The Sessions I've been looking forward to for a long time and then we're very glad to have Brandt and Manu here to talk about what's new with the verifiable credential data model version 2. ✪
Brent Zundel: I'm jumping right into Charter um our Charter was pretty straight forward we wanted to address any Errata or bugs that showed up um or were reported from previous versions of the of the data model. ✪
Brent Zundel: Uh we wanted to continue developing that data model and um add whatever new properties uh or change whatever properties were necessary to change. ✪
Brent Zundel: Um managed or adjust or create any Registries that could uh support the data model. ✪
Brent Zundel: Um and our primary task for this round was algorithms for the expression and verification of proofs this was how do you you know secure a verifiable credential such that it can actually be verifiable. ✪
Brent Zundel: Um as well as we wanted to to tweak the multilingual support so this was what our Charter said this was uh I think directly quoted from the charter text. ✪
Brent Zundel: And what this really meant was okay we need to fix the bugs we need to update the data model. ✪
Brent Zundel: Uh we needed to answer the question do we want. ✪
Brent Zundel: A registry do we need a registry should we have a registry. ✪
Brent Zundel: And the bulk of the work went into defining securing mechanisms. ✪
Brent Zundel: What also came out of this was a recognition that earlier versions of the data model defined um a pretty healthy number of extension points and these were properties defined in the data model um and defined in a very minimal way so that. ✪
Brent Zundel: Implementers could have a point by which they could you know extend out and do any number of things. ✪
Brent Zundel: Extension points where everything from you know evidence or terms of use or or things of that nature um and some of the feedback that we got was while the extension points were uh excellent and convenient they also led to challenges in constructing interoperable implementations because implementers weren't sure if the manner in which they implemented the extension point would match the way someone else had. ✪
Brent Zundel: Because the extension points were not as uh normatively defined as uh as some folks wanted. ✪
Brent Zundel: So this was the body of work that we had before us. ✪
Brent Zundel: We've done a lot we've we've done a lot um here's some stats um more than 250 issues have been processed uh resulting in more than 260 changes to the spec. ✪
Brent Zundel: Who are registered as participants in the working group with 118 people representing those organizations. ✪
Brent Zundel: Um and this is on top of or you know you know Venn diagram overlap slightly of the 560 people in the credentials community group it's just a large community. ✪
Brent Zundel: Is that the previous versions of the data model tried to. ✪
Brent Zundel: Talk of fine line between is it Json is it Json LD well it could be both it could be neither it could be 1 um we were maybe a little too koi in the past or trying to. ✪
Brent Zundel: Maybe it was a little too clear to us what we were doing and not as clear to other folks but um the very clear feedback that we got from implementers was. ✪
Brent Zundel: Because if we're using um Json signing mechanisms we can use Json LD um if we want to use the full expressiveness of Json LD and all of the power that is uh enabled there then some of the halfway steps that we had taken actually kind of inhibited some of that desire and so the big change is that this is a Json LD data model. ✪
Brent Zundel: You don't need a Json LD library to process verifiable credentials um the processing can be hard-coded it can be um you know done you can do Json only processing of Json LD because that's what you can do with Json LD. ✪
Brent Zundel: We allow this type based credential processing we allow um. ✪
Brent Zundel: Folks essentially to do what they were doing before but the the description of how to do that in the in the data model in our opinion is much clearer um and hopefully avoids uh and will avoid some of that confusion. ✪
Brent Zundel: Um so this was number 1 big change it is 100% Json LD. ✪
Brent Zundel: Additionally we were like okay this registry should we have 1 um rather than constructing a formal w3c registry the verifiable credentials working group elected to publish a note. ✪
Brent Zundel: Of verifiable credential specifications. ✪
Brent Zundel: This was to uh try to better adhere to. ✪
Brent Zundel: You know some of the desired decentralized characteristics of verifiable credentials. ✪
Brent Zundel: Um what we've ended up with with the VC specs directory is there's a list of specifications that you can use for different extension points or different credential types have been defined and are listed in this in the directory um. ✪
Brent Zundel: Securing method mechanisms particularly those that the working group has developed are listed in the in the specifications directory. ✪
Brent Zundel: Verifiable credentials media types being the you know Ayanna registered. ✪
Brent Zundel: Um so we don't have a registry we have. ✪
Brent Zundel: Registry light it's um it's a place where pretty much anyone can say hey this is a thing I'm working on here's where you can learn more about it here's the specification we're developing and all of that and if that sounds like a registry to you that's okay. ✪
Brent Zundel: The bulk of the work as I said before was developing securing specifications um the. ✪
Brent Zundel: Biggest and most uh painfully accurate feedback from earlier versions of the data model was. ✪
Brent Zundel: What exactly does proof mean how do how exactly do I use that um. ✪
Brent Zundel: And so we've defined a couple um the 2 families are uh data Integrity which takes uh uh more distinctly rdf and Json LD flavor uh to the approach and the uh securing verify credentials with Jose and coase approach which. ✪
Brent Zundel: I umbrella spec is verifiable credentials data Integrity 1.0 and that's a spec that tells you how to write a verifiable credentials data Integrity spec um of which we have 3 that are in development data Integrity eddsa uh data integrity ecdsa and what I am calling data Integrity BBS because that matches the other ones even though technically this 1 is called like BBS signatures 2023 right now but I'm hoping we can get that name changed. ✪
Brent Zundel: Took most of the the group's time. ✪
Brent Zundel: To get these things uh together and get them. ✪
<manu_sporny> yes, we need to get that name changed :)
Brent Zundel: To the point where we're thinking we're pretty close to done. ✪
Brent Zundel: Uh additionally we have Manu who'd like to speak I'd love. ✪
Manu Sporny: Jew just on the on the previous slide um I I I think it's important to point out that we're trying really hard to achieve. ✪
Manu Sporny: A number of the Privacy goals that we've always had in this community so like um ecdsa is there because like governments like issuing doing digital signatures using ecdsa and there's like a clear path there from a. ✪
Manu Sporny: Um uh uh approval Hardware security module support perspective so that's why we're doing ecdsa is to is to kind of ensure that we can bring the the uh most widely recognized digital signature format into the verifiable credential space eddsa is kind of like the newer way of doing elliptic curve signatures um it's simpler easier to implement um and you know people people use it and then finally BBS is this you know unlink uh signature scheme meaning that um it has certain like privacy characteristics that are desirable um you know people call it on linkability but it's this idea that every time you show your credential to someone the digital signature changes in a way that's still verifiable but like you can't be tracked using the digital signature which can happen with ecds and eddsa um we also. ✪
Manu Sporny: Have like selective disclosure and the. ✪
Manu Sporny: Whose goal is to is to provide unlink signatures as well so all that to say that you know we we have spent a lot of time. ✪
Manu Sporny: This in this round trying to create the technological and cryptographic underpinnings that are going to achieve a number of like the Privacy uh protections um uh that you know we've we've wanted for like Beyond a decade at at this point um. ✪
Brent Zundel: Thank you mono that the strikes true for me as well we've. ✪
Brent Zundel: Much the beginning with verifiable credentials we have tried to produce something that um enables but doesn't necessarily require um some of the deep privacy enabling Technologies um and with the securing specifications that we're defining we've just gotten more concrete with that. ✪
Brent Zundel: Um so pretty excited about some of this stuff. ✪
Brent Zundel: The other bit that we've worked on is uh like I said we have a lot of extension or had a lot of extension points. ✪
Brent Zundel: The ones that we've been able to more formally Define uh our credential status and we have a bit strength status list specification that allows you to or allows implementers to interoperate use this that credential status extension point. ✪
Brent Zundel: Normally than the data model did um we now have verifiable credentials Json schema specification that provides an interoperable means of doing that. ✪
Brent Zundel: We also have found and these are now listed in the verifiable credential specifications directory there's uh. ✪
Brent Zundel: Specifications being developed and used for evidence for terms of use and for the refreshed service. ✪
Brent Zundel: Some of the other extension points we weren't able to find as much and you'll see refresh services on both these lists um. ✪
Brent Zundel: Because the disposition of these extension points is still a little unsure um confidence method render method are are much more in that experimental vein and so what's likely to happen with these extension points in the core data model is they're going to be listed as reserved properties. ✪
Brent Zundel: And say you know if you want to build a render method please consider using the render method property. ✪
Brent Zundel: You know it should have a type and an ID like all the other properties but we're not going to formally Define how it ought to be done and it's not officially a part of the specification. ✪
Manu Sporny: Yeah uh yeah plus 1 to that I thought it might be helpful to kind of point out also kind of what the expectation is around these um so as as Brent was saying like the the reason the VC specifications directory exists is to. ✪
Manu Sporny: You know have 1 place for people to go to kind of understand what's out there but not it doesn't have to be the only place um and so we're looking to the community. ✪
Manu Sporny: To use these extension points um in in experiment with them and and deploy things using them right so the the goal here is that like the verifiable credentials working group can set some of the core um uh stuff here but we do expect Innovation to happen um outside of the working group on on each of these you know extension points so for example like confidence method um uh is is being contemplated as a way that you can gain confidence in the individual that is presenting a credential like confidence method could have you know a key uh sorry it's an entry in it that says um if somebody's presenting this credential to you um you can gain confidence that it's the same person that it was issued to the credential was issued to by checking. ✪
Manu Sporny: Hardware security module like for example it is bound to a person's phone and if they're able to prove. ✪
Manu Sporny: You know control over this key using this confidence method then you have a pretty high assurance that the individual um is the same 1 that the that the credential is issued to so like that's what confidence method is is meant to do people are also looking at confidence method as like you know could we use biometric templates there like that's scary but at the same time some you know things like border crossings require that um so confidence method you know could could hold properties like that um. ✪
Manu Sporny: It's a you know access to a biometric templating service where we don't actually provide a biometric template or anything like that in the confidence method but it's like a pointer to a service that somebody could use with the consent of the individual uh to to do that kind of biometric checking again like that's being done experimentally because it's a that's a kind of a scary thing to work on depending on you know where you are. ✪
Manu Sporny: Verifiable credential looks like um meaning like some of them still want it to look like the piece of paper right the the people still want a driver's license to be rendered like the physical driver's license people still want you know an education a degree uh issued by a university to at least have like some kind of renderable form um and the render method could be anything from like PDF to SVG to you know PNG image um and you know work continues there like we're not going to we're clearly not going to be able to Define how that works in this iteration of the working group which is why that's you know a ccg work item uh currently um anyway back over to you Brian I thought it might be this is some of these might have been new new new to folks that hadn't been tracking. ✪
Harrison_Tang: By the way Kim is also on the Queue so Kim do you. ✪
Geun-Hyung Kim: Actually I teed up Demetri I wanted to put Demetri on the hook because he he mentioned render method I know edu use cases very keen to have uh some kind of more first class of it so um Demetri if you can I I would be special eager to hear if like you were able to use that specifically and how you're using it. ✪
Dmitri Zagidulin: Thanks Kim I commented on it in chat because I'm a big fan and and we are uh using it at uh digital credentials Consortium and uh it sounds like um Arizona State University is also interested uh in using it as well as a couple of others specifically. ✪
Dmitri Zagidulin: To answer the very commonly asked use case of okay I've got to verify the credential how do I print it out how do I turn it into a PDF either for online use or to hand it to a person who is not prepared to consume verifiable credentials digitally that sort of thing. ✪
Dmitri Zagidulin: And so that's 1 of the driving forces that's 1 of the uh major use cases behind render method as well as there's a couple of others so and and what were specifically exploring is the use of an HTML and CSS template that is either linked to from the VC or embedded in the DC. ✪
Brent Zundel: Thank you Kim thank you Dmitri um so just to. ✪
Brent Zundel: The balance that the VC working group tried to strike in the data model with these extension points was uh to not just allow but encourage experimentation and use um that I would say the primary reason for constructing the verifiable credential specifications directory was to give a place for folks to. ✪
Brent Zundel: To highlight the things that they're working on and how they fit with the rest of the data model so that other implementers can come along and and make use of those things we wanted to encourage that while at the same time having kind of you know the rigorously defined normative standard that is the expectation of something that comes out of the w3c. ✪
Brent Zundel: And so I I think we've caught that balance pretty well um. ✪
Brent Zundel: Speaking of not done yet what are the next steps where are we at so. ✪
Brent Zundel: This is the list of normative specifications that are currently in process from the verifiable credentials working group. ✪
Brent Zundel: Hopefully those of you who have been involved with w3c standards and work groups before are looking at this list and going holy crap that's a lot of specifications. ✪
Brent Zundel: Yes most working groups in the course of their 2-year span I would say. ✪
<manu_sporny> haha, yes, that is A LOT of specifications.
Brent Zundel: 2 Or 3 is like the you know that's that's where they go with it that's how the what they try to accomplish this work uh working group has accomplished so much they have worked so hard and gotten so much done um it's just truly been impressive and so I'm going to run down these 1 at a time and let you know the status of them uh verifiable credentials data model. ✪
Brent Zundel: Uh what candidate recommendation means is the working group we think we're done we think that we have defined it such that it is implementable we are actively looking for implementation feedback. ✪
<manu_sporny> Also, we got so much done because of the excellent leadership of Brent (and Kristina) as Chairs throughout the process!
Brent Zundel: The expectation with the data model is that after we get this feedback we will make some adjustments and modifications and we will re-enter candidate recommendation we'll go through this Phase 1 more time um with the refinements that came through after the first phase. ✪
Brent Zundel: And it hoped for timeline is that that transition to uh Canada recommendation part 2 will happen sometime in May. ✪
Brent Zundel: Um verifiable credentials data Integrity along with ecdsa and eddsa are in a similar place I would say that the likelihood of implementation feedback that results in candidate recommendation uh Phase 2 for these is is probably not as. ✪
Brent Zundel: Like the number of changes that need to be made is probably not as large but there still will be some and so we expect those to go into a second candidate recommendation phase uh about the same time as the core data model. ✪
Brent Zundel: Viable credentials data Integrity BBS is still a working group draft. ✪
Brent Zundel: Um that means we are still working on it it is approaching uh entry into candidate recommendation uh we expect work on that to wrap up what in the next. ✪
Brent Zundel: Securing verifiable credentials using Jose and cos I would say is in a similar position as BBS um we are. ✪
Brent Zundel: Working toward addressing the last set of open issues there and will introduce that specification as a candidate recommendation within the next couple of months. ✪
Brent Zundel: Uh again is in a similar space as the BBS and um. ✪
Brent Zundel: Securing using Jose and Jose if not even a little further along um that 1 has been uh ready for candidate recommendation for a time we just had to do 1 more round of horizontal review with it um and once we address the feedback obtained during that horizontal review that uh specification will also go into candidate recommendation. ✪
Manu Sporny: Yeah plus 1 all that um the so implementations also like you know when 1 of the reasons we go into candidate recommendation is to basically tell implementers like hey this is ready for implementation like experimental implementation tell us how it goes tell us to change anything if it was a pain or if you found a bug or or whatever um and I think for the vast majority of these specifications we already have 2 or more implementers implementing which is which is good like that that you know that's where we we should be there are test Suites for most of these specifications um uh as well but you know we're getting to the point where those test Suites need to be just done done so that implementers can can move forward with like absolute certainty that they're going to be you know passing um all the test Suite so so we do have test Suites we have. ✪
Manu Sporny: Uh but now we're getting to the point where we like really have to wrap up the the test Suites and wrap up the implementations but I think we have high confidence that VC data model 2o is not going to have any problems from you know implementers same thing for many of the data Integrity Suites including the selective disclosure in the BBS ones although those will have you know far less implementers than the BC data model 201 um vcos cozy has multiple implementers bit string status list has multiple implementers I don't know where we are on Json schema um but it's not a difficult thing to implement um and so you know all that to say that you know the specs getting the specs done is very important but so is you know getting the test Suite done and the implementers integrated into the test Suites so that we can prove to the w3c membership that yes people implemented the specification and they did Implement you know. ✪
Brent Zundel: Is that for every normative statement in each of these specifications there must be uh tested proof that at least to implementers have implemented the feature. ✪
Brent Zundel: Interact with the test suite and that will produce a report for each of the normative features. ✪
Brent Zundel: Get that level of support unfortunately then we'd need to we would need to pull it out of the specification good morning. ✪
Manu Sporny: Yeah absolutely um and just so people you know uh kind of know where we are from from an implementation standpoint we have 11 implementation so like way more than 2 for like at things like core data model and and stuff like that um we know that there are probably upwards of 17 to 18 Implement that could integrate with the test Suite if they wanted to and we're currently working with them I know Benjamin that's on the call today is is working with a lot of implementers to try to get them integrated into the test Suite so we are we are very um uh uh lucky to have this many implementers you know at this stage like when you look at browser specs like you're lucky to get 2 because they're you know they're only like really 3 browsers on the planet that are that are left whereas the work that we're doing here you know has much broader um ability to implement this the specification so we're. ✪
Manu Sporny: Certain features it's a pretty strong sign that like people didn't Fe you know find the feature useful it could also be a sign that the feature was too complicated to implement um so so all that to say like I think we feel pretty good about the number of implementers that we have we just need to kind of heard all of them through the end of the process which is which is the always challenging. ✪
Brent Zundel: Um additionally to the normative specifications uh we have a couple of notes the verify the credential use cases Note which already was pretty darn fantastic. ✪
Brent Zundel: Uh pretty thorough overview and revision uh thanks to the editors of that and the aforementioned verifiable credential specifications directory um it's possible that the working group will. ✪
Brent Zundel: Publish the verifiable credential implementation guide um but it is unclear at this point so it's not officially listed here. ✪
Brent Zundel: Um and this is where I'm happy to take any questions any further conversation wherever folks want to take it um that that was the presentation hopefully it was helpful um and. ✪
Harrison_Tang: Any questions if you have any questions just type in Q Plus to add yourself to the queue. ✪
Harrison_Tang: I I have a 1 quick question um just on the high level like what do you foresee the version 3 will cover because earlier you guys mentioned that uh for example the proof part right the crypto Suite uh version 2 uh basically solve the problem then what are the high level problems that still needs to be solved. ✪
Brent Zundel: I'm pausing because there's a portion of my brain that has been actively shut down to prevent it from thinking too hard about the what version 3 could look like because it uh doesn't want to go there just yet um. ✪
Brent Zundel: I think version 3 is likely to you know add greater Clarity to the extension points um. ✪
Brent Zundel: The cheater answer is it depends um you know we got to version 2 because we had enough implementation feedback in enough industry experience to say here's where the major gaps are. ✪
Brent Zundel: We can see maybe where some of those gaps could be. ✪
Brent Zundel: Is the uh the short answer I'm hopefully Manu has a little better of an answer. ✪
Manu Sporny: Not not much not much better um if if folks don't mind me jumping here to to try and respond Demetri Phil Kim is that okay. ✪
<kim_duffy> sure!
<kim_duffy> but first Brent needs to go to Disney World
Manu Sporny: Okay um so uh yes what what Brent said so almost certainly usually when you do a major version the working group the next Charter will switch into maintenance mode and that will be the point release so we'll release version 20 and then in version you know 1 0 of the other specs and then we will be put in a maintenance mode which says we're working on version 1 1 of the specification which usually doesn't allow us to work on any new features it's just there as like if we find a bug we fix it if there's some kind of horrible issue with the specification there's an active working group to to fix it so maintenance mode for version 2.1 and 1.1 for the other specs is usually where this goes um. ✪
Manu Sporny: And then we We Gather feedback you know there's a quiet period where people go out and they Implement and they put it into the world and then they come back and they're like hey this isn't working well or we're missing this feature and we kind of gather those up for the version 30. ✪
Manu Sporny: Uh work um the version 3 0 work I would expect like things extensions like render method refresh service evidence things like that if we get more of those types of like Community incubated specifications or things deployed into the ecosystem um those would be good candidates any anything being incubated in you know ccg or diff or ITF or well not it like wherever like you know this incubation can happen wherever and as long as we have enough people that want to see 1 of those extension points more formally uh standardized that could be in a version 30 um uh uh a place the there is a question around like what do the protocols and query languages and higher level things look like so you know a a diff as incubated some work in this space and presentation Exchange. ✪
Manu Sporny: Uh the digital credentials or identity credentials API so browser vendors are actively working on you know what this looks like in a in a browser setting um uh and then there are things like you know VC API and verifiable presentation request and and that sort of thing so the the protocols are still. ✪
Manu Sporny: Kind of mushy right now and I think people are trying to get some deployment experience before we really you know commit strongly to to to 1 or the other but there could be a future here where um maybe it's not you know on the browser portion of it or the front end you know delivery portion of it but maybe like you know VC API focuses very much on kind of the back-end um uh like back office open apis for issuing verifying um uh storing um managing status lists uh from an issue or perspective and and that sort of thing so those are in the ballpark of things that could go into. ✪
Manu Sporny: You know a next working group but I would imagine there would be some kind of mandated quiet time for a point release before we we get there. ✪
Manu Sporny: Hopefully hopefully that was that was helpful and and not too too controversial. ✪
Dmitri Zagidulin: Yeah I wanted to ask uh a question that you may or may not be uh commonly asked in the coming days which is from the groups that implemented VC data model 1.1 What specifically is changed what breaks what do we need to uh what what are the concrete steps we need to do we just had this discussion at the open badges version 3 group in 1 Ed Tech uh because they they just find finalized the spec for vcd 1.1 but now 2.0 is coming on the horizon and they had to ask. ✪
Dmitri Zagidulin: So what are we doing uh so I'd love to hear your thoughts on it uh and happy to share the list that uh the 1 Ed tech crew came up with but first of. ✪
Brent Zundel: Sharing that list would be fantastic um we. ✪
Brent Zundel: The working group attempted to um. ✪
Brent Zundel: B as conservative as possible with changes. ✪
Brent Zundel: The way that you know fundamental to the nature of verifiable credential is that it needs to be verifiable and so the fact that there are now um coming out securing specifications that say you know oh you want to use Jose to secure a VC this is how you do it oh you want to use uh a date Integrity signature to secure VC this is how you do it and that um will likely impact implementations um some of the groups that I'm involved with are you know specifically looking to use version 2 over previous versions be mostly because of the new features um. ✪
Brent Zundel: Uh specifically like there's content Integrity stuff in this version that wasn't in in previous versions that allows uh for you know integrity. ✪
Brent Zundel: Verifiable Integrity links to other things um. ✪
Brent Zundel: So I I don't know specifically of things that are definitely going to be broken it's likely that there are some we did our best to minimize those as much as possible. ✪
Manu Sporny: Yeah plus 1 to that um the uh the own so yeah as as Brent said we were really careful to try not break uh existing implementation so if if someone has stood up of of VC 1.1 or VC 1.0 infrastructure and they're issuing credentials and all that kind of stuff they can continue to do that that like you know as long as the verifier accepts those those credentials which there are a number of verifiers that do. ✪
Manu Sporny: Continues to work just fine so upgrading to 200 is an optional thing if they do upgraded 20 I think the only breaking changes were that we renamed. ✪
Manu Sporny: That that is it that's the only breaking change we made um and frankly like and that doesn't break existing implementations in the space because when a v2o credential is issued and used you will use a v2o context um declaration at at the top and so you know it's it's so we we also went to the you know the the extent of making sure that a v2o presentation could include a v11 credential like that works just fine as well um. ✪
Manu Sporny: Expect a large number of issuers sorry of of people in the ecosystem to upgrade to 20 because it's got a ton of new features that you know are useful um Brent mentioned the like uh content Integrity links the resource Integrity links like that was a huge thing that people asked for and that's in there now um uh the other thing is we now allow uh enable um you to encapsulate uh other type of envelope credentials in there so in theory well not in theory in in reality you could um include uh credential types that have their own media type that are totally different from verifiable credentials you could include an MDOC if you wanted you could include an ACDC uh uh uh uh protected credential you could include a um gordian uh uh uh credential that is now. ✪
Manu Sporny: Uh now we don't know what that ecosystem quite looks like but it's you know it's it's possible um so so the you know I I think the good news here Demetri is like we tried to make sure that an upgrade to 20 would result in very minimal changes and I think we were successful in doing that um but the real you know reason to upgrade is like you've got a number of interesting new features that um you know people have have asked for. ✪
Harrison_Tang: Right Kim you're next on the queue. ✪
Geun-Hyung Kim: Oh okay um thanks you guys this is a great presentation and uh Brent Manning to take a vacation this is amazing work um I have sort of more a counterfactual question because you know so as a notice VC that contributor a bit more of a VC hype man over the years I've developed my own mental model about like what it would be if we had infinite time and I think from the start and there was some talk for a while that. ✪
<dmitri_zagidulin> I think the WG did a great job, in terms of upgrade path! That's what we found too - 1) change in @context, 2) change in the two date fields. And that's about it.
Geun-Hyung Kim: You know we wanted to develop a pure data model and then have these different um you know formats mentioned but then as you were talking about the design decision which Json LD I realized like that you know a lot of the goals what you're trying to do you you can't do it if it's a pure abstract data model like you have to sort of say we're picking the art you know we want these rdf graph features and what so we got to go that path um so I was first of all like um what you're thinking well 1 but it's specialized Json LD but I was assuming that it could still work you know you could serialize a core LD things like that but then also you know kind of like if we could start over what it would. ✪
Geun-Hyung Kim: To the V the VC data model 2.0 to fit in the overall ecosystem you know given that there are multiple formats emerging is it just something that we're going to have to expect issuers to um you know support multiple formats you know how do we get alignment and so this runs a foul of my advice to not think about this stuff but I am curious about like the overall context and where we go next in that regard. ✪
<phil_(t3)> In that overall context, what of IETF's work in this space re: VCs...
Manu Sporny: Thanks Brent um uh yeah that's an excellent question Kim I mean you know I think 1 of the things that we asked ourselves regularly in the working group is like was there another path that we could have taken um so you know let's let's talk about like all the elephants in the in the in the room right so we definitely have multiple digital credential formats that exists today uh we've got you know the um the the non-red stuff both V1 and V2 we have w3c verifiable credentials we have uh mdl we have MDOC um we have the new SD jot VC stuff which even though it says VC it's not actually W3 CVC it's something else um these credential formats exist in the world in a number of them are not going away we're not getting back down to 1 again like I I just don't see that happening so I think short term um I know. ✪
Manu Sporny: Will support any digital credential format that the customer wants us to support even if we think it's a really bad format because we are for for-profit company and we like to get paid and that is the way to keep the customer happy is to do what they they want We'll advise them that hey you know it's going to cost more money the more of these things we have to support and the more variation there is but the fact that these things exist in the world today you know it's it's the messy reality is that we have to support more than 1 credential format I think anyone that is running a. ✪
Manu Sporny: A nonprofit or for-profit Enterprise that is the reality on the ground today um could we have done something in version 1 oh that would have prevented this where we are right now. ✪
Manu Sporny: I don't think so because I think the natural. ✪
Manu Sporny: Any Market vertical is to have options in the space right I mean like cars have been around for more than a hundred years now we are not down to 1 kind of car brand or even 2 we have you know it tends to to 50 plus different car brands each manufacturer does things in a slightly different way we have electric cars gas cars hydrogen cars you know all that kind of stuff and I think the same. ✪
Manu Sporny: Uh you know our our industry um so you know what if we pick Jason instead of Json LD when we started uh or what if we you know it so so I think I think what we I think what we. ✪
<dmitri_zagidulin> very incosiderate, of the car manufacturers! THINK OF the savings and the efficiencies we'd have. (with just one car model)
Manu Sporny: Well what we have right now is like all the variations not not every single 1 but I think it's important for each you know Community that's working on these variations to make sure that the thing that they're creating is internally consistent um so that it's easier to implement um uh I don't know if that answered all of your questions Kim but that's kind of. ✪
Manu Sporny: My current thinking would love to hear other people's you know thinking um in the space. ✪
Brent Zundel: I I'd like to chime in just a little bit maybe abused your uh car analogy further than you than you'd like but um you know they're looking at the different use cases. ✪
Brent Zundel: Um there's a different intended use and a a lot of the different variations that we're seeing I think are an answer somewhat to that um. ✪
Brent Zundel: There's also different um 1 1 of the limitations that has been placed on and accepted by the verifiable credentials working group is that we don't talk protocols. ✪
Brent Zundel: Um and there are a host of existing protocols that verify the credentials kind of but maybe don't quite totally fit inside um and so some variations are a verifiable credential flavored thing that is you know designed to fit on this existing set of rails it's like oh that car thing is great but I have these train tracks over here so how do I create this thing that has some of those car-like elements but can run on these existing these existing rails and um I think some of the variation that we're seeing is is due to those effects um all in all what we've created with the verifiable credentials in the verifiable credentials working group is not only a set of specifications that in my opinion can excellently prepare almost any uh issuer and verifier to receive and exchange uh credentials about any. ✪
Brent Zundel: Existing uses that that folks want to put them to that that are slightly different so in addition to this wonderful set of specifications what we have produced as a working group is um a really compelling conceptual notion of this credential this vehicle that encompasses. ✪
Geun-Hyung Kim: +1 Manu/Brent, and it could be a useful role of W3C CCG and DIF to help promote convergence and/or clarity. But I also like the more practical suggestion of new specs at minimum making it internally consistent / implementable ✪
Brent Zundel: Qualities of personal control privacy um and a much more user Centric view of the world. ✪
Brent Zundel: And um seeing that view of the world propagate even among all of these different communities that when the verifiable credentials working group first started and even now a number of them turn and they scoff and they you know hold their noses or whatever um they're still. ✪
Manu Sporny: +1 To what you said, Kim -- yes, agree -- always worth it to try to converge. ✪
Brent Zundel: Are not only great but potentially inevitable in some uh. ✪
Brent Zundel: That's kind of a big rambly way to say the the ecosystem is healthy where exactly verifiable credentials will fit within that ecosystem is you know yet to be seen um you know I think we've created a pretty fantastic set of specifications um and I'm sure that. ✪
Brent Zundel: Not directly built upon they will they have at least you know distinctly influenced the direction of things for a long time to come. ✪
Geun-Hyung Kim: Actually I do want to jump to say that is absolutely true the idea that it's influenced all these other specs in introduced you know where maybe it would not have existed like say the idea of minimizing phone homes and things like that um so yes definitely huge accomplishment and take take some time off. ✪
Harrison_Tang: All right any last question or comments Phil do you have more questions or comments I saw some comments on the chat. ✪
<phil_(t3)> Nope but thanks for asking
<manu_sporny> haha
Harrison_Tang: Right well thank you thanks uh Brent thanks man you for spending time and jumping on to explain the VC 2.0 by the way I just want to make a quick comment in regards to the car analogy I actually really like it I recently heard the same car versus truck analogy uh to uh for like a specialized large language models and that guy got a lot of VC funding so apparently they are now actually works quite well so you're not using it. ✪
Harrison_Tang: Anyway um thank you this is a great discussion and this concludes this week's W3 ccg meeting thanks a lot. ✪