Manu Sporny: All right welcome everyone this is the verifiable credentials API call this is June 21st 2022 our agenda is here on the agenda today is options options options so option processing for all the VC API endpoints. ✪
Manu Sporny: Give talking about options by the end of the call but that's basically it for the agenda today we've got a couple of other kind of questions around who's implementing what endpoints yeah that's it that's it for the the agenda will also do you know introductions relevant Community updates and start out with that we have a couple of those things going on any other updates or changes to the agenda anything else folks would like to discuss today. ✪
Manu Sporny: Okay and in Eric I'll note the will want to talk about the status of the use cases and what the next step is there after we do introductions and Community updates all right so let's go ahead and jump into introductions. ✪
Topic: Introductions and Relevant Community Updates
Manu Sporny: All right any updates just Community updates in general I've got one and that is that the very first verifiable credentials 20 working group meeting is happening next week so first we see to delete G meeting is next week the Brent sundel one of the. ✪
Manu Sporny: Um it is 11 a.m. eastern which I guess puts it around 4 p.m. or 5 p.m. based on depending on where you are in Europe if you have not rejoined please do so you need to rejoin the group to recommit to the IPR agreement they will be posting an agenda later on this week so just as a heads up. ✪
Manu Sporny: Here's our Brinson Del who has been who co-chaired the VC part of the VC actually did he do vc10 I think he did part of it right he definitely was a co-chair of the did working group Brent's great and then we have Christina yasuda from Microsoft I think this is I don't know if this is her first time sharing w3c group or not but she's excuse me also done quite a bit of work on it. ✪
Manu Sporny: That sort of thing that Microsoft so and then of on Herman's going to be our our staff contact along with pierre-antoine who are both you know really really wonderful people as well so both so we're in very good hands is what I'm trying to say and and it will be exciting to see see everyone you know again new faces and old faces any questions are. ✪
Manu Sporny: All right any any other announcements relevant Community updates anything of that nature. ✪
Manu Sporny: Dimitri of got a question for you to any anything public about kind of where what jff for vcd use going to do next. ✪
Dmitri Zagidulin: Yes now so this is still subject to change but I believe the current plans are to do the next Jeff of plugfest the successor to the first one that will involve most likely issue API the day before the Autumn iiw at the computer science museum History Museum. ✪
Dmitri Zagidulin: Right right everybody brush up on your apis yes. ✪
Dmitri Zagidulin: Yeah people people did well yeah. ✪
Manu Sporny: Okay cool okay well good there's a quite a bit of time between now and then you know we'll have yeah good okay good for those of you that weren't a part of the first plugfest I think we had what a grand total of three weeks to really Implement and demonstrate some level of you know VC display interrupt but it was good it got everyone yeah it's a. ✪
Manu Sporny: Okay thanks for that Dimitri that's good that gives us a bit of planning is there any any thoughts about you know what apis if any or did methods if any or is that just like the topic of the next discussion in these need you okay. ✪
Dmitri Zagidulin: That's that's really the topics as you can probably imagine there is a three or four different Lanes or groupings or communities do the VC API open as you connect family of protocols and of course wacky did come. ✪
Dmitri Zagidulin: So one of the challenges of the plugfest is. ✪
Dmitri Zagidulin: Do we demonstrate interop within that particular lane and then for the overachievers wallets that can speak the different families of protocols. ✪
Dmitri Zagidulin: Really that's the topic that is going to be the subject of much argument on the mailing list. ✪
Dmitri Zagidulin: More agreement that's correct that's right that's right I do not mean to cast aspersions preliminarily. ✪
Manu Sporny: Or agreement we just all going to agree with each other we're just gonna agree on a single protocol and in put all this behind us it'll be great all right any other updates are anything Community updates before we go in to use case updates. ✪
Topic: Use Case Update
Manu Sporny: All right Eric over to you Eric and Josh over to you where are we on use cases when should we talk about them next etc etc. ✪
Eric Schuh: Sure so I think since the last time I gave an update Joe and I have had some discussions and our plans have somewhat shifted a little bit this is still dealing with someone at the Fallout of one dropping off so plans change but effectively we accepted the existing. ✪
Eric Schuh: Case GitHub and I am working on what I believe is up to seven P ARS one for each of our six use cases and then a general one to respond to some of tall Ted's requests for some just minor I guess formatting changes here and there so I'm planning on having those 7pr. ✪
Eric Schuh: Better platform for talking about each use case individually worked out some bugs with the mermaid stuff in rendering I think as well so I think next week would maybe be a good time to take a look at the GitHub repo and its current state I don't know if there's going to be too much to discuss because I have a feeling people will it'll be more useful for people to kind of take their own time outside of this call for some sense of that to review and then maybe if we have. ✪
Eric Schuh: Have issues we can come back the following week or in. ✪
Eric Schuh: Six and have discussions then but look for those P RS in the next week before this call next week I'll I'll have them. ✪
Manu Sporny: Awesome great thank you for that and for all the work there Eric I really really appreciate that and Ted and Joe as well you know for input I'm sure I put myself on the cue to say I finally got around to fixing that mermaid flow diagram rendering thing in respect so I don't think it does any of the weird vertical height stuff anymore and there's a new release out there so I don't know if you saw. ✪
Eric Schuh: I did yep and I'll take a look during this this PR process one last thing I wanted to mention is that Joe and I have also decided to move our six use cases that we have so far to the focal use cases section of that document and start to cherry-pick kind of more breadth of use cases from both the VC use cases document and the did use cases document so that. ✪
Eric Schuh: Out of that so if anyone has any use cases from there that they'd like to see appear in the VC API please either submit a PR or make an issue and let us know. ✪
Manu Sporny: Awesome thank you for that okay any questions and concerns around the use cases document. ✪
Manu Sporny: Do either of you have I have I've wanted to do either of you have an idea around like how this gets into the VC working group or not in this iteration do you do you think I could do you feel like it might be in a position where you would want it as a use cases document published as by the VC working group. ✪
Eric Schuh: I guess while we're waiting for him my initial thoughts would just be that similarly to how we want to start cherry-picking use cases from both the did use cases document in b.c. use cases document I think that there's a good chance that some of this will flow into it I'm not sure if one-to-one copy would make sense or not probably try to leave that to the VC to group to decide. ✪
<joe_andrieu> It's a good candidate for adoption by the VCWG
Manu Sporny: Okay we can we can bring that up you could type type out what you're saying Joe if it's short but we can come back and discuss this on a future call as well. ✪
<joe_andrieu> I'll raise that there once we get going
<joe_andrieu> +12
Manu Sporny: Candidate for option on there we go it's a good candidate for adoption by the VC working group okay good just wanted to see if there was interest there from seizing on working on use cases to pull that Mark in okay sounds good Joe you might want to raise an issue I don't know well we can just bring it up we're first meetings next week so you know we can just. ✪
Manu Sporny: Right moving into the core of the agenda now we're going to start talking about options so the specification this came up during testing so Andrew Jones has been working on the test suite and noted a bunch of issues with the the OAS files. ✪
Manu Sporny: Things for options that no longer makes sense or we're not using and that sort of thing so we're going to go ahead and take a look at that let me go ahead and share my screen. ✪
Manu Sporny: Okay so I think this is it and then let me pull up the VC API. ✪
Manu Sporny: In right now we are going to look at issue credential in specific the specifically the options for issuing credential in right off the bat there's some errors here or things that look like you know they're they're wrong to a certain degree so every single one of the points that we have has this options object one of the first. ✪
Manu Sporny: Had was as the op ER is the options thing optional or not like do you have to specify options or can it be an empty object that kind of stuff. ✪
Manu Sporny: Well you've got let's see if you have audio if you've rejoined because you added some things here to start us off yes I can hear you. ✪
Joe Andrieu: How About Now new browser so you know I realized procedurally this might be an annoying place it's a raise this but maybe it suggests a new issue on its own but we still don't have our endpoint specifying which component is hosting that endpoint and who's expected to call it and I think that's confusing a lot of the conversations about are we talking about an endpoint on a. ✪
Joe Andrieu: Iris and those end up I feel being very different surfaces. ✪
Joe Andrieu: So without that it's hard for me to even understand which options were talking about. ✪
Manu Sporny: Yeah plus one to that and you've been very consistent about you know that being an issue and I think the group agrees that's an issue so would it be okay if we specify which end point we're talking about like which which app we're talking about sorry which which thing we're talking about like whether it's the issue or a poor the issue or service that we're talking about for launching into a conversation. ✪
Joe Andrieu: Yeah I think that's great I mean I think that the key thing is for us to have a good conversation I think we need to have that defined I think once we do we can talk about it and then I think there's a second question is how do we get the spec text updated so that incorporates that in some some way. ✪
Manu Sporny: PS maybe we could identify maybe we can add something to the OS to say oh this is meant to be exposed through the issuer app or it's meant to be exposed through the issue or service where it's meant to be exposed through both I don't know if we have any in points like that but maybe we can just kind of tag each one of the endpoints on with respect to where they're expected to be. ✪
Joe Andrieu: You know I don't know OAS enough to know if that's sort of the right way to do it but it sounds reasonable. ✪
Manu Sporny: Well if it's not supported by OS we can just put it in the respect proper to start. ✪
Manu Sporny: I guess because I was asking the kind of the question conceptually site conceptually do each one of these endpoints map to one or more roles in the ecosystem that can decorate or one or more what are we calling these things systems Joe what would what's a what's a nap and a service is that a system is it a roll. ✪
Joe Andrieu: I've been I've been calling them components I think that's the language with that first diagram in the VC API itself where we identify those components. ✪
Manu Sporny: Hard to read English but oh well okay so. ✪
Manu Sporny: I need for PR add a ripped ER to each endpoint that lists which components it's expected to be attached to. ✪
Manu Sporny: Okay okay so that's the first thing so credential issue. ✪
Manu Sporny: So this endpoint is expected to be exposed on an issuer service that's what implements it but it could be exposed through the issuer app I'm that's a question not a not a it's an assertion that's looking for people to say no that sounds wrong. ✪
Dave Longley: I'm going to go ahead and assert that it sounds wrong. ✪
Dave Longley: Part of it that seems right as it's exposed on the issue or service I don't know what it would look like to expose it on the issuer app. ✪
Manu Sporny: Is a software-as-a-service thing an issue rap. ✪
Dave Longley: No I don't think so I would think that would be an issue or service. ✪
Shawn Butterfield: Yeah I'm just thinking about what this would look like if I were to implement it it wouldn't be so I'm plus one today we wouldn't be on an issuer app we think of it as a developer service so it would feel to a SAS developer like a low-level API or a low-level library that they would implement. ✪
Manu Sporny: What are we is an issuer app Joe is an issue or a PK is a website in issue rap. ✪
Manu Sporny: Which is like a human facing website and then if it exposes apis is it still an issue rap or does it become an issue or service at that point. ✪
Joe Andrieu: So certainly a website could fulfill any of these roles I mean I think I do not personally make a distinction between json-based apis is being magical endpoints any different than a website URL is an endpoint the difference that we put into the architecture is that a nap executes the business rules and policies whereas the service component is providing generic services at the behest of a nap. ✪
Joe Andrieu: So in the in the in the scenario that we use for u.s. permanent residence card the there was a mock website for USCIS which held the business logic about who was supposed to get what is credentials issued and that website spoke over the back end to the verifier or the issuer service sorry to get those credentials issued. ✪
Joe Andrieu: So the Touchstone that I've use is you know the business rules that are specific to that application as opposed to a generic service which is software-as-a-service. ✪
Manu Sporny: Okay so one way to look at this is anything that provides generic Services is a service like the shorter service we are fire service in things that have business logic in them are the apps. ✪
Joe Andrieu: That's right that's how I tend to think about it. ✪
Manu Sporny: Okay that that seems like a nice clean the stupid. ✪
Dave Longley: Yeah and the other thing I would add to that is that the that business logic acts as a gating factor for the application to use decide whether or not it's going to use the service so there's sort of a trust boundary thing that's how I tend to think about it. ✪
Manu Sporny: Okay good it seems nice and clean architecture Lee. ✪
Manu Sporny: Okay all right so credentials issue is on the issue or service. It has in the way you use it is you send it and unsigned credential and it will basically attach a prove to it in and send that proof back in previous calls we had we seem to have come to agreement that these. ✪
Manu Sporny: Especially this one is configured is pre-configured through some kind of out-of-band mechanism to use a specific to use specific key material to use specific revocation list formats basically the endpoint is configured with all of these these things so calling and dynamically changing. ✪
Manu Sporny: In the credential status mechanism and all that kind of stuff is complexity that we seem to have shied away from. ✪
Manu Sporny: So that's kind of the background for the options object here. ✪
Manu Sporny: We have some weird things in here like for example Challenge and domain challenging domain are typically used on presentations they are not used in credentials when signing credentials I think and then for credential status we're say I think what we've said is that thing credential status is not. ✪
Manu Sporny: Settable anymore or by default it's not something it's something that's pre-configured on the endpoint in not settable when you make the call Dave. ✪
Dave Longley: Yeah I was just going to say that the challenge and domain which could also sort of be understood as a audience are things that are used with authentication proofs and those are not the kinds of proofs that you put on BCS and you put assertion proofs on them and so challenging domain I don't think make sense here and gradual status as mentioned would be something that was already configured for the system so that would also for that particular issue or endpoint or configuration and so that wouldn't make sense as an. ✪
Manu Sporny: Okay I'm hearing no objections I'm worried that there's some kind of Miss rendering going on here so I'm going to go and look at the OAS just temporarily. ✪
<kayode_ezike> Couldn’t the service provide its own value for ‘created’?
Manu Sporny: No it would be in like who gets your credential options up here it is okay all right so we're talking about striking challenge domain credentials status okay there are no objections to that need. ✪
Manu Sporny: OSHA mean credentials and remove challenge amazing credential status from a list of suitable options. ✪
Manu Sporny: Don't have normative language around that default but that's fine we can fix that later there's another question around a options is the options object itself optional like do you could you just do credential colon and put in a credential and that just leave options completely blank. ✪
Manu Sporny: This is true across the entire API. ✪
Manu Sporny: Clearly we'd have to look at every single endpoint but I think it's true across the entire API. ✪
Manu Sporny: Because if it's not an option if it's yeah it's the I'd like if it's in options at shouldn't we shouldn't be doing this whole mandatory options thing. ✪
Dave Longley: It will probably be true for the whole API but as you said we need to look. ✪
Manu Sporny: So we'll keep that in mind as we go along but I'm sure that when there are no mandatory options which should be true for all any points at The Shins object emitted. ✪
Dmitri Zagidulin: I'd like to propose that we tackled the topic of verifier options from the end right what Amazon purportedly starts with the Press. ✪
Dmitri Zagidulin: Is before doing that depends that's we start that their app UI that's from that here's here's why proposed that. ✪
Dmitri Zagidulin: Most of verification you I implemented so far tends to. ✪
Dmitri Zagidulin: Even though we do have a little bit of fine-grained results right we have a list of Errors we have a list of checks performed but I would like to propose we go one step further and have the verify API return back a list of events and then pass fail on each one of them so for example right the reason I mentioned start with you I first is. ✪
Dmitri Zagidulin: Even imagine a wallet or a verifier app displaying an overall status verified or not but then displaying the details a list of okay expiration date checks out the signature checks out but the key was revoked or the credential was revoked right so my proposal is and this this would affect the options object which is why the working backwards Bart what if we. ✪
Manu Sporny: Yeah I mean that that that sounds intriguing Dimitri I think the so yeah plus one to exploring that I think you know we probably when you and you included this in what you said right we I'm concerned that we need a simple yes no response back with more detail which is what exactly which is what I think you're you're adjusting. ✪
Dmitri Zagidulin: Response to that would be one one reason why might be a good idea to provide an event log in success as well is because different verify our services will perform for in checks right so it informs the user. ✪
Dmitri Zagidulin: Exactly what do we mean by this is verified did this particular service check the revocation status or did this particular check. ✪
Dmitri Zagidulin: I don't know check for the issuer's keys revocation. ✪
Dmitri Zagidulin: Not not all services will be do that hence the level of. ✪
Dmitri Zagidulin: Okay so you're absolutely right that we don't want this mechanism to shore up non-conforming implementations but so far the specs and implementations leave a lot of leeway for implementers which is should be a separate discussion topic but also even business logic wise you don't always want to like just as an example right. ✪
Dmitri Zagidulin: With the driver's license when using the physical driver's license for age verification. ✪
Dmitri Zagidulin: The verifier looks at the date of birth but also in some cases looks at the expiration right so some venues will say yeah even if this is a valid license and your of age because the credential has expired we're not going to. ✪
Manu Sporny: Well go ahead Dimitri I'm just noting that Joe's been on the Q so Dimitri Joe and then David. ✪
Dmitri Zagidulin: That's also tomorrow that use case to give the verifier the ability to perform a subset of the checks. ✪
Dmitri Zagidulin: Would PA real wood does not necessarily denote about implementation it is still both are valid. ✪
Manu Sporny: All right thanks to me to go ahead Joe. ✪
Joe Andrieu: Yeah I think you both have good points I think the seems to be the right balance is to make it optional to include the event log on a failure value of I'm sorry include the event log on success and that we should probably always include it on failure I'm looking at this from a debugging standpoint and I don't know how many times I've. ✪
Joe Andrieu: I was doing something that I didn't realize it was doing and they're sort of information maybe I turn it on and do a test or maybe I just have it on all the time but I could see in production you may not want to have that extra traffic so optional seems like a good way to handle it. ✪
Manu Sporny: Um I'm wondering if we got it I mean it's so these are all good points I'm wondering if we're confusing verification from validation I think what what Dimitri I heard you say had a lot to do with validation use cases not verification so this is a huge interoperability could be a big interoperability issue if you have some verifiers saying yeah the verifiable credential is valid and you have other verifiers saying no it's not. ✪
Manu Sporny: I think that we made a distinction in the vc10 data model sorry we made a distinction in the vc10 specification where we said there are two processes active here verification and validation verification checks for things like is the signature valid is the is the verified well I think it there we couldn't even agree on that right because because there were things like is the is the. ✪
Dmitri Zagidulin: That's exactly my point but the lack of a. ✪
Manu Sporny: Well I think what I thought what we said was okay then we need to split these into two things and it may be that we need to split this into two different apis the verifying API will always do the same thing regardless of what issuer like their normative things you have to check for like the signature being valid for example in you have to check for the expiration date as an example but when it comes to do you do you pay attention. ✪
Manu Sporny: All of a sudden you're in like validation and that's where kind of the event log in specific business rules are triggered and that kind of thing so I'm wondering. ✪
Manu Sporny: I'm well one we can have an event log for both but I'm wondering if we want to separate verification from validation I have two different endpoints or if folks feel like we really should have this all on the verification and point. ✪
<ccgbot1> DavidC has been added to the queue: DavidC, DavidC
Joe Andrieu: Yeah it depends which end point you're talking about so validation as is written up in that section on architecture happens at the app so the app is one that knows the business rules and knows whether or not expiry matters or knows whether a particular issuer is valid for a particular assertion and my sense of verification was your check in the crypto and you're checking the status property and that's it so. ✪
Joe Andrieu: Talking about having a validation endpoint at the verifier service I think that's probably a bad idea I do think it is something that app needs to handle and whether or not they expose an endpoint for it is is my sense an internal question for the app developer. ✪
Manu Sporny: Right thank you Joe Dimitri you're up next. ✪
Dmitri Zagidulin: So I think this is a really central question for us whether we want to separate verification validation into two separate API endpoints 11 consideration is that if we do have two separate API points does that mean you the verifier. ✪
Dmitri Zagidulin: It's to make to API calls and. ✪
Dmitri Zagidulin: The client that is making the request. ✪
Joe Andrieu: Right so the when you said the verifier makes multiple calls I'm thinking you mean the app calling the service but I couldn't tell from the question. ✪
Dmitri Zagidulin: Yes let's say I've going to service. ✪
Ted Thibodeau: +1 Validation == business logic; verification == crypto, basic structure. Separation of these endpoints seems optional to me. ✪
Joe Andrieu: Right so in that framing I think I still hold the what I said before which is I think the app is responsible for validation and therefore the app would not be asking the software as a service to check its business rules the app itself is going to be an embodiment of its own business rules and and if an app calls a bunch of endpoints internally because it's got some micro Services architecture you know that's up to the app to decide how they how many endpoint calls they want to make on their own. ✪
Manu Sporny: All right thanks Joe um Ted mentioned something in text David you're up next. ✪
Manu Sporny: There is in the in the jitsi chat I can only see one Q so we'll we'll handle that that shouldn't hopefully you know trouble. ✪
Kayode Ezike: Sidebar: Does it even make sense to refer to the functions in an apps as “endpoints”? ✪
Manu Sporny: Um thanks David Ted do you want to vocalize what you put in to the chat Channel. ✪
TallTed_//_Ted_Thibodeau_(he/him)_(OpenLinkSw.com): Yeah I can make my mic work. ✪
TallTed_//_Ted_Thibodeau_(he/him)_(OpenLinkSw.com): What I'm saying is physically validation to my mind as business logic and verification is crypto and basic structure is the thing integral. ✪
TallTed_//_Ted_Thibodeau_(he/him)_(OpenLinkSw.com): Separation of those two endpoints you know optional to me there's I can conceive of situations where I would just want one thing for anybody to deal with and what requests they made to it would govern what process are and what they got back. ✪
Manu Sporny: Okay so the only question I have at that point Joe said thumbs up to that Dave Longley did I see you + wanting that or were you plus wanting something else. ✪
Dave Longley: Yeah I'm in agreement with Joe and Ted yep. ✪
Manu Sporny: Okay alright okay so that then calls into question the name of the endpoint because the name of the endpoint is credentials and verify but we're also doing validation in it how do you square that Circle. ✪
Dave Longley: Well I don't think we are doing validation in there especially we look at the definition that we put into the VC data model spec we're checking cryptography structure and timeliness which involves credential status and expiry date and I think all of those things are generic checks that don't involve any complexity for. ✪
Dave Longley: Reject a we would return false from a verification point of any of those checks failed and we had an event log as was described or whatever we want to call this log business the app could apply business logic rules to make exceptions if it wanted to. ✪
Manu Sporny: Actually hold on I'm sorry David is that what is that an old kyo-ahn said like okay sorry yep got it got it go ahead Joe sir. ✪
Joe Andrieu: I was mostly just going to agree with Dave I don't think validation is happening at the verifier service I think it happens within the app and it may or may not express any point I think we're talking about the verifier service API which should not be doing validation. ✪
Manu Sporny: All right Dimitri does that gel with your worldview or is there some. ✪
Manu Sporny: Because I feel like there's some misalignment but I can't quite put my finger on it. ✪
Dmitri Zagidulin: It's it's a reasonable stance. ✪
Dmitri Zagidulin: I am okay with it for the moment. ✪
Dmitri Zagidulin: Headed that way see if I run into any difficulties but if we're saying this if we're saying that verification is atomic essentially the we do want that event log that there is the question of whether or not we want. ✪
Dmitri Zagidulin: Turned on success and Joe made a good point for debugging purposes it might be a good idea so that's a good candidate for our options object which is how we started this whole conversation but the thing I want to mention is if we're treating verification versus validation as as atomic as the thing for the service to perform it would be really interesting to see some normative language for which exactly the steps we're expecting other fire service to perform. ✪
Manu Sporny: Yeah I agree that would be we need a trainer upright because because if we don't do that then all of a sudden some implementations are checking for timeliness and other ones are not and if we're checking for timeliness then we have to be maybe have an option where we can override the time. ✪
Manu Sporny: Like I got this in the past I want to verify it was valid in the past go ahead Joe. ✪
Joe Andrieu: Yeah I don't think that's what timeliness means in this context I think it means checking the status and point. ✪
Manu Sporny: Okay I was I was going for something else there I agree we need to check the status endpoint but what happens if the if the credit credentials expired yesterday. ✪
Manu Sporny: Interesting yeah I know like I get it. ✪
Joe Andrieu: This was to support right the revoked driver's license. ✪
Manu Sporny: Yep yep yep yeah okay alright so so expiration date issuing State all that stuff is really about validation not. ✪
Manu Sporny: I get it okay yeah that makes sense to me does anyone else have any concerns about that. ✪
<davidc> it is ssential to describe the verification steps in the VCDM
Manu Sporny: Okay King so what are the steps for what are the normative language check the proof check the credential status. ✪
Manu Sporny: Check for all its really checked the check check to make sure the issuer check to make sure that. ✪
Manu Sporny: Check to make sure the issuer key has not been revoked as of a particular date. ✪
<davidc> check that Now is between the issuance date and expiration date
Manu Sporny: I'll just leave this I think we're going to need a date thing here because how are you going to check the business rule what API are you going to call to see if something was valid on a particular date so so let me here's the here's the issue I'm concerned about you've got a verifiable credential the issuer key was revoked yesterday but you really just want to see if the thing was valid the day before. ✪
Manu Sporny: Day so you're in the middle of a validation check but you need an endpoint to call to see if the issuer key was valid at a certain point in time Joe go ahead you're on the queue. ✪
Joe Andrieu: Sorry I lost my train of thought that the one thing in here that's that you haven't mentioned is that it's a it's a valid BC structural checks have been mentioned but I don't think we've defined what that means I don't know if we have a formal schema for example those sorts of checks what a I'm hesitant to. ✪
David Chadwick: +1 To checking that the VC conforms to its schema ✪
Joe Andrieu: Just that temporality is anything other than a validation check however it seems like it would be particularly useful to be able to say validate this to the best of your knowledge at a particular point in time the problem is you can't necessarily adjust all the parameters to go into the past especially for something like a status check so I think this semantics have to be. ✪
Joe Andrieu: Now and there may be some cases where we could optionally support check it in the past however when you get back that event log you will know that expiry failed and so if you have business rules to say hey we don't care we're actually we care about yesterday then I think your validation process could handle that if it has the event log. ✪
Manu Sporny: Interesting any other thoughts on that. ✪
Dave Longley: I would my thought would be I would prefer all these things to fail closed and all of the verification systems can all know about expiration and current time and they can know that they can check whether or not the current time is between the issuance date and expiration date and they can fail when that happens and that's returning event log that can be checked by business rules to allow the VC to be used if desired. ✪
Manu Sporny: Interesting okay alright alright so on the pr is to Define steps for verification at the verifier service using normative language which means you check to make sure the structure of the VC is valid you check the credentials schema that's associated with it if one exists you check to make sure that the issuer key has not been revoked you check to make sure that the credential. ✪
Manu Sporny: As having been revoked and inevitably we will go to the VC 20 API and maybe add additional checks what do we do when that happens go ahead Joe. ✪
Joe Andrieu: Yeah I'm not answering your last question there it was about if can we generalize the language here for issuer key I think it should be verification method or something. ✪
Manu Sporny: So it seems like the event log having the event log is a very important thing because in the future. ✪
<dave_longley> and check that the current time is between issuance date and expiration date
Manu Sporny: How do you differentiate between what checks are if we add a check which is you know over the next 10 years almost inevitable. ✪
Manu Sporny: How do you know whether or not that check was being made. ✪
<ccgbot1> DavidC has been added to the queue: DavidC, DavidC, DavidC
Dmitri Zagidulin: Wait so was that a rhetorical question or is a question to the group. ✪
Manu Sporny: Well the question of the group I mean like how do you eat we're going to add another check at some point in the future like let's just say that you know I we for whatever reason vc10 didn't have the credential schema property and in the future it does well we wouldn't list the credential schema property here but then you know we do or or if the verification method let's say we had revoked but we didn't have suspended and now we have suspended. ✪
Manu Sporny: I note the sorry I have been not tracking time where three minutes over so go ahead Joe and then we're going to have to shut the call down. ✪
Joe Andrieu: I was just trying to thumbs up and at the other thing. ✪
Manu Sporny: Okay all right good okay so the other part of the pr that's needed is we're going to say we want an event log it's an optional value not mandatory that provides the checks performed and by default that's turned off. ✪
Manu Sporny: Okay all right thank you everyone for the call in the the Lively discussion today we got through a lot of things especially we've got a number of PR's that need to be raised so I will go ahead and note that here and that's it for the coal will see everyone next week where we will talk a bit about the use case of stuff and keep going through this options discussion thanks all bye. ✪