Meeting minutes
Manu_Sporny: Hey Todd, good to see you here.
Todd_Snyder: Yeah, finally glad to be able to join you guys.
Manu_Sporny: Long time no We're going to get started in about two to three minutes. We usually give people a little bit of time to jump between meetings.
Manu_Sporny: All right, I think we've got a healthy enough group to start here. welcome everyone to the July 7th recognized entities task force call part of the verifiable credential working group. reminder to everyone that the calls are recorded and auto transcribed by our AI overlords. the minutes get published to the mailing list later on tonight. if you are not okay with the meeting being recorded, please let us know. but we tend to not have issues with that these days.
Manu_Sporny: We do have an agenda today. we have been over the past couple of weeks talking about some additions and changes to the specification to make sure that we meet the use cases that the supply chain industry has. so these include input from GS1 and digital anchor work as well as other items. we have some poll requests to look at today regarding that stuff.
Manu_Sporny: We are also trying to make sure that we get into candidate wreck sooner than later which means that we need to do horizontal reviews and all that kind of stuff. So that's what we're very busy doing. and we're making really good headway on that. So, we've got multiple issues, that we can review today, get general input from folks, and then, figure out, where we want to go, next week and the week after and so on so forth. So, that's the agenda today. It's going to be a lot of review over work that's been happening, pull requests and issues and things of that nature.
Manu_Sporny: all in our quest towards candidate Let me pause there. Are there any other changes or updates to the agenda? Anything else folks would like to discuss today? Phil,…
Manu_Sporny: please go ahead.
Phil_Archer: Just very quickly,…
Phil_Archer: just a quick shout out to Todd who's with us today. Todd will introduce himself. He's from GS1 my colleague there. which is great because it means I can keep my co-chair hat on and don't need to wear my GS1 hat cuz Todd will.
Manu_Sporny: Brilliant. …
Todd_Snyder: Yes. Yes.
Manu_Sporny: yes, welcome Todd. Please quick intro on
Todd_Snyder: I've worked with some of you before. yeah. So, I represent GS1 Been working with our verified credential solutions for about five plus years and looking forward to contributing to the group. Thank you.
Threat Model Integration
Manu_Sporny: very wonderful to have you here. all any other front matter we want to discuss before we get started with our agenda? All right. If not, let's go ahead and jump into it. I'm going to u highlight some threat model stuff. So as folks know we have been working on a threat model for a little bit. We talked about it at the face toface meeting. we got updates. There was a couple of folks took a look at it. and then I merged the first version of that over this past weekend. So it is now integrated into the specification.
Manu_Sporny: And let me go ahead and share my screen. this does not mean we are done by any stretch of the imagination, but it means that we have a firm basis to kind of move from. some of the editorial changes that I made was we used to have a security considerations and privacy considerations section of the specification. All of the items in there got moved to the threat model. they were all issue markers saying we are going to get around to a threat model. We're going to talk about security considerations. All of those have been expanded upon in the threat model and those sections have been replaced with this threat model section in the specification. so instead of security and privacy considerations, we now have a threat model section.
Manu_Sporny: If you go to the threat model section, it says this is a general threat model for this spec including security considerations, privacy considerations, market compos competition considerations and please go read the verifiable credentials threat credentials data model it security and privacy considerations before you start reading this document. So then that's a standard disclaimer that we have in many of our extension specifications. Joe and Kevin actually Joe's not here. So Kevin just a heads up maybe to make sure that Joe knows about this there is kind of an index of threats that we have in the threat model section where we identify the threat.
Manu_Sporny: We identify the class of the threat and then we have a one-s sentence description about it. And if people want to learn more about it, they click on the threat and it takes them to the threat model that specific entry, talks about the threat in more detail, talks about responses, talks about which components are affected, talks about the threat taxonomy and so on so forth. So everything is cross-referenced at this point for target threats, implementation threats, external threats and dependency threats. So that is how we have weaved it into the specification to date. I'm semi okay with it. I'm actually fairly happy with it.
Manu_Sporny: it's a good index and it takes you to the details and doesn't bloat the specification by an enormous amount like the security and privacy considerations sometimes do in some respects. so that's just a heads up like that's out there. It's published as an editor's draft. right now,…
Manu_Sporny: let me pause to see if there are any questions, concerns, comments on this approach.
Kevin_Dean: I'll pass that on to Joe.
Kevin_Dean: I'll let him know about it. Manu Sporny:
Manu_Sporny: Okay, thanks I think he'll be okay with it because there was some code the thing that changed Kevin is there was code to autogenerate this list and I did that and when I was reading through the spec I was like people don't really know…
Manu_Sporny: what on unauthorized issuer spoofing means or abuse of recognized action means and I thought it'd be useful to have a sentence that explains it at a high level so people know what they're getting ready to click on and go to.
Kevin_Dean: All right.
Manu_Sporny: Yep,…
Kevin_Dean: We might want to look into the autogenerator being able to pick up the description from the source as well.
Manu_Sporny: exactly right. but I think the cross referencing worked fairly well and it takes you to here and this is the first cut at the threat model document with the DFD which does need to be updated I still need to update that but dictionary and the key stakeholders and then the threats right so this is the autogenerated table of contents for all the threats in the threat model and then you can go down into specific threats and the flow it's associated with and that kind of stuff. so that's out there. and the suggestion is that this is the thing we are going to point the security and privacy groups at.
Manu_Sporny: So before we'd do a horizontal rec request and we'd say, "Hey privacy people, here's our privacy consideration section. Please read that." And hey security people, here's our security consideration section. Please read that. instead we're going to tell both groups we have a unified threat model. Please take a look at it. we do tag things as a security threat or a privacy threat but as we all know sometimes those go hand in hand where a security threat will lead to a privacy issue and vice versa.
Manu_Sporny: So that's a new structure that's the thing I think we were asked to do and we have done it and we will see how it goes. all right any other questions comments on the threat model or how any of this stuff is set up. And then of course please take a look at it when you have a moment. I think Phil, you had volunteered to take a run through the threat model. just let me know…
Phil_Archer: Thank you for reminding me.
Manu_Sporny: what you think as you go through that. no problem. It'll be some nice bedtime reading. it is a big document. okay.
Recognized Entity Use Case PRs
Manu_Sporny: If there are no more comments on that, let's go ahead and move on to pull requests. we do have Let me see. Recognized entities. one second. The preview is not working. for a reason where we know why it blew up. But let me get a preview on screen for we have u four pull requests.
Add "display information" and "credential type" use cases. by msporny · Pull Request #93 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: This one is blocked due to an active discussion in the VC working group about the digest SRRI property. this PR PR93. So let me topic this one is about adding the two use cases that were missing. So, Steve Capel, went in, thank you, Steve, and added, the crossber trade and product conformity, use cases. one second, let me get this PR adds two more use cases around education and vital records.
Manu_Sporny: primarily to add the first two that we had talked about. One of them was Dimmitri Zagad MITDC's use case around I want to be able to list the information that someone with a verifier wallet should show on screen for a college diploma icon for the university legal name of the university their website contact phone number so the very basic use case. And then the other use case was you've got a industry body and it wants to publish the list of all known issuers of a certain type of credential. so just real quick going to this use case. this is the education use case.
Manu_Sporny: It's just a paragraph about a national education authority wanting to publish the set of universities and colleges that it recognizes as legitimate institutions. and specifically it wants to enable digital wallets and verifier software to display that issuer along with their university name, logo, website in a way that's cryptographically verifiable. So nothing about what they issue or any of that. It's just like this is display information for this organization and contact information for this organization.
Manu_Sporny: The second use case is a vital records use case which is basically you've got a national association of vital records agencies. and they want to and that entity that association wants to say these are all of the vital records agencies that can issue birth certificates. and so it builds on kind of this first use case but in the second use case it is very specific about the exact verifiable credential that they issue and the schema that they issue too. So that is the validation schema part of our use case and then there's the crossber use case that Steve added here as well as the product conformity one.
Manu_Sporny: those remain unchanged of course. So is just those two use cases there. Let me pause there. I think these were just missing and they've been added. but let's pause to see if anybody's got any other comments or concerns on this item. should be pretty straightforward. We do need reviews from folks. Just take a look at it. see if it makes sense to you and then we will try to merge the next two poll requests are much bigger.
Manu_Sporny: These are the ones that are what I hope are the GS1 UNCCE UNP digital trust anchor use cases as well as Stephen who is use case and Stephen and Steve the use case around using who is to discover u a recognized ized entity credential. So the credential based discovery the recognized entity credential is delivered at the time when the holder presents a product conformity credential to the holder also prefetches the recognized entity credential and delivers that at the same time.
Manu_Sporny: So the verifier doesn't have to go out to the internet and fetch it. They can just use all the information the holder provided to determine whether or not that's a legitimate, product conformity documentation. The second one is what I'm calling just identifier based discovery which is where the holder just hands over a credential to the verifier. The verifier has no idea who the issuer is like they don't recognize it.
Manu_Sporny: But in the credential it tells the verifier where it could go to get the list of recognized entity credentials and how it might be able to link it to an issuer that it does in fact trust like a national body or an international body of some kind. but the way that happens is that it just goes based off of the issuers's identifier on the document. and then it goes to the issuer's identifier and on the issuers's identifier who is service and then it looks up the recognized entity credential from there and goes from there.
Credential-Based Discovery PR
Manu_Sporny: So, we're going to go through these two, at this point. So, let's go ahead and jump into the first one. Let me topic this. and let me go ahead and check this out on screen. So let's see this is credentialbased discovery.
<Dave Longley> perhaps "issuer-identifier-based" would be more clear
Manu_Sporny: So what this PR does is it adds a new algorithm section. and there is a based discovery section here that it details. but for this one what we have done is in the recognized entity credential for the issuer property we have said the issuer property can have a recognized in property as a part of it. So let me go down to here to show what this means. So this is a bog standard verifiable It's a BCDM2 credential. Here's The issuer is a university but this thing is new in here. Right? So this is the issuer.
Add section on credential-based discovery. by msporny · Pull Request #94 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: when they issued this credential they're like if you don't know who I am I am recognized in this list and so you can go there and see if you trust the issuer of that list and if you don't trust the issuer of that list that issuer says where they are recognized in and you can go to that other list and so on so forth so this is effectively the GS1 use case I believe so please correct me if I'm wrong about that Phil or Todd Kev I think this is how we get to the G use case, how we get this technology supporting the GS1 use case. the other parts of the pull request it's a description. Sorry, let me go over here. There's an algorithm section. It basically explains what I just said, right?
Manu_Sporny: you get a credential. If you don't understand who the issuer is, you see if the issuer is recognized in any list and you go to that list and see if you trust that whoever issued that list and so on and forth up the hierarchy. and then there is an algorithm that basically tells you that highlights what I just said which how do you look for this thing? how do you discover who the issuer is? And then that's followed by an example here which we just took a look at and then an explanation of the example and that's all that that PR does. But let me pause here questions, comments, concerns. go ahead, Dave.
Dave Longley: So on the last call for which you weren't present we noted that you could add a type property or an additional type if there was already a type property in your issuer field with a value of recognized entity and by doing so it automatically brings recognized in property into the issuer field. So we already have a compositional way of doing this. So we don't have to make a special call out that says a recognized end property is defined under issuer. which I think might be challenging thing to do anyway compositionally. so a tweak to this PR would just be to call out in the issuer field that the issuer can have any number of types that you would like. One of those types can be recognized entity and when you do that you get the recognized in property.
Manu_Sporny: Got it. So the delta to the PR would add one line here type colon recognized entity and then you get this and…
Manu_Sporny: you go from there.
Dave Longley: Yeah. And…
Dave Longley: then tweak the language around issuer so it doesn't seem like we're special we're defining a new recognized in property just for issuer. Yep.
Manu_Sporny: Got it. So, it would basically like you could have all of these things in there. I can definitely make that modification. any other highlevel because I wasn't there for the discussion.
Manu_Sporny: Any other highle changes we can think of? go ahead Steve.
steve: Just a question on cardality.
steve: How many of these recognizings can I have under one issuer?
Manu_Sporny: You can have a list.
Manu_Sporny: But that's a really good question. you could have as many as you want, right? Yep.
steve: Yeah. Yeah. Because I might want to say I'm recognized in this list and that list in the context of this credential. Yeah.
steve: Okay. Manu Sporny:
Manu_Sporny: Exactly right. Yep. and then of course all the verifier needs is it just needs to see you in one of the lists that it recognizes.
steve: That's all. Yes. Yeah.
Manu_Sporny: Yeah. Yeah.
steve: I just asked cuz I didn't see an array bracket.
Manu_Sporny: Okay. Yeah.
steve: Just an object bracket.
Manu_Sporny: In general anything in JSONLDD can do an array bracket for any property here. there's some corner cases…
steve: Okay.
Manu_Sporny: where that's not true, and large, yes, you can always have sets associated with any property. but it is worth pointing that out. So I will definitely do that in the update to the PR. and if you and Dave don't mind, adding these as comments to the PR, that'll help me remember before I merge.
Manu_Sporny: Go ahead, Awesome.
Dave Longley: My type comment is in the PR,…
<Dave Longley> oh "credential-based" seems like it needs a better name, but i don't have one to offer.
Dave Longley: so you'll see it. I'm trying to remember…
Manu_Sporny: Thank you.
Dave Longley: what I was about to say. no, forgot it.
Manu_Sporny: That makes the update easier.
Manu_Sporny: Go ahead, Todd.
Todd_Snyder: Yeah. …
Todd_Snyder: this is the first time I'm looking at this stuff, so might seem a silly question to ask, but what I'm seeing here, it says the type is a recognized entity credential. That's saying that there's a credential at this ID the university JSON would be a type of recognized entity credential.
Manu_Sporny: Yep, you got it.
Todd_Snyder: And that would have something that would tell you that this issuer belongs to that authority. am I understanding it correctly? Okay.
Manu_Sporny: Exactly right. Yep. Yep. Yep. Yep. You got it. So if we go up here, the recognized entity credentials basically look like this, So this is a recognized entity credential and the issuer is someone that is some authority, So this would be like a GS1 u national body or could be the top level GS1 thing and then the credential subject would be every organization that entity recognizes right so everyone that you've issued a GS1 prefix for example go ahead
Manu_Sporny: You might be muted.
Todd_Snyder: Yeah, we can hear you.
Phil_Archer: I'm walking the dog, so I can't really actually see the screen, so forgive me. I thought I wasn't muted. No, I should be unmuted. You should be able to hear me.
Manu_Sporny: No, no,…
Phil_Archer: No. Okay.
Manu_Sporny: you're there. You were just breaking up a little bit.
Phil_Archer: Yeah. Am I walking the dog? Sorry. so I think a question that Todd and I will take offline is listening to this which is great. it doesn't include one feature that I can see anyway that I've heard you say Manu which is in the GS1 case that this recognized entity is allowed to issue numbers beginning 1 2 3. Now I'm in my head balancing that against the desire that there is no need for any special GS1 code at all.
Phil_Archer: And I think it's more important that there's no need for special GS1 code rules and that it strictly adheres to our model of this particular bit of GS1 credentials beginning 1 2 3 and then they issue you licenses 1 2 3 4 5 6 and so In other words, this is a question for Todd take offline I know but I'm starting not to care about that detail because I think the important thing is that the issuer is recognized by the relevant bit of GS1. So that's a thing we're going to have to think about.
Manu_Sporny: All right.
Phil_Archer: In other words, are we going to come back and say, "No, no, we need to be able to extend one credential to extend another." Or is that actually worrying about something that doesn't really matter very much? Okay, I'll stop there.
Manu_Sporny: I've got good news for you, Phil, but Dave's on the queue. Go ahead, Dave.
Dave Longley: So two things. First one is we don't need a block for this but I do think we need a better name than credentialbased for this since everything is credential based. so we'll want to come up with that. to briefly respond to Phil, if these product VCs in them have that number, then when you check the recognized entity list and you go to it, the entity list can itself say that the given issuer is recognized to issue cred product VCs and it can have a JSON schema that can highlight which numbers would be allowed to be
Phil_Archer: right?
Dave Longley: So any implementer of a JSON schema validation library, any JSON schema library, you could run it and you can run essentially arbitrary JSON schema for any of these use cases. So it wouldn't have to be GS1 specific. We might have to put some kind of specific guard rails around some kinds of JSON schema since you can do things like reg x dos. So, we'll have to sort that out. But, I would think that this would cover that case.
Phil_Archer: Yep. Thanks, Dave.
Manu_Sporny: It's one of that. Phil, you're first on the queue, but that might be an old hand. there's Todd is on the
Todd_Snyder: You were said you were going to have a solution for a problem.
Todd_Snyder: No I mean I needed to digest all this but I think it's on the right track. We just need to figure out how these connect and actually work out a real world use case. But I think I'm following with the concept. I'm just not sure if they fit every case of our credential chain.
Manu_Sporny: Plus one to that. we do want to run every single GS1 credential through this scheme to make sure that it works. But I think it works right now. So, I think the good news is exactly what Dave said. there is a generalized mechanism we believe to achieve the GS1 use case and that generalized mechanism is in the recognized entities list. the national GS1 office I'm totally blanking on the name GS1 uses for that.
Manu_Sporny: It's the local what is it? Thank you.
Phil_Archer: member organization.
Phil_Archer: Member organization
Manu_Sporny: The me Thank you.
Manu_Sporny: me the member organization for example GS1 US would say these are all the entities we recognize and for this entity we recognize them to issue this type of product thing and when they issue it the prefix that they use has to be this and it matches directly
Manu_Sporny: in the JSON schema. So I do think one we specifically support that use case and…
Phil_Archer: All Yeah, thank you We're working on it.
Manu_Sporny: it is not specific to GS1. It's a generalized solution.
Todd_Snyder: Makes sense.
Manu_Sporny: Okay, So we have to test the theory by running your credentials through it, but we're expecting it to work hopefully.
Phil_Archer: We're working on it.
Manu_Sporny: All right. So, that is the badly named credentialbased discovery. as Dave mentioned, we would love folks to bike shed some alternate names on it. Kevin, go ahead. You're on the queue.
Kevin_Dean: Yeah, just to clarify the recognized in is something that takes place at the verification layer. It's the linkage between credentials whereas any constraints that are placed on recognized in such as within the TS1 use case restricting the range of identifiers that a company can issue that is in the validation phase that's a business rule that applies to that particular type of credential. these are discussions we had in the past few weeks over this that we're looking for as much generic support as possible in the verification phase but there will always be business rules in the validation phase that will further constrain what verification can do.
Manu_Sporny: Yep, exactly so that is a PR that exists today. please take a look at it and, suggest any changes you'd like. I'm not super thrilled with the algorithm. I think it could be nicer and cleaner. so just keep that in mind as you're reading through it. If you can think of a better way to kind of express the algorithm, or other things the algorithm should be doing or keeping in mind, please please suggest it. go ahead, Dave.
Dave Longley: I didn't think we should bring this up before merging the PR, but I just say it out loud on a call. Sometimes it's better to have these algorithms do things like check your issuer chain all the way up before applying, and this might be related to what Kevin was saying, before applying these validation rules. it would help you avoid doing things like doing a bunch of validation rules on a chain that is wasting your time that never gets to trusted anchor. So there are some considerations around the best way to write that algorithm and we can sort that out
Manu_Sporny: Plus one to that. the other weasel word language that we usually put in specs around algorithms this is just one of the algorithms. You can do it however you'd like as long as the outcome's the same. so we want to make sure that people know they are not expected to take the algorithm literally and only implement it one way. They can do whatever they need to from an implementation perspective to protect against attacks like you just mentioned Dave. so that isn't in here yet either and it needs to be at the top of the algorithm section.
Identifier-Based Discovery PR
Manu_Sporny: we need to say any implementation that effectively does the equivalent of the algorithm is considered conformant. okay, that's it for that the other PR is on identifierbased discovery which might also be equally badly let me go ahead and get this one on screen in identifierbased discovery layers on top of the credentialbased discovery thing we just talked about.
Manu_Sporny: So the only thing it adds is this section that says hey you might not even get a recognized in the issuer might not even give you a recognized in property right and if they do that then one of the things that you can do if it's a controlled identifier document or a decentralized identifier document you can just go to the issuers's did document
Manu_Sporny: and you can look in it to see who is service and if who is service you can go there to see if they have a recognized entity credential there right so I at least know the issuer's identifier I'm going to go out to the internet dreference it see if they have anything that announces who they are and if they are I'm going to go and I'm going to fetch that thing it's a presentation of verifiable credential. I'm going to handwave over that right now. But when you retrieve that, you're expecting that maybe there's a recognized entity credential in there. and if there is maybe it identifies the issuer and then as the verifier you can get p assurance who that entity is. go ahead Dave.
Dave Longley: Yeah, not that the language in the PR says all these may but we might want to say ecosystems are expected to def to define and require this behavior if you want to interoperate in those so in ecosystem A you'd say make sure you publish this recognize entity credential through this who is service or people will not be able to resolve your stuff.
Manu_Sporny: Yep. Exactly.
Dave Longley: And maybe the better name for this one is issuer identifier based. That one seemed a little more obvious than a name to suggest for the other
Add section on identifier-based discovery by msporny · Pull Request #99 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: Yep. Let's go into that. yeah, I can update the description to issue identifier based discovery and of course plus one to what you said. So, Steve Capel, I think what this, means is that, the work that your, group is doing would basically say hey, you need to make sure that, if you want broad discovery of who you are, this is one way to do it, right, is through the who service.
steve: Yeah, I think it's not obvious to me when to use which, I can imagine an invoice being issued with a recognized in that points to a business registration not in the issuer did, but I can equally see it this way. And I need to think a bit about do we make any recommendations on our side about best practice when you should use which or do we just say there are two ways to do this and look at both right bit unsure of that I know there's a little discussion about should it be a VC or a VP at the other end of who is I don't actually have strong feelings about it the only reason I questioned it is
steve: because sort of everywhere else in the architecture in trade there's a discovery pattern of credentials not presentations right so I find a product ID and I resolve it to a product passport I look in the product passport I find a facility ID I resolve it to a facility record and this pattern and it's very similar to the credential-based discovery right I find an ID there, I resolve it. So there's just this pattern throughout the whole architecture of resolving identifiers to credentials and this would be the only place where you resolve an identifier to a presentation and great issue with that.
steve: just I'm wondering what impact it has on the likely operate operationalization if you like of this particularly for the small businesses that will be using some cloud software. So I'm imagining, a fiveman business, person business, sorry, running a finance system that offers this capability to sign your invoices and the business doesn't know what a DID is from a bar of soap and the finance system helps him create his in the context of that finance system. Then tells him to go to the tax office and do a certain thing.
steve: tax office creates a credential and I'm just thinking about the operation what a verifiable presentation means is that credential comes back to the finance system and then gets wrapped in a VP by the finance system and then I can imagine the same business may be in another context wanting to say not only am I this business but I'm also accredited by the National Accredititation Authority as a conformity assessment body or something, an auditor. you'll now need to take both of those credentials and know to wrap them up in a VP. And again, I'm not sure there's any problem with that.
<Kayode_Ezike> Probably should prioritize checking for the recognizedIn property, since it is a unique and explicit signal
<Kayode_Ezike> And if that’s not there, you can check the issuer ID
steve: probably need to think about the detailed sequence of steps when you've got a small business using a system going to two different authorities and are there any sort of workflow blockers not really blockers but complexities that would slow down uptake and I admit I don't know the answer to that have to think about it a bit so I'm not objecting to the use
steve: of a VP just wanting to think through the logistics of it if you like in a industry or an area where generally there's very few verifiable presentations. It's all about linked credential discovery. it's sort of a little out of pattern that's all but yeah I can't say more than that at the moment.
Manu_Sporny: No, I appreciate the yeah,…
steve: The inut
Manu_Sporny: input so far. Dave, you're on the queue next.
<Phillip Long> Isn't the VP an emphemeral transport mechanism to encapsulate the sending of multiple VCs? It offers an additional identificaiton of the sender of the package but isn't a "thing" itself.
Dave Longley: Yeah, I could respond to that. I have thoughts there, but I got on the queue to say I would actually recommend that this group suggests that who is approach is the better approach. And the reason for that is that it decouples all of this from whatever VCs you're issuing, which is advantageous in a number of ways. you don't have to updating your VC schemas or whatever to con consider or allow for the recognized entity type to appear in the issuer field. That may or may not be something you can do easily.
Dave Longley: It also allows after updates to who is service can happen independently from the VCs you've previously issued which allows you to add new VCs update them do other things or there are a whole host of things you don't have to be as worried about and that you are free to improve without worrying about existing VCs that are in the ecosystem whether or not you need to reissue those and So that decoupling and dellinking I think is a cleaner approach. And then we can say if you're not able to do that you can integrate these things directly into your VCs but you will have the drawbacks that I just mentioned.
Manu_Sporny: Yeah, I mean certainly plus one to that. we don't have enough implementation experience to know which one of these is better than the other. I think that we can reason through them. certainly and put that reasoning in the specification. and it may very well be that what Dave said it is much more loosely so one of them is more loosely coupled than the other one right the recognized in the issuer field is a little more tightly coupled.
Manu_Sporny: it's more explicit and then publishing this information at who is more loosely coupled and things can and that has its benefits as well. it also I think kind of presumes that the entity has a presence online where that might not be the case. so there are a lot of pros and cons to this. I would be surprised if we could get to a concrete set of understanding on when you use one or the other. But that's good that's good it is work that we identify and we know we need to do. I think the most important thing is none of us are saying one of these is bad and the other one's clearly bad and clearly good.
Manu_Sporny: But I think it's like we've got two approaches here and we'll need to puzzle out when you use one versus Steve to your question on versus VP. one of the benefits of doing a verifiable presentation is it does allow the subject or the holder to sign a presentation so it can be replayed elsewhere. Me meaning someone can say yeah this is a set of credentials that the subject had and they published it online and this is a
<Dave Longley> maybe pros/cons could be put in the spec
Manu_Sporny: fairly fresh signature. and that is a way that public information can flow between systems without that that being a part of that transmission. there are downsides there as well people can forge your information on without your consent and that can be good and bad depending on the use case. So, plenty to consider there as well. so Steve, all I'm trying to say is you're not alone in wondering which one of these is better than the other. we're going to have to kind of work through it. Phil, you're next on the queue. please.
<Kayode_Ezike> Agreed with Dave. I guess the question is more about the guidance to give to VC consumers, not the VC issuers.
Phil_Archer: I'm doing the Sorry.
<Dave Longley> i have a natural inclination to propose loose coupling as "better", but it's not always true/easy to do.
Phillip Long: I was just sorry. Phil Archer,…
Manu_Sporny: Sorry, Phil Long,…
<Dave Longley> agree with Phil that a VP is just a wrapper that allows for authentication and the delivery of multiple VCs (if desired)
Phillip Long: did you No worries.
<Ted_Thibodeau_Jr> consumers a/k/a verifiers
<Kayode_Ezike> Right
Manu_Sporny: not Phil Archer. for long.
Phillip Long: I was just responding to Steve's comment because this is a common concern that recurs in the environment. and unless I could be naively mistaken here, but the VP doesn't persist other than as a mechanism for transporting a credential set. it could be enclosing just one credential but the intention of it is to provide a mechanism to be able to put together a set of credentials that may be from the same issuer or multiple different issuers depending on the use case and it provide the added value that you mentioned Manu which is that the person who is making that VP can sign it and at least where
Phillip Long: the providence of that package came from and make your decision about how important or not that might be. but it doesn't persist after the transport. So it's always confused me that we have this sense of it being very different from a credential because ultimately it is just a package of them and when it arrives you get dumped the package individual credentials one or more however many they put into it. So, I just wanted to I could be wrong and I could be, needing some, better understanding, but that's my current view of this. and I don't see the VC VP as a meaningful distinction other than to ex explain that the function has this value added to it. Thanks.
Manu_Sporny: Yep. Thank you.
steve: But it persists in storage,…
steve: Obviously, I mean, it's the difference here is most VPs in my experience are they're created, if you at presentation time. Somebody says, "Give me this information." I go, " here's a presentation." And you're right, it's a bundling and a dynamic kind of persists for the conversation. In this ca, that's not the case here, right?
steve: this VP could exist for years because it's assembled at sort of creation time abstract of any request and stored and then somebody finds who is endpoint pulls the VP at that point it's just a carrier and you pull out the VCs inside it that's true so it's a slightly different pattern to my normal understanding of the use case of a verifiable presentation right? Because it's not created at presentation time. It's created potentially years earlier. And also you got to recreate it every time you change you have a different combination of recognized entities. Anyway,
<Dave Longley> a VP is primarily for 2-party use; a VC is primarily for 3-party use
Manu_Sporny: Yeah. Yes. so that is true. it is different in that sense. So, Phil Long, you're absolutely right. one of the benefits of a VP is you can have a set of credentials that you move across any arbitrary set. but it does not disappear necessarily. you can make it disappear, you can put time limits on it and all that kind of stuff. But what Steve is saying, Steve Capel is saying can also be true. last for years. It could be downloadable and for forwardable that is a capability of the entity that's creating the VP as Dave said it can be created dynamically when the request is made or it could just go into long-term storage and sit there.
Manu_Sporny: So there are many different ways that this could be used and again we haven't explored that space I don't think before. real quick because I do want to get to a couple of other issues and items. This PR is out there if folks want to take a look at it. Again it's got an algorithm in it it's a start. it definitely needs some work. if you have any additions to the description of it, please provide those in the poll request. So looking forward to more reviews as we go. Okay.
<Dave Longley> a whois.vp endpoint could create a VP at presentation time.
<Dave Longley> (at request time)
Horizontal Review Readiness
Manu_Sporny: last set of things that I wanted to mention with the threat model in place and I believe these last two kind of features in place. I took a look through our issues. There are still some that we need to get to, but I think we're ready for remember horizontal review can be kicked off when you have just two paragraphs in your specification and that's it right. the horizontal review we're seeking right now is we think we've got the general shape of the specification and if these PRs go in we've got the general shape of the specification and we would like privacy and security and tag review on what we've written. It can take months to get that which is why we're trying to kick it off.
Manu_Sporny: One of the things that you need for those horizontal reviews is you need to do a self-re specification. you need an internationalization one, you need an accessibility one, you need a security and privacy one and then the tag kind of uses a combination of those things along with stuff you fill out in the questionnaire for them. And that's how you kick off the horizontal reviews. I have created a horizontal review tracking issue. We have not requested horizontal review yet. So there are five groups we need horizontal review and I have done the security accessibility and internationalization self- review for this specification.
<Phillip Long> Thanks for the clarification as I had thought the value prop was not associated with VP persisiting.
Manu_Sporny: So the security and privacy questionnaire has a big long list of information feature Why do you expose it? are you exposing a minimum amount of information? do you deal with fingerprinting. how does the information persist across browser sessions? Do you use device sensors? all kinds of privacy things. And so for each one of these, there's a response and we specifically point to the threat model. We say so for example, do we deal with sensitive information? Why yes, we do.
Manu_Sporny: And we specifically talk about those things in external this thread 11 and thread 7 for do you do script execution no we don't except we do use JSON schema as a part of our spec and there's a specific attack that we're concerned about and we talk about it here and how to mitigate it and so on so forth Right. So that's the security privacy self-review. Same thing for accessibility. Do you render visual content? Do you allow the author control over the colors that are shown up on the screen? And for most of this stuff, we say but for things like do we allow text content? yes, we do.
Manu_Sporny: We allow people to specify what the name and description of an entity is the description of the university, the legal name of the university. So we allow those things and we need to make sure that those things are accessible to people. so we have a big set of responses here ready to go. And then internationalization is the same thing, How do you ensure that there's enough metadata in the credential to support things like native language and the text direction? and good news here is we depend on JSON LD which has those things built in. So we respond in that way and we say whether or not certain things in their checklist are applicable to us or not and if they are applicable we tell them yes we thought about it.
Manu_Sporny: Yes, this is where we, talk about it in the specification and so on and so forth. So, all of those things are ready to go and as far as it would be good if someone else in the group or multiple other people in the group reviewed each one of these things. so we'll be looking for folks to volunteer to take a look at these things before we request horizontal review. but if we pull in the PRs we reviewed today, next week or the week after, and if people review these issues to make sure that what we're saying about the spec is accurate to the degree that you think.
Manu_Sporny: then we can kick off the horizontal review I think within the next two to three weeks. All right. we are out of time today. Any quick thoughts or comments on that before we end the call? we'll continue discussing this next week. I unfortunately will not be here. but I think Benjamin will be running the call next week to move folks through. any other comments, concerns, trepidations on any of that stuff?
Manu_Sporny: Steve, I'm gonna leave the PRs open just to make sure that people have the chance to provide comments and follow our standard merge process which requires around seven days of review.
steve: Okay, and thank you for the work.
Manu_Sporny: Yeah, no problem. Okay. thanks everyone. have a wonderful rest of your week, a wonderful weekend, and we'll have the call again next week, and I'll see each of you again in two weeks. Take care.
Phil_Archer: X bay. Meeting ended after 00:59:04 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.
Call Wrap-up and Thanks
<Dave Longley> big thanks to Manu for putting this together!
<steve> Should we merge the PRs now?