Meeting minutes
Attendees: Denken Chen, Joe Andrieu, Phil Archer, Dave Longley, Henrique Xavier, Benjamin Young, Elaine Wooton, Ivan Herman, Manu Sporny, Dmitri Zagidulin, plus 5 more individuals
Confidence Method v1.0 Pull Request
Confidence Method v1.0
Restructuring Confidence Back
Joe Andrieu: Okay. Um, Denken, uh, all I have on my agenda for us is the pull request. Were there some other things you wanted to go over? We could walk through the issues.
Denken_Chen: Uh not yet.
Denken_Chen: We would like to say that this meeting will be recorded and will be published in our mailing list uh for the meeting minutes. So if you feel uncomfortable about this, please raise your concerns or leave the meeting. Um and also if you are new to this meeting, you can also uh give us a short introduction if you will too. Um is there any concerns about the recording of the meeting or if you would like to self introduction for yourself? Yeah, please, Henrique.
Henrique_Xavier: Uh I'm a researcher on web technologies working at the network information center from Brazil. Uh right now we've been uh paying attention to verifiable credentials for some time but now uh Brazil approved a law uh requiring age verification for certain websites and applications. Uh so this gave a big push uh to the verifiable credentials. So I'm here to follow up the discussions.
Denken_Chen: Nice. Great to see you here. And also Elaine is back. I would like to mention that this meeting will be recorded as before. So make sure you're okay with the recording. So we are getting started. Okay. So no problem. Okay. Uh Joe, let's go ahead. I I think the PR is the great ways to start it to restructure our confidence back. Uh would you be able to screen share the draft?
Joe Andrieu: Yes, I'm happy to. And let me drop in um a URL. Do we have a a similar subtopic kind of pattern here,
Denken_Chen: Thanks.
Joe Andrieu: Brandon, that we can leverage?
Manu_Sporny: You can use all of the RC commands.
Joe Andrieu: Like we'll
Manu_Sporny: So you can type subtopic colon in the thing and it will just work.
Joe Andrieu: cool. Awesome. Thanks, Okay. So this is the preview of that PR. Um mostly it is a uh conceptual update uh to introduce the shifts uh the expansion from just the con confidence method to um sort of a generic approach to increase confidence. Um and so let me put the abstract up and folks can read that. This is the framing u mechanisms to be used with the VCDM to increase a verifier's confidence that the presenter of a verifiable credential is in fact appropriate related for its use. I'm trying to avoid the subjecter language here. Um in the simplest situation, this means the presenter is the original legitimate recipient of the credential. This specifications defines a data model for expressing competence methods and evidence. Oh, that's a I should fix that. And evidence and a verifiable credential and provides examples of how to use it.
Assurance Methods Vs. Evidence Property
Joe Andrieu: Um the reason evidence is no longer uh I think what we should be talking about is probably in this section and I definitely want to touch on it and get feedback. Um, one of the things that that we have discussed is um, and it's one of the reasons we shifted this language in the charter and that the language shift here was there's there's almost certainly value in allowing an issuer to state for the record what identity assurance level they achieved for any given subject in the VC. Um, that was a good place, a good use of evidence. If it was for the full VC, that would make sense. Um but as we've constructed this confidence method we realized this is specific to a subject an individual subject ID in the claim set. Um so we wanted to use that same flexibility for assurance methods. So instead of using the evidence property we want to propose that we are using an assurance method property which is a direct corlary or peer of the confidence method. So it shows up in the claim sets and what it means is that the issuer um achieved this level of assurance for that subject prior to issuing the credential.
Joe Andrieu: Um and one of the examples that we talked about that led to that was if I'm in a uh uh a marriage certificate that has an officient two spouses and two witnesses, there very well may be different levels of assurance for those different parties. I could see that the officient and the espouses may have a higher level of assurance, whereas the witnesses don't really probably don't need that. I mean, it's not my call. I'm not the policy maker here, but it seems like uh that's not as important. Um uh Ivon, I saw you put your hand
Ivan_Herman: Uh just for my understanding,
Joe Andrieu: up.
Ivan_Herman: does it mean that we add a new property or change a property in the VCDM data model itself
Joe Andrieu: Um, yes.
Ivan_Herman: because then this has to be put into the data model document. So that has to change as well as part of this PR so to say.
Joe Andrieu: Um, okay. I'm going to let Mana go and then I also had a thought about that, but go ahead,
<Phil_Archer> Manu just said what I wanted to say, no need for me to repeat it
Manu_Sporny: Uh yeah,
Joe Andrieu: Mann.
Manu_Sporny: I think ultimately the answer is yes, Savon. Um they're I think these extension specs or quote unquote extension specs um have two contexts associated with them. You're right. We need to put it in the vocabulary. So yes, uh we should probably do that um along with you know modifications to the data model here. Um and then the expectation I think is there will be two contexts. one of them so that people can layer this into their you know VC2O uh uh uh credentials VC11 credentials I think if we can get that level of extension and um and so you can just layer this in uh if you want um uh or you wait for us to release VC2.1 in that context which will have these extensions in there and that could be you know another year from now So um there are two ways to do this. You know ideally everyone upgrades to VC2.1 and VC2.1 will contain these you know things in there. Um uh but if people for whatever reason don't want to update to VC2.1 they can do it peacemeal.
Manu_Sporny: Uh, that's
Joe Andrieu: Um, yeah, before you go, Phil, um, I was going to say this could also be added to the extensions. Um, we I don't think we have to do that because we are part of the VCWG, so this body politic can make that decision. I mean, not everyone's here, but this group that we're a part of. Um, but sometimes we do have other groups who who control the vocabulary. Um, but let's not make it an extension. I think we should push to get it into the VCDM. Go ahead,
Phillip Long: Yeah,
Joe Andrieu: Phil.
Vocabulary Vs. Data Model Updates
Phillip Long: just to for my clarity when you say um add it to the vocabulary, I'm assuming you mean literally add it to the vocabulary uh file that's associated with the VCs and manu when you're talking about layering it. Do you mean that this would just simply be an additional uh a second a following context within the context file to um to add that element?
Manu_Sporny: Yes.
<Denken_Chen> Confidence levels (from the issuer) · Issue #16 · w3c/vc-confidence-method · GitHub
Phillip Long: And apparently that's yes. Thank you.
Joe Andrieu: I had a question for Manu.
Joe Andrieu: Um, we have we have this document that's now standard track. Um, do you think we need to update the VCDM spec text or just the context? Like I don't know if we've dealt with how these extension specifications extend the vocabulary without needing to update the spec. So, if you could comment on that, I'd appreciate it. And I see Evvon
<Dave Longley> "assuranceLevel" seems to be "at a point in time", so i think it needs more "wrapping" of some kind.
Ivan_Herman: Yeah, I mean answering also to you Joe, first of all I I would prefer to just concentrate on the latest version of what we
Joe Andrieu: next.
<Dave Longley> it's more like the issuer is expressing an event that occurred at some time/date/location/etc. where a level of assurance was met
Ivan_Herman: work on. We see the M2.1 at some point uh and not roll it put it back into an older release. It just complicates our own life. Whatever was older was there. It's it's cast it concrete and let's let's leave it the rest. So I think we should just do it on the latest version. Um wait a minute. What was the other question Joe that that you asked and I wanted to answer?
Joe Andrieu: Is would it at all be appropriate to just update the the context file with the definition in this spec text or really should we is it more proper that we update the VCDM spec and the context
Ivan_Herman: I think the the the letter the VCBM spec has a reference to
Joe Andrieu: file?
Ivan_Herman: the uh to the the confidence method as a it lists it as a uh exception no extension property or whatever the name was that we used there uh that has to be changed and updated and the vocabified itself must be updated as well.
Joe Andrieu: Okay,
Ivan_Herman: The context file is not a definition.
Joe Andrieu: great tape.
Dave Longley: Uh couple of quick thoughts. I put one of these these thoughts into the PR that uh if we wanted to avoid some of this vocab stuff, we might uh determine that it makes sense for us to express assurance level information as some kind of confidence method. Uh the other point I want to make is that confidence method refers to a method that can be used to increase confidence.
Joe Andrieu: Ready?
Dave Longley: Um I think that's fairly broad. could cover things like assurance but I the description of assurance method does not seem to cover a method rather it's just an announcement of some some level or something like that so one way to express that as a confidence method would be for to say that a user can selectively disclose um that they they have signature over the fact that they completed some assurance test and got some level with the with the issuer.
Dave Longley: So, uh there's there's I know we're looking for some symmetry there, but I think we're kind of missing it a little bit. And we might be able to leverage that to avoid having to create a new property as well.
Manu_Sporny: Uh, a couple of things to respond to. So, I think plus one to what Ivonne said, we don't have to update the VCDM21 spec, but we probably should to to just keep it aligned with with this spec. That's one school of thought. The the other school of thought is like we should try and make it so that every time we update this spec, we don't have to update the VCDM spec for from a kind of like a maintenance long-term maintenance perspective. that might be the better thing to do where we're like, hey, BCDM supports confidence methods, but if you want to know anything about that, go and read the confidence method spec. I would like I would like us to try and I think do that. Um, and then whether we do that or not, uh, as Avon said, the context files are um they're non-normative to a certain degree.
Manu_Sporny: Like we the caches matter, right? But like what goes in them and how we change them, you know, can change from release to release. Um, so just some thoughts on how we how we do that. I I do think we'll not need to update VCDM, but I think let's update VCDM so that it just points to the confidence method spec for all the details. Um, uh, all right. And sorry, Phil, to steal your thunder. Um uh the other uh I guess um thing on the you know what I'll reue for the assurance level stuff um because there are other people in the queue.
Joe Andrieu: Okay. Um I think I'm next. Okay. Um one agreed manu. I think I think the right way to do it and Ivonne sort of hinted at it which was the current spec says hey confidence method is a point of extension. Um and it doesn't define any particular types. I think we can update update that to say there's an assurance method that's defined in this other spec but I think formally linking it from the VDSM in that lightweight way is maybe the right way to have a a more maintainable architecture.
Joe Andrieu: Um the other thing I want to comment on I fascinating Dave your response um did suggest to me that there is there is a type of symmetry here that I did not mean to imply. And so maybe maybe we shouldn't use the term assurance method. Um my thinking with the insurance method is definitely that it is not something that the holder does. It's something that the issuer is asserting that they did. And so it's not a mechanism where after the fact the verifier is doing something with the holder to to increase their confidence. That would be what a confidence method is. Whereas the assurance and maybe we could we could just maybe we call it assurance level. I think we hesitated from that because uh we weren't sure historically or in our current conversation in this community that that would be the easy drop in. But maybe this really is a statement of the assurance level that the issuer got. So maybe that's an easier term that would avoid potentially trying to interpret the symmetry of these two when they're at least for my sensibility not quite the same.
<Dave Longley> that's not true
<Dave Longley> you can have evidence be per subject
Joe Andrieu: Uh Dacon
<Dmitri_Zagidulin> @Dave - are you sure? Evidence is on the same level as credentialSubject, not under it..?
Assurance Level Terminology
Denken_Chen: Uh yeah, I'll paste uh previously I raise the issue 16 uh and use the new term assurance level because you can see from the example um as we study about this framework the identity assurance framework they were need identity assurance level uh they were ASOS levels of assurance and also from they have assurance level. So assurance has been using widely in different frameworks. So that's why I'm more uh for support the world assurance level for the lawyers for the policy maker to fully understand uh it's the way it's a field they can fill in based on their framework they've been choose and that's Ite.
<Dave Longley> evidence: [{"type": "OurNewAssuranceEvidenceType", "authenticated": {"id": "any subject", "level": "foo"}}] ... etc, just on the fly
<Dmitri_Zagidulin> i see
Ivan_Herman: Yeah, I this becomes an issue which we should probably decide on the main call but Phil is here so we will make a note of it. I think uh the proper way of doing it is to issue 2.1 as a public working draft. It's in our charter. We have to do that anyway. Uh just go there and do it like we did a few days ago, a few weeks ago with the um then akidna steps in and we can make all these changes quickly.
Ivan_Herman: Otherwise, if we just postpone it to sometimes when the when the sun comes or whatever, uh I'm sure that we will mess it up and we will forget it. It's it's just uh it's just messy. Uh if we have it in under Akidna, then we can make any change even if it is one single word, we can change right away. It becomes official as a as a draft and let's do it properly in my view. But that's a working group decision. We are not here to decide on BCDM. That's
Joe Andrieu: Thanks Ivon
<Manu_Sporny> vc-data-model/contexts/credentials/v2 at main · w3c/vc-data-model · GitHub <-- fwiw
Ivan_Herman: it.
Meeting Cadence And Resolutions
Manu_Sporny: Real quick on that, I'm wondering I mean there are a lot of us here like there, you know, 15 people here. I'm wondering if we can do a proposal and a resolution understanding that resolutions don't stand until 7 days have passed. Um it might because our next meeting is a month away, right? And so I'm concerned about the amount of time it's going to take us to just get to the next meeting where we can officially resolve that.
Manu_Sporny: I'm wondering if um there's a way for us to just say, hey, you know, we took this preliminary proposal and resolution on the call. Uh are there any objections? If there are no objections within 7 days, then the then the decision stands. Um that's the first question. Uh but specifically on assurance uh method, I agree with I think what folks are saying. This feels more like assurance level to me. It I thought that was like an evidence thing. I didn't think it was a confidence uh thing. So that that's an interesting I I thought you know I was very much an evidence thing what the issuer you know found from an uh I perspective uh plus one to you know specifying NIST SB863 because that's always asked for um certainly in government um sometimes in large organizations. I will also note that that you know document has uh IAL, AAL and FAL. So uh identity assurance levels, authenticator assurance levels which we should also care about and then federated something or another assurance levels which I don't know if we should care about.
Manu_Sporny: Um but there are three kind of assurance levels there different classes of assurance levels. Um all of them feel more evidency uh than confidencey. Uh but you know we should we should try to tease out like you know what what is what what is evidence versus what is what is establishing confidence. That's
Dave Longley: Yeah, I agree a lot with what you just said, Manu. I I think one of the goals of not using evidence field is uh was for this to appear at different places uh at any um generic subject in the graph of information. I don't know that that is necessarily that helpful though because assurance level to me seems to be more at a point in time and it needs some other kind of wrapping around it. Uh that might express the event that occurred, the time, the location, that sort of thing. Um where you know that level of assurance was met and if we wanted to bind it to uh or or have it be related to the V when that VC itself was issued again that seems like it fits in with the concept of evidence.
Dave Longley: Um, and we would also want to be careful that if somebody refreshed a VC, for example, that we would not mislead someone that that level of assurance was uh redone or, you know, at the refresh time. It was whatever happened at the original time. So, there are other considerations like that. So, it seems like I think we need to think about a little bit more uh about where this should
<Dmitri_Zagidulin> @Dave - are you proposing that we merge evidence with assurance level? (to just one field)
Joe Andrieu: Yeah. Interesting. Um the to my sense I think man assurance is definitely uh it smells like evidence. The difference is evidence can't be per subject. So if you have a VC, you can only say every subject in here uh is satisfy the same. Um and I think that would severely restrict the usefulness of the feature. Um for example, if I have um a uh a record of a dog's um rabies shot, um who is I4, right? like we can make sense of it because there's only nonsense if you do I for the dog. Um but you know that that is the core difference is that we were trying to get a per subject um uh element.
<Phillip Long> So that sounds like @Dave Longley described putting additional evidence in the wrapper around the originally issued credential.
Joe Andrieu: Uh to your point Dave that's really interesting to to me it is that the issuer is saying that when I issued this this was a this was my level of assurance that they have about the subject. um I'm not deeply enough in the IAL to understand what their temporal binding is. Um but um we could echo it in the data model. I mean if the assurance level is both a string um that indicates like NIST IL3 um maybe it also needs uh uh properties about when that was achieved and I think that would be a constructive improvement. We haven't yet drafted that language. So um we can unpack that to hopefully address that. Go ahead, Ebad.
Ivan_Herman: me. It's me.
<Dave Longley> it already does that ... not really a question at this time.
Joe Andrieu: Yes, Ian.
<Dave Longley> you can say whatever you want in the evidence value.
Ivan_Herman: Okay. Um, sorry to come back to the administrative issue, but many asked me to do that. Um first of all the decision on uh whether this is a valid resolution or not that's something which the chairs have to so Phil is here and he's on the queue so he may do it from my point of view from the process point of view it's perfectly fine because nothing requires us to make resolutions only on the what we call the main call but the other comment is that uh at some point in time we have to rethink the whole call scheduling and naming
Ivan_Herman: anyway because our charter has been just renewed uh and we have to start a new life so we give it the shape we want. Um so
Phil_Archer: Uh yeah,
Ivan_Herman: yeah
Phil_Archer: which is what I was going to talk about. So, thank you, Ivan. Um Brent and I haven't yet been able to have a chance to have a chat because he's been traveling. Um all being well, we will be able to speak on Friday. And this is certainly the uh the the the main topic to talk about, how often we're going to meet and everything else. If uh we continue just to have all group meetings every month, then for the reasons discussed in this meeting already, it's clear that a group like this having to wait a month just to get something approved, the people are almost certainly going to approve anyway is crazy. Um so my personal view which obviously Brent and I need to discuss with Ivan um is that uh a subgroup working on a document should be able to make that kind of um proposal that affects something else.
Phil_Archer: All I would say is I think it needs an email to the group that says hey please look at this. We've done this. I don't think you can just leave it to people happen just by chance to be looking at the GitHub repo. But apart from that, I definitely think this group should have the ability to go ahead and say any objection if we do this rather than having to wait a month at a time. That that seems silly.
Joe Andrieu: Thanks, Phil. Demetri, go ahead.
Dmitri_Zagidulin: So on the subject of uh sort of the different conceptual difference between evidence and assurance level one mental model that we can encourage is two two things. One is point in time versus can be added to on later. Uh meaning the assurance level is just at the point of time of issuance. evidence can be both at the time of issuance and then also later gathered. Right? We have this notion of uh both hash linking and regular linking. Uh we have this notion of compound credentials of uh making making a statement doing a verifiable credential and then accumulating evidence and endorsements around it whether the initial one was self issued or institutionally issued.
Dmitri_Zagidulin: uh evidence accumulates the the assurance level at the time of issuance does not. So that that and and the other uh the other conceptual uh distinction is assurance level concerns the identities of the parties involved of the subject for example whereas evidence is on the claims about the subject. That's it.
Joe Andrieu: Dave, go
Dave Longley: So I just yeah thank you.
<Phillip Long> The claim you've determined by a check of information asserted is to be trusted is different from an issuer's attestation. It's a trust me, I thought about it. Versus I've investigated the veracity behind the assurance. That would require evidence.
Joe Andrieu: ahead.
Dave Longley: I just wanted to dispel the notion that evidence can't effectively say whatever we want. Uh when we design a new evidence type uh evidence is just supporting information about uh the verifiable credential that the issues that the issuer is providing. We can talk about we can link that to any subject we want to any generic subject in the VC in any place. We can talk about essentially whatever we want to in that field. And I put in a chat just off the off the cuff, you know, a really simple example of a new evidence type where we would say something was authenticated, its identifier is this, its level was this, and then that could be about any anything else you talked about in the VC anywhere.
<Dave Longley> i agree we don't want to reveal the PII, but i still think it's evidence -- self-asserted evidence, if you will.
Dave Longley: Um, so I I don't want us to think that we can't use that field for that for that purpose. And it really does seem like uh that is the reason why the evidence field was created for issuers to put information that they used during their issuance process um to further support the the claims made and so
Manu_Sporny: plus one to what Dave just said. I'm looking at the context, the JSLD context in the document. It looks like the language does support what we had in there does support uh what Dave is saying. We might have to adjust it a little bit to make it clearer that it applies to every sub any subject. Um Dave, it's scoped to the verifiable credential stuff, but that means that anything below at the same level or below the verifiable credential can reuse it. Um, right.
Dave Longley: I can I'll answer that quickly.
<Dave Longley> it's still just "additional supporting information" provided by the issuer -- you have to trust the issuer's statement that they performed the check, but that's what they are doing.
Manu_Sporny: And it's protected.
Dave Longley: Uh no, but I don't think that that necessarily matters.
Manu_Sporny: You're
Dave Longley: This is a property about the verifiable credential and the evidence and that's also gets to the um the point
Manu_Sporny: right.
Dave Longley: that this is evidence about creating this verifiable credential and it takes that sort of uh point in time question out that I was making before.
Manu_Sporny: Gotcha. And then and so the question is do we want to allow it to apply to anything in the subree or do we want to keep it at the top level uh and just you know you refer to subjects in the evidence field by ID? Um, that's
Joe Andrieu: Thanks, Venu. Yeah, I I acknowledge Dave, we could we could adopt a pattern like that. Um, but the the conversation for both you and Dimmitri have convinced me more that it is what we're talking about with assurance level is not evidence.
Ivan_Herman: Yeah.
Joe Andrieu: um because we are not providing you you don't provide the evidence that was used to establish your IAL you know you don't you don't provide the biometric template you don't provide the sensor data these things are not enshrined and the way evidence um is actually here's the evidence that we use to uh have some confidence not to reuse that term but here's the evidence the issuer used so that you can look at the evidence and I um you're not looking at the evidence you're taking an attestation from from the issuer about the level of assurance they got.
Joe Andrieu: So I think to me these feel different. Um they smell alike but I think the nuances are different. Go ahead, Demetri.
Dmitri_Zagidulin: So, plus one to what Joe said. Joe, I agree with with that distinction. Uh that assurance level seems to be uh at a station or reference, but but not the copy. Uh but I just want to clarify uh Dave. So, are you are you proposing we potentially merge evidence and the assurance fields or or use the evidence property for assurance? Is that is that the upshot of your uh what you were saying?
Dave Longley: Um I I think evidence can be used for this. My my conception of this was uh that the evidence here is uh is for the fact that I talked about a subject and made claims about it. The evidence is that it's the subject that I thought it was because I did some identity assurance check at this level. That was how I was conceptualizing this. And so I'm just telling you I did this identity assurance uh check that it is my assertion that I performed this and that is my evidence that when I made these claims about the subject it was the subject I thought it was that that all seems to hang together for me.
Dave Longley: I don't know if other people can think about it in that way. Um, and uh, it seems to me that all of that makes sense from the perspective of uh, some some event occurred where this check was done and it was done for the purpose of issuing this credential. So that seems like it fits with evidence. It if we're going to put it somewhere else, I think we're going to be describing like an uh, authentication event or an identity assurance check event that happened. And that in itself might be better expressed as on its own as a VC. And that that's actually been done in some other work.
Joe Andrieu: Yeah, I really think it's it's they're different things like uh an IL3 statement does not provide the evidence for the verifier to evaluate it, but the evidence field should provide the evidence like otherwise we named it badly. And and if you look at, you know, what's on screen right now, which is an example from that section in the PCDM, you know, it is pointing to here's the video that we looked at, here's the evidence, you can go look at it.
Joe Andrieu: Um, and I think that is very much what we're not doing with IIO because we want to um, you know, we we want to launder the data so that however deep the issuer went in their identity assurance, including biometrics or PI or whatever, that information is not to be presented in an assurance level statement because that's not what you're there to do. You're not providing the evidence that we prove that Joe Andrew lives at this address. Like that would reveal a whole bunch of PII that I doesn't need to do. So I think I think I'm pretty big disconnect with that recommendation. Dave Manu, go ahead.
Manu_Sporny: I can see the difference that you're making, Joe. Um, I can also see how it could map to something that Dave's saying, but it's a concrete suggestion for this PR just to make sure it doesn't get held up because this is a much longer discussion. I think could we just put a an issue marker around like we are discussing, you know, the difference between assurance method and evidence right now.
Manu_Sporny: Um, I don't know if we have consensus to just at least rename it to assurance level. Um uh so so that that's concrete suggestion just if we could put a warning marker so we can get the PR merged versus like you know have a big long discussion about this or we can split it out that's also an option um uh about I um so you know when you go in into you know 863 it's not really uh prec script. It's not that prescriptive. Meaning like it's like, hey, you know what? Remote remote remote identity verification is totally fine, right? And you're I2 if you if you do that. Um, uh, how did you do the remote verification? Did you use, uh, you know, one of the modern LLMs that can detect, uh, deep fakes or did you not? Uh, and and you can claim IL2 for both of those things. Um, and and I think that's it's vague enough. So, I get your comment about like laundering the the core evidence so that we can make kind of a more generic statement.
Manu_Sporny: Um, but it can also not be useful information to the entity checking because they're like, I have no idea what your what your IL2 uh processes are. Uh, and so, okay, you did that, but how does that help me? Um so I I think I I so so you know since I believe that is the case with 863 why how is this mechanism useful right like why um you know I why why for an IL2 statement um would I pay any attention to the field because I don't really know like at what level the the vetting happened other than like in a very broad sense which I don't think is helpful.
<Dave Longley> "subject assertionMethod IAL2" <-- this would generally mean "this subject has an assertion method of 'identity assurance level 2'" ... which i doubt is what anyone means.
Joe Andrieu: Phil, go
Phil_Archer: very briefly. Um I think just just to comment that the depth of this
Joe Andrieu: ahead.
Phil_Archer: conversation shows that whatever is decided the explanation is going to need to be quite difficult to put together um to make the distinctions between um assurance and evidence and confidence. They're all very similar terms um and everyone who's spoken so far I think is a native speaker.
Phil_Archer: Pity the person for whom English is their third language. Um, so it's it's going to have to be very clear with lots of examples and potentially um people are going to get it wrong either and and they won't deliberately do that but they will get it wrong. And what impact would that have on the confidence in the truth of their statements if people actually use the wrong one by mistake?
Joe Andrieu: Yep. Thank you. Um Manu to to your point I you know the fact that it the the the NIST I2 may be useless. Um that's not why we're doing this. We're doing this because the NIST this assurance levels are being written into regulatory requirements. And so the issue is about letting the issuer signal alignment with the regulatory frameworks. Hence the NIST and the EIDS and the ISO. And I don't know if we can refer to the ISO. That's a whole another conversation I don't want to get into now because we're it's it's in other places. Um uh but I think that is a good reason to separate it from evidence.
<Manu_Sporny> wait, assuranceMethod doesn't go inside confidenceMethod?
Joe Andrieu: Like I is not evidence. I is just saying hey there's some external regulated uh framework. there's a vocabulary that's defined in the spec. So we can use this string and that string means that we are deferring or we are specifying I fal AL whatever the strings are um but without providing the evidence like it is not evidence. If you want evidence then that should go in the evidence property. I think that actually supports sort of this distinction that I'm advocating for. Go ahead Dave.
<Dave Longley> not as presently defined
<Manu_Sporny> I was thinking it was a subproperty of assuranceMethod... hmm.
<Dave Longley> (or proprosed)
<Dave Longley> proposed*
Dave Longley: Yeah. So, uh, to speak in favor of this, uh, this stuff actually being evidence still, I I think it's evidence. I just think it's self, uh, asserted evidence. If I'm going to issue a credential and I want to say this this person has this name and and so on, uh I might want to attach an evidence field that says that it gives additional supporting information even if it's self asserted to the verifier that tells them the reason why I think this is the person's name is because I performed this identity or check or assurance check or whatever kind of uh authenticator check we want to we want to talk about.
Dave Longley: That's not a key component of what I'm asserting about the person. I'm just letting you know that's additional supporting information that can help the verifier establish some confidence uh based on what the what I did when I issued this credential. And I think that fits really cleanly with the definition of evidence. And I I don't think we had anything that ever said you couldn't self assert evidence in that field. It's just additional information about the other claims you're making. I'm not interested really as an issuer to hand you a credential that says this uh authentication happened at this date and time. That's that's what I'm you know that's the claim. Those are the claims I'm making. That's I am going to make those claims. But in the evidence field as just this is supporting information for this other stuff I'm claiming this is the person's first and last name. And by the way, I did an if you go look at the evidence field, I did an identity assurance check to this
Manu_Sporny: Uh yeah, I mean plus one to that.
<Dave Longley> {"name": "Alice Smith", "confidenceMethod": ..., "assuranceMethod": ...} <-- proposal
Manu_Sporny: Um meaning, you know, I can see the distinction you're making, Joe, but also I think the the perspective Dave's providing is would work as well. Um one of the things that is tripping me up is I'm not seeing any examples in the specification about how assurance method is being used. And so I'm I'm like I'm I just presumed a bunch and based on some of the things you said, Joe, I'm like, "Oh, that doesn't align with the examples in my head." So maybe having some examples would be helpful either way for us to look at an example with evidence and look at an example with confidence method and then go like, "Oh yeah, they're really similar." Or, "Oh no, here's exactly why they're they're so far apart." Um because right now what I'm presuming is like assurance method is like a string and it just says2 and and I don't know if that's actually what's in other people's heads. That's
Joe Andrieu: Uh yeah, plus one for examples. Um I do expect it to be a string, although Dave brought up interesting issues about assurance level.
<Dave Longley> i'd rather it be: {"name": "Alice Smith", "confidenceMethod": ...} ... with an evidence field that says, btw, i did IAL2 on Alice Smith.
<Dave Longley> noting, this is a challenge if Alice has no identifier to reference.
Joe Andrieu: Um being potentially time bound in a different way than the credential is. And so, you know, that's an interesting nuance that we could add. Um I I feel strongly these are different. There are nuances here that I think are important. and the fact that we could we could jam this functionality into a field that I think is meant for different purposes. I have evidence that you could evaluate as opposed to attestations from the issuer. Um, but my my question for you Dave is are you using confidence in the way that you're describing or are you just arguing that it's possible? Because as the editor of the spec, I think this is a nuance that's important, but I'm not sure why you're pushing back against it other than to point out that we could reuse evidence. I just think that reuse is is not clarifying. I think it's confusing more than clarifying.
Dave Longley: I I think this feels like auxiliary information that was used to uh during the issuance of the VC to decide that the person usually we're talking about people here decide that the the person is who they are and then you're going to make claims about them.
<Dave Longley> modeling it instead as another type of confidenceMethod that Alice may selectively disclose solves that.
<Benjamin_Young> Render Method next week?
Dave Longley: So it really feels detached from the those other claims that you're making. It seem it does seem to me like this is additional supporting information uh that was used to issue the VC. Um, at least that's definitely seems like a use case to me and it seems like the use case that makes the most sense because as I was saying earlier I if you just put an assertion method on and tack it on any general subject in the VC to me that means you're asserting that this subject has an has uh a an assurance method. I typed assertion method by accident into the chat. you're saying this subject has an assurance method of level two. That that doesn't really make any sense to me. Um and so there would have to be some additional modeling. And I think what we would be trying to say would be this subject was authenticated by this party at this date and time to this level. And that's something totally different. And I don't know that that's something that that doesn't seem like it's even hitting the use cases that I would have in mind for this where I just want to make claims about a subject and by the way verifier if you want to know this is self asserted evidence but I checked this person to this
<Benjamin_Young> x
<Benjamin_Young> can we put that in the invite?
Joe Andrieu: Yeah. So I think it's I think it's easy to construct a definition of assertion method um that supports that argument. Dave, I would define it differently to say that what that uh subject assertion level IL2 means is subject had this level of assurance established at the time of this credential. like you're you're it it is a statement by the issuer about this subject and it you know what how it maps semantically to English is you know word smithing that we could tease out. Go ahead
Manu_Sporny: All right. So I just put this in chat.
Joe Andrieu: man.
Manu_Sporny: I have been completely thinking this property goes somewhere other than it actually goes. So assurance method is a top level thing that can go on any subject. Is that correct?
Joe Andrieu: Um no. Um but also what you what you said was paradoxically impossible.
Manu_Sporny: always the
Joe Andrieu: Top level things are to the VC. Evidence is top
Manu_Sporny: subject. I mean I mean like you've got a subject and assurance method is it hangs directly off of subject or does
Joe Andrieu: level
Manu_Sporny: assurance method hang inside confidence method like where does the property go? I was thinking like either confidence method Okay.
Joe Andrieu: inside subject. Yeah,
Manu_Sporny: All right.
Joe Andrieu: that disappear that you could you could provide a confidence method which lets a verifier do some additional things
Manu_Sporny: Uh okay.
Joe Andrieu: to increase their confidence that the subject is the subject identified in that statement. And the assurance level is a statement that hey this subject is in this statement um we had achieved this assurance level before we made this statement.
Manu_Sporny: Yeah, I don't think I like that. Um I I like that much less than I thought it was in inside the the confidence method. Um, that's
Joe Andrieu: Okay. Um, uh, it's actually a good time for the momentum of the conversation to wind down. So, um, I have some notes that I'm just going to put into this uh, PR, which I've been sharing off and on on screen. Um, clearly we need to elevate this to uh, I guess the rest of the group and and Phil, I'll follow your lead as to when and how we might want to do that.
Joe Andrieu: Um, any other actions? Like I think for this PR, um, can we proceed just with the issue marker? Um, and that would let us get an example in or I could update the PR so it has more in it. Um, but I think I'd like to get it in unless people are opposed to that and Okay. So, let me add here with that issue marker. We can merge and I will say add example. Add an issue to add examples. And I'm pausing for anyone to uh speak up that maybe I didn't capture that, but I'm seeing mostly thumbs up from folks. Okay, Denin, do you have anything else you want to say before we wrap
Denken_Chen: Yeah. No,
Joe Andrieu: up?
Denken_Chen: at this moment I agree this needs further discussion on this. Yeah. Thank you.
Joe Andrieu: All right. Excellent. Well, thanks everyone. I appreciate the robust discussion and um we will we will advance this forward and also advance that conversation forward. Thank you everyone. We'll see you I think uh in two weeks we're back. There isn't a main meeting in between that
Phil_Archer: Correct. I don't think so.
Joe Andrieu: window.
Phil_Archer: No, I think we're okay for now. But as I say, Brent and I to be spoke to you to be speaking Friday, so we will come back to everyone with at least some sort of plan. I hope so. Anyway, that's that's my hope for my Friday conversation with him.