Meeting minutes
Joe Andrieu: Howdy, folks.
Scott Jones: Hi. Very well.
Joe Andrieu: How you doing, Scott? All right.
Scott Jones: How about you?
Joe Andrieu: Hey, Lane.
Elaine_Wooton: Good morning everybody.
Joe Andrieu: Where in the world is Elaine Wooden today?
Elaine_Wooton: I'm sitting in my house in Gaithersburg, Maryland. Perfect.
Joe Andrieu: Lovely. How'd you like GDC?
Elaine_Wooton: GDC was great.
Elaine_Wooton: Yeah, it It was nice to see Scott there. Scott greeted me.
Joe Andrieu: Cool. …
Joe Andrieu: you went too Scott. How'd you enjoy it?
Scott Jones: Yeah. I enjoyed it.
Scott Jones: It's the scale of it versus I IW as an example was pretty remarkable. What was IIW like 300 people?
Scott Jones: Am I making that up?
Joe Andrieu: That's about right. So,
Scott Jones: This was 2,000 or 3,000 I think they actually said.
Elaine_Wooton: Yeah, it was hard to know…
Elaine_Wooton: who to connect with. And at some point I can't remember who it was, and I introduced whoever it was that I'm thinking about. to somebody I'd met that deals with product ID and the guy was on a script and I don't know jetlagged I don't know and he filibustered us for 10 minutes straight no break in so hard to know who to talk to yeah
Joe Andrieu: Right. Indeed. Hey, Phil.
Scott Jones: Got to use that filibustered. That's awesome.
Joe Andrieu: It's definitely a tactic that happens in these conversations.
Scott Jones: Yeah. Or an energy vampire kind of analog where they're just like I'm gonna attach to you.
Elaine_Wooton: Yeah. …
Joe Andrieu: Welcome, Den.
Elaine_Wooton: know who it was? It was Phil Archer. And this guy was lecturing Phil Archer about product ID.
Joe Andrieu: Yeah. Hey, that's D level mansplaining.
Elaine_Wooton: It was incredible. and Phil just standing there like nodding his head.
Add sections on cryptographic keys and controlled identifiers by msporny · Pull Request #43 · w3c/vc-confidence-method · GitHub
Scott Jones: Hey, heat.
Elaine_Wooton: It was great.
Joe Andrieu: Please tell me about product identifiers. Hey, Manny. Welcome. All right.
Manu_Sporny: Asia.
Joe Andrieu: I don't know that I'm expecting anyone else in particular, so I think we can go ahead and get started. Denin, did you have any thoughts other than looking at manage PR for today?
Denken_Chen: Yeah, I think we should look at that first.
Joe Andrieu: Okay, I do have some work to do on the data flow diagram that we got started on our last call. but it's really not mature enough to get coherent feedback. But I've been refactoring if you recall we had the bits about
Joe Andrieu: the livveness check server and the evaluator context and so I've been thinking through how we can resolve that but I don't know that it's quite ready to present yet today but let's go through that order so let's first look at manu's and then maybe we could see if there are other issues we want to pull up if we get through that today I does that sound good to anyone else have auggest suggestion for the agenda. thumbs up for Manu and e. go ahead, man.
Manu_Sporny: If we have time, I would like to spend a little bit kind of talking about Joe, and Denin need from us to make progress on anything else. I think we have any issues we need to talk about? just you asked for thoughts. I'm seeing a number of things that are not tagged issues that are not tagged with do we need discussion? Is it if there were more things that were ready for PR, I might be able to start tackling them primarily…
Manu_Sporny: because I think my work on recognized entities is wrapping up. So I have some spec editing time coming up. That's it.
Joe Andrieu: Okay, cool.
Joe Andrieu: So, that triggered two things for me, Manny. one maybe we can get to when we talk about issues, which is we should triage those and label them so that we can decide if we need more discussion or if they're ready for PR. and then I don't know if we've had any coherent conversations about test suite and how we want to approach that. I think we initially had some hopes that maybe we could leverage the VC test suite etc. but that's something we need to get concrete with and start moving towards resolution about how we're going to test these things. so I'll just put that in the queue as something we can talk about later.
Joe Andrieu: All Anyone else? So, I happen to be having a weird thing. I don't want to use all this time for customer support, but I cannot check out that branch on my local clone. The branch for your PR menu. I can see it live, but I wanted to see it rendered, right? And the PR preview has been problematic. So I was like, I'll clone it and I'll switch to the branch and, render it locally. but the branch doesn't check out when I try to do it. And I…
Joe Andrieu: if anyone has any lowhanging fruit,…
Manu_Sporny: Are you working off of your own branch?
Joe Andrieu: I'll try it because I would like to share the rendered version, but maybe I'll have to defer to someone else to do this screen sharing. Go ahead, man. Manu Sporny:
Manu_Sporny: Your own clone of the repo or the main one.
Joe Andrieu: So, I'm …
Joe Andrieu: that's a good thing to check.
Manu_Sporny: Cuz if you're not, maybe you just need to resync your local forked copy.
Joe Andrieu: Okay.
Ted_Thibodeau_Jr: to minimize the live tech support part.
Ted_Thibodeau_Jr: The preview issues so far as I know have all been resolved. So pushing a fresh commit to Manu's branch should get a rerendered thing. And so the extra checkout issue should be not a problem right now.
Manu_Sporny: And the preview for this particular one looks to be working for me as far as I can tell.
Discussing Guardian Of The Subject Phrase
Joe Andrieu: So, we'll use the preview and Manny, you nailed it. it was one of those kinds of are you plugged into the right port thing. So, my local clone was off of my fork. and so my fork doesn't have your branch, the main one does, right? So, thanks for that. so let me just share screen with my two files here. One on the PR preview and one on the PR All so, Manuel, I made a bunch of comments a couple of weeks ago. I saw you were able to get in and process that a little bit today. do you want to open us up with where you think we're at after your engagement this morning?
Manu_Sporny: Sorry it took so long to get around to it. I had just forgotten about it. until you reminded me yesterday and then I forgot about it until 15 minutes before the call. so I did take a look. I think I merged most everything. you had made specific recommendations for Joe. I did try to mix in some of coyotes like hey this isn't exactly accurate in a guardian use case concern that he had. So, I took your text, Joe. added a comma or…
Manu_Sporny: a guardian, text in there. and then I think that would address both Coyote and your concern, but please take a look through that to make sure it works for you.
Joe Andrieu: Which section is it?
<Dave Longley> "agent of the subject"?
Manu_Sporny: Just search for the text line 649. Yeah, there we go. That ora guardian of the subject is what I added because coyote was like it might not be the subject that has control over the keys. and I know we don't define guardian, but hoping it's self-explanatory Enough.
Joe Andrieu: Yeah, I actually don't agree with that framing. I'm not sure where we should resolve around it, but let's open it up for some discussion.
Joe Andrieu: My concern is that part of it is we don't define guardian. So it's unclear what that means either from a semantic or a technical perspective. but the meaning of the confidence method is so that you could have confidence that some party you're interacting with in some context. It could be out of time, A log file of a signature. So it may not live, but the party in question is the subject of that RDF triple.
<Dave Longley> or a "delegate of the subject"?
Joe Andrieu: And so if you have a VC where there's a guardian involved what you don't want to do is say that the way we have confidence in the child if we go with a parent child relationship just have a relationship to talk about there could be a confidence method for the child and that should be what the child controls and so a confidence method for the guardian should be attached to a subject that says this person is the guardian of that other of the child. and I think that is a clean way to get the semantics. And it feels like this is conflating the two. So I can't tell with the proposed language here whether or not the person satisfying the confidence method is a subject or just someone who is a guardian. and I have no mechanism to understand who decided that they're a guardian. Is it my state of California? Is it the United States of America? Is it someone else? etc. Go ahead, Manny.
Manu_Sporny: Yeah, I'm fine with that. I was just trying to align something with Coyote, but what she said makes sense to me. there's some other proposals in the chat. Dave is saying agent subject. Denkins plusing delegate but I think those create the same problem that you're concerned about Joe in that they're kind of like it's not the subject it is very much associated with the subject and subject in the RDF sense the confidence method and we are kind of like we don't care how that thing's exercised the presumption here is that there's an association with the subject so it's an abstraction I
<Denken_Chen> +1 to delegate, or represents the subject
Manu_Sporny: I think Joe is what you're effectively saying is how it's used is abstracted away. but ultimately we're presuming that that thing is associated with that subject in some way and is being used. So I'm fine with striking it. I wouldn't expect Coyote would push back too hardly based on the discussion that we just had. and I can do that now unless there are other people that are like,…
Manu_Sporny: "No, we really should talk about delegates and guardians." I want to avoid doing that because it opens a can of worms. Joe, as you mentioned,
Joe Andrieu: Yeah, plus one.
Joe Andrieu: Go ahead, Dave.
Dave Longley: Yeah, I think the public key has to be presumed to be minimally we don't have to put the word in there in the minimally minimum I can't even say the word has to be usable by that subject if something else can use it that's not necessarily even relevant here and that I think that goes to Joe's point…
<Ted_Thibodeau_Jr> A minor person doesn't delegate to their parent/guardian...
Joe Andrieu: Okay, cool.
Dave Longley: what you're putting in the VC is about the subject associated with the sub subject so that's what it has to be usable at least by that subject
Manu_Sporny: So I am putting in a change right now to just delete that a guardian of the subject phrase. So it will read, "The issuer records a public key presumed to be usable by the subject at the time of issuance proof of use." I'm fine with that…
Manu_Sporny: if everybody else is. And if you refresh,…
<Dave Longley> "usable by the subject" is a minimum bar, +1 to just leaving it at that
Ted_Thibodeau_Jr: I Yeah,…
Manu_Sporny: it should come up on screen. Joe, the Sorry,…
Joe Andrieu: It's going to take a while to build. I think this is preview. Manu Sporny:
Manu_Sporny: I didn't apply I just did the change command. It won't show up on that screen. It'll show up on the code preview, the GitHub code changes thingy.
<Ted_Thibodeau_Jr> "usable by the subject" is similarly problematic where the subject is a pet or a minor person
Joe Andrieu: Right. Yeah.
Ted_Thibodeau_Jr: it won't show up on the preview until it's speaking because my hand is usable by the subject is similarly problematic…
Joe Andrieu: Go ahead.
Ted_Thibodeau_Jr: if the subject is a pet or a minor person. They can't use that. There's another entity which could use it on their behalf But similarly to the problem of definition of guardian, I think we run into similar problems with definitions here.
Joe Andrieu: So, I actually think there use cases where you could have a pet who has a cryptographic key in particular if they have an not an RC chip, but if they're chipped,…
<Dave Longley> it's still even "usable" by a pet -- perhaps, for some definition of "usable", i.e., walking through a doggy door with the key embedded in their collar
Joe Andrieu: they could actually have a secure element and you could Right.
Ted_Thibodeau_Jr: You would agree that's true,…
Ted_Thibodeau_Jr: but you're not chipping your kid. I'm pretty sure. Sorry, I'm speaking out.
Joe Andrieu: But the point is that you can say things that are nonsensical and so you can put things in here that are not usable by a child. So you would not do that, I think, is my reaction. like I agree with you.
Joe Andrieu: If a child because they're 2 years old or whatever doesn't have their own cryptographic capability then you shouldn't add a confidence method that's going to let someone use a cryptographic method to have confidence in that subject Because they're isn't one that would satisfy the lema, if you will. Go ahead, David. I think you're next.
Dave Longley: Yeah, I was just going to say I think what you said, is logically consistent with what we were saying before that you would not put such a confidence method into a VC because it's not usable by the subject. we could have some language in there that could potentially be usable in the future by the subject. So, you're just trying to get ahead of it. And so you want to give someone a VC that has this confidence method for a minor who can't use it now but maybe in two years they can and that's maybe a use case but I think generally speaking the point is that is of the reason why you would not put that in to if it's not usable by the subject you would not put it in the VC except for that special use case I just
Usable By Or On Behalf Of Subject
<Manu_Sporny> what about "on behalf of"?
Joe Andrieu: there's an interesting So Dave,…
Manu_Sporny: I'm wondering if on behalf of would address your concern, Ted. So, we would change it to the issuer records a public key presumed to be usable by or on behalf of the subject at the time of issuance. Proof of use.
<Ted_Thibodeau_Jr> Us knowing it's nonsensical doesn't save the later reader/user of this tech from doing what they think is sensical.
Joe Andrieu: your use case, it took me in a direction that the rest of the text sort of breaks, which I just want to speak to is you could have a confidence method that is presumed to be usable by the user even if they can't use it today. for example, they may have something that they are bequeafd upon turning 21.
Joe Andrieu: and when they get this thing from their grandfather then they will have the key and then they can presume it. but the language here says at the time of issuance and I'm actually suggesting there is this weird edge case where at the time of issuance maybe it's not usable but when it is usable then it can be used right it's not a catch22…
Joe Andrieu: but the usleness is when that confidence method can be actualized if you will Ted go ahead
Ted_Thibodeau_Jr: Yeah. …
<Denken_Chen> +1 to “on behalf of”
Ted_Thibodeau_Jr: I did speak the words on behalf of and that might be viable. the framing of this as being confident that the subject that has identified is the entity that you're looking at or considering. puts again some of the limits that don't make sense to me for confidence. it's only applicable to a subject is what I'm hearing. and said that might be enough to resolve the issues.
<Dave Longley> "can be used at the time of presentation"?
Ted_Thibodeau_Jr: that I've had about the other things, but I don't know that that does anything on behalf of or The subject doesn't necessarily have to be an adult. They don't have to have capacity to enter into contracts to be a subject. They don't have to know that the VC exists to be a subject. that's why pets can be subjects. And the cat who inherits her humans millions of dollars to live out her days in the palace hotel. That's great because you can check their chip against the identifier that you have for them. But again, you're not going to check the chip of the kid because the kids aren't chipped usually yet.
Ted_Thibodeau_Jr: Yeah, I've got too much raw thought and not enough words around it. I'll leave it there.
Joe Andrieu: Okay. …
Joe Andrieu: maybe some more will come out. what you triggered for me is to me think I maybe use the term catch22, but I think there's an innate relationship here where if the subject can't leverage keys for whatever reason because they're one years old or they're pet or they're an inanimate object because subjects can be anything then I think it's simply a null set. those keys that are usable by the subject become a null set and therefore you cannot use a keybased confidence method to help a verifier increase their confidence that the subject is the party they're looking at. So we're not trying to satisfy everything for all subjects.
Joe Andrieu: We're saying that when you have this mechanism available called the cryptographic key and this asymmetric private public key thing that we can do then you can use this confidence method. Go ahead there.
Dave Longley: Yeah, that's how I was thinking about it and we don't necessarily have to resolve that the language here to address that. But I get Ted's concern that we might not be explicit enough about that null set concept. The other suggestion I put into the chat here is to replace at the time of presentation. You'll note that the sentence that follows immediately after this also says issuers should verify the use of the private key before issuance. And so you should do that, but there might be use cases where you don't do that. And really this is only effective if the subject can use this key at the time of presentation.
Dave Longley: And that would also cover these other use cases of bequething things and so
Joe Andrieu: Yeah, I like that with one caveat.
<Phillip Long> Seems like we're trying avoid the challenges of guardianship. Can this simply be narrow in this spec and push these guardianship-like questions for quardianship when it is addressed directly?
Joe Andrieu: But I think you're right. the second sentence there issuers should verify that is about encouraging closing the loop so that you test the confidence method before and so when the confidence method is tested again we have two ends of that being tested but they can't always test the confidence method so that's why the second sentence is there but I like if this is at the time of presentation with one caveat which touches on actually the next topic on the thread list which is
Joe Andrieu: we may not be in the context of a presentation for example checking a log file to see if a particular authentication action or whatever was done by the party you think it was done by and so I think there's another word instead of presentation but I'm not quite sure what that is and maybe we can talk about the other thing and figure out how we want to generalize beyond just the proof of use flow man, go ahead.
Manu_Sporny: If you could show the GitHub code. I updated it. I hopefully based on what Ted and Joe and Dave y'all were saying and did an amalgamation. Maybe this works.
Joe Andrieu: Plus one this, just to comment on it. I'm not seeing any other hands on our virtual queue. we could potentially get rid of the time of issuance and just say at presentation. I mean that gets back to this other conversation I want to have about, what is the nonVGVP way to talk about the valuation layer. but it is presumed to be usable. So This is not a conformance statement. We're saying, hey, the idea here is that it's presumed to be usable at time of issuance and presentation. So if it is usable at the time of issuance, then you should verify it, right? So I think that does flow. I think that's coherent.
<Ted_Thibodeau_Jr> "Confidence method can be used in some situations about some subjects", none of which "some" we have good definitions for? Makes me wonder how much value there ultimately is in this "confidence method".
Joe Andrieu: Go ahead.
Manu_Sporny: Yeah, a plus one to that and noted on the presentation thing and we need to get to that discussion next. I think my only question is this better and does this address your concern, At least is it better, not is it perfect?
Ted_Thibodeau_Jr: I think it's better. Yes. I'll keep chewing on it.
Manu_Sporny: Okay, I'm gonna commit it then.
Joe Andrieu: right. Okay.
<Dave Longley> ^i think if you invert that focus to the cases where it's clear, you see the value more easily; it's the corner/special cases that are tricky here.
Manu_Sporny: So that Ted Thibodeau Jr:
Ted_Thibodeau_Jr: It's fine. Yep.
Joe Andrieu: All right.
Non-VP Confidence Method Use Cases
Joe Andrieu: No other hands. U been giving man moment to commit so the issue about presentation is that most of these confidence methods may or may not happen during presentation. you could be out of a context where there isn't a back and forth with a VPR and a VP where you have a challenge and the VP is how you sign over the challenge. it could be a standalone interaction on a web page where you're uploading something that is the proof of signing over. and I think what I want to do is have our language cover both of those use cases without making it limited to just VPs. So to your most recent question about the VP and nonVP.
Joe Andrieu: So, I think it is useful and important for us to explain, hey, with a VP workflow where you get a VPR and you respond to that with a VP. I think we want to explain and show how that works. but if it's not a VP, if it's like looking at a log file, then we don't have a presentation, we don't have a presenter, the language needs to be generalized in a way that, I'd like to figure out how to talk about. Go ahead, Matt.
Manu_Sporny: Yeah, plus one to it. I just needed something concrete to latch on and I'm happy to write text to that. so I'm wondering if the most prevalent use case might be I'm just making this up. So, you use your digital driver's license to create an account on a website, noting that that's a horrible thing potentially to do in many use cases. and in there, it's got a confidence method that for authentication. and every time you log into that website afterwards, you just did off to do it. and the website when you signed up for the account noted that a confidence method was in the driver's license and it allows you to continue to use that confidence method to log in.
Manu_Sporny: Did off being the alternate thing, right? So, you identify yourself to the website using a verifiable credential that has a confidence method that points to an authentication mechanism.
Manu_Sporny: And then the website every time you log in after that just has you do a did off to log in as a concrete but that's a presentation. I
Joe Andrieu: That the loop is that we often talk about these in a conflated way right so did off has come to mean it's in a presentation …
Joe Andrieu: but I don't know that it should in some concept doesn't have to be in a VP flow, which is what I'm trying to tease out here,
Manu_Sporny: Yeah, the only other thing I can think of is authorization to an HTTP endpoint based on a Zcap. because it's kind of weird because you're not really raising confidence in the subject. you're kind of raising confidence that the subject has gotten an authorization to do something and you see like that it was hard for me to try and…
Manu_Sporny: fit a simple example into the spec. I'm concerned about people being able to understand this nonVP example. gotcha.
Joe Andrieu: …
Joe Andrieu: what about the log file? I mentioned that but you didn't pick up on it for some reason. but the log file has a nice feature that it is necessarily expected to be separated in time, a week later or a month later, someone's doing a security analysis on our log files as a matter of course. and there is not a presenter who's presenting something to you right now. You have a historical fact that's in the log. and so we're trying to make sure that the party who engaged with that at that point in time, may not have been a VP related interaction, is the person today. Go ahead, M.
Manu_Sporny: Yeah, I'm trying to think of how that would have resulted in not a VP having been presented at that time in the past, what protocol did we actually use for you to show up in the log?
Joe Andrieu: Go ahead there.
Manu_Sporny: That's what's missing.
Manu_Sporny: At least as far as I can see.
Dave Longley: A couple of comments here.
<Ted_Thibodeau_Jr> Perhaps. But those corner cases are where the value is most needed.
<Dave Longley> can we separate the non-VP bit into another PR?
Dave Longley: One, I do think we should find some language for this. two, I do think we should make it a separate issue and not hold the P up for it. Three, I don't know that we are going to be able to describe something that's testable with a log file that would also be interoperable. So I think one of the ways out of this is to say one way to do this is this and then describe the verifiable presentation mechanism and say there might be other ways to accomplish that involve log files this or that but that's not necess that does not sound like it's going to be something that we're going to interoperably specify and I think we should separate this issue out so we can get some good language for
Joe Andrieu: Plus one to that and…
Manu_Sporny: I'm raised in you right
Joe Andrieu: I started making a note so that we can do that. I think we should add a separate issue rather than hold up this PR. but something you just said I wanted to disagree with which was that I do think the Wait.
Joe Andrieu: we can define yeah the problem is about testability and we're right back into the algorithm issue with that we're having over in the resolution in terms of how do we describe these things we do not want to define a wire protocol or data format that would do some other new arbitrary kind of flow so I totally agree with you Dave that we want to stay away from that potential rat hole. but the algorithm bit that's nipping at me I mean I think maybe having an example saying there are other ways is the easiest way to do it.
Joe Andrieu: is that we can simply say look if you can perform a ceremony in which the candidate subject is able to prove use of a private key that's associated with this identifier then you've set aside a proof of but I guess we're not standardizing any particular proof of use ceremony is the challenge here. okay so it feels like we should just give a particular example and then the other question is let's find language to generalize it. that are folks following with me? Is that the consensus we seem to be getting up at?
Manu_Sporny: Yeah, I'm adding a issue 48 is now raised for that item. Show.
Joe Andrieu: Okay, All moving on to the next one. Back to the use case. yeah. This was interesting. So, I had not tracked this.
Joe Andrieu: What's the easiest way to pull that up? Maybe that did not jump to the section. Do you know what line it's on this example? Here it is. I see it did highlight it.
Manu_Sporny: I know it's light. We can add more if we want to.
Joe Andrieu: I think I have a different challenge here.
Type Of Multikey Object
Joe Andrieu: But I'm happy to be educated. this object here does not seem to be a multi key. So, one of the things I was confused about, it was one of my comments and about types. I was expecting a different type for we're specifying a C or we're specifying a verification method in a C. but you've got a different strategy about how to handle types and you're far more experienced with JSON LD. So maybe I'm just thinking about it wrong. Go ahead, Manny.
Manu_Sporny: Yeah, it's let me go back to the beginning. So, you could have a confidence method with a colon in just that did example meaning a text string, no multi key, no anything else. And you could argue that that is totally legitimate because you're pointing by reference to something over there and you need to go to that something over there to figure out what it is and whether or not you can use it. So that is from a JSON LD perspective legitimate. the next step is this object that we're seeing on the screen. So you specify the ID and you're like, hey, this is a multi key.
Manu_Sporny: So the system can have a little more assurance that okay I'm going to go out there and I'm expecting to find a multike key because it's a multikey I'm guess I'm expected that there is going to be a public key multibase expression there when I go to the reference they didn't put it in here for some reason there can be number of legitimate reasons people didn't do that but here I'm going to go out and it's typed as a multi key and then the third thing
Manu_Sporny: you can do is that I guess it's not necessarily above because this is doing it by value…
Manu_Sporny: if you put ID in that example above there ID type and then public key multibase sorry keep going down 668 line 66 yeah starting from line 668 through 672 that object …
<Dave Longley> from a JSON-LD perspective, you can omit / add as many properties as you'd like -- the ID signals where to "follow your nose" if you want to potentially get other properties.
Joe Andrieu: Down or…
Joe Andrieu: Here's 68.
Manu_Sporny: if you add ID there type and multike key that's the full expression including ID. So it is a legitimate expression of a controlled identifier. now the question does the group feel the…
Joe Andrieu: Wait. Hold on. That is not a controlled identifier. Manu Sporny: Manu Sporny:
Manu_Sporny: if you put the I D. …
Joe Andrieu: I'm just saying we have a C spec that defines…
Manu_Sporny: I see what you're saying. Yeah. Yeah.
Joe Andrieu: what a C is and we're not using CIS here.
Manu_Sporny: Sorry, I misspoke. It's not a C. It's a key that exists in a C. Yeah.
Joe Andrieu: In this case it doesn't though, but these are two slightly different use cases, So one is we're embedding which multi key might work. I still had some type related questions about it. But for this multike key, we are not embedding the key. And so when I look at this data object, I'm like how do I get this is not a key. This is a reference to a key.
Manu_Sporny: Yeah. the verification method pointer is effectively that that's what I thought you were asking for, Joe. So if I misunderstood, but I think that's still legitimate and we want to support it.
Joe Andrieu: Yeah, plus one.
Joe Andrieu: Dave, I'm gonna queue you up. plus one, I do want to support this structure. how we do it, I'm not sure. My concern is these two data objects are not semantically the same kind of data object. So, I think they need different types. Dave
Dave Longley: So I put this into the chat, but from a JSON LD perspective, you can add or omit as many properties or you can refer to these as triples as you would like in an object, an ID just signals where you can go to follow your nose if you want to potentially get more properties. So all of this from the lowest level data modeling perspective is a totally legitimate way to express this. and so there's no problem there. if you layer anything in your spec that says for someone reading your spec that you have to have this property or that property, then that's something that you have to do to be conformant with whatever spec you've written.
Dave Longley: But if this is found data, they discover it or it is handed to them and they're just processing it as JSON LLD or as linked data generally. There's absolutely nothing wrong with this approach. And it's commonly used to say, I've got a few things to say about this and if you want to go fetch it, you can get more. and the few things I had to say about this might help you decide whether or not you want to bother going to fetch it. Because if you only understand multi key, for example, and you don't understand JSON webkey, maybe you won't go fetch it. Or if we're talking about some other thing like render methods I understand this render method type and now I want to go fetch dreference all the other information that doesn't mean by the time you dreference a thing you still need to confirm that the type that you found is still what you wanted because that there could have been a mismatch…
Dave Longley: but this is a way to signal to someone whether or not they want to bother following their nose to get the rest of the information. and then the ID that you follow then becomes the source that you have to decide whether or not you trust for that operation.
Joe Andrieu: Yeah, that's really interesting.
Joe Andrieu: I think I'll just need to get my mental model on the other side. but it's not there yet. and I just want to voice what feels weird to me, Dave, is I want an identifier for this object in this graph, in this VC.
Joe Andrieu: and you're saying no the ID entangles all the references to that ID and so even though the object in this VC is not actually a multike key because we can go retrieve it somewhere else which I guess is part of the open world sensibility around these data structures
Dave Longley: Yeah, that's right. If you want something in this particular graph, you'll have to put it in this particular graph because this particular graph does not exist outside of this document. but that's what the embedded use case is for. If you don't want that use case and you want to say there's this information can be fetched elsewhere in some other graph, here's the ID for you to go fetch it. That's just a different use case. But it's all legitimately follows the data modeling and…
Dave Longley: spec the low-level specifications for this.
Joe Andrieu: Except that you can't tell by the ID or…
Joe Andrieu: the type whether or not you need to fetch anything. that's my sort of conceptual quagmire. I'm
Dave Longley: As an implementer of this I would know that I would see that the type is announced as a multikey. first of all as an implementer I would look and see what the type is. If the type tells me that this thing is a multikey and I support multikey and the material is not asserted in the document itself then I would use the ID to fetch it. If there is no ID and there's only a type then there's no way for me to use that. won't use it. If there's no type provided and there's a DID provided and it's a bare DID,…
Dave Longley: then I know that it's for a DID document and I can decide to fetch that DID document. So that there's a number of ways as an implementer that I could know whether or not I want to use what's
Joe Andrieu: Yeah. …
Joe Andrieu: I think we need to write something about that up. because when I look at this as an impleer, I'm very confused by how am I supposed to know that I'm supposed to do that? and so we need to write up exactly where they're supposed to do that. in particular, multi keys don't need to be have did based identifiers. So it just triggers a whole bunch of, what are the generalized things going on here? go ahead, man.
Manu_Sporny: Yeah, that's fine. I mean, I can add some explanatory text to the PR. one I'm wondering if it's more generalized. the thing I'm struggling with, Joe, is like Jason LD RDF makes this pretty clear. But I don't think we should presume that people implementing this stuff at this level understand any of that. which is why what you're saying Joe resonates with me on just at least explain it and maybe point to other places where people can read more about this. and this thing we're describing is not specific to cryptographic keybased identifiers, right?
Manu_Sporny: It's not specific to this thing. It could just as easily apply to not that I think this is a good idea, but biometric templates and a variety of other objects in the DI document or the verifiable credential and so on so forth. So it feels like maybe this is general advice that we should put into the VC data model. it's not necessarily something that should go into this specification and maybe we point to that section in the confidence method thing to describe what Dave just covered. So I am wondering again if this is another issue and…
Manu_Sporny: maybe it is an issue for the VC data model or there's an issue somewhere that we need to raise to address this more holistically. that's
Dave Longley: Couple points.
Joe Andrieu: Go ahead,…
Joe Andrieu: D. Yep.
Dave Longley: First again I think we found something that we can decide what to do about as a separate issue. I wouldn't want that to hold up the PR that is doing a lot of useful things. and the second thing is I having some deja vu about this sort of thing. I think this has come up before and people have said that's what f reading the JSON LD specs which are already linked to is for I don't necessarily agree that that's so straightforward given Joe's reading this he's like hey…
Dave Longley: what do I do but maybe when we do something about this we can more directly have a little bit of text and directly link to those specs or something along those lines.
Joe Andrieu: cool. …
Joe Andrieu: I do think some language here would be helpful. Let's not hold up this PR. and it might be lightweight language here and more detailed language somewhere else if there's a more appropriate place to put it. but I want to push back against that this is expected for JSONLDLD because I actually fundamentally disagree with the appropriateness of downloading by default. I use DIDs as identifiers which identify this thing right now that you're dealing with. and you don't necessarily need to go DID to get the other data elements related to that. So the expectation that someone's going to access the network to get the rest of the data about this object creates a security dynamic. I'm really not comfortable with.
Joe Andrieu: But that's sort of a meta note that as we unfold this, I just want to try and help people understand the trade-offs about those choices. Go ahead, Dave. cool.
Dave Longley: Yeah, I wanted to in case this was unclear, I also don't support download by default. I did not mean to imply that that's something that should be done. Rather, there are situations where if you want to use something or want more information, you have to download. that doesn't mean you should do that by default. just means you're making a choice to do it and it comes with different security considerations and it should be framed that
Joe Andrieu: Should I note here? I lost our thread on which issue we were on.
Joe Andrieu: Yes,…
Manu_Sporny: Joe, I have raised issue 49 to track that if you want to make a comment about it somewhere in the PR.
Joe Andrieu: I wanted to do that. but I think we just lost it cuz didn't you respond to this comment, Manny? Yes,…
Manu_Sporny: Was this example already exists comment I think all the way at the bottom potentially. I did also I did also Yeah,…
Joe Andrieu: you can. Okay.
Manu_Sporny: there you go.
Joe Andrieu: And what number was it?
Joe Andrieu: M Okay. Okay. Was that actually the last comment from you, That engagement.
Manu_Sporny: Issue 4949.
Dislike Of SIDS Spec
Manu_Sporny: Yes, I think so. There's also this I didn't wanted to get a feedback on the SID thing. okay.
Joe Andrieu: Yeah. I was honestly confused about that.
Manu_Sporny: Yeah, I think my position on the SID spec is clear. I hate it and I wish we never did it. And the only reason we did it was because we had a gun pointed to our head in the working group and people were threatening to fork the spec and we did the work and those people forked it anyway. So now we're stuck with this crappy,…
Manu_Sporny: spec. I know some people like SIDS, but I think they're just centralizing bad. We shouldn't suggest that people use them.
Joe Andrieu: Your P. Manu Sporny:
Manu_Sporny: We should be using s everywhere. The end. And it makes me sad every time I have to write a PR…
Joe Andrieu: Right. And right.
Manu_Sporny: where I have to ref that spec.
Joe Andrieu: So, I appreciate that. What was confusing to me is that you would rather not suggest repeating using SIDS, but your PR does exactly that. So, I was trying to reconcile your own comments with the PR you submitted,…
Manu_Sporny: Yeah, it's…
Joe Andrieu: and I was
Manu_Sporny: because I can't site the DIDS The thing that has the citations lives in the SIDS spec.
Joe Andrieu: But my point is I couldn't understand…
Manu_Sporny: That's the reason. And because people would complain if we didn't just mention SIDS in there and did subset that.
Joe Andrieu: how I might be responsive to your comment without getting rid of the…
Manu_Sporny: Yeah. I gotcha.
Joe Andrieu: what you put in the PR. Okay.
Manu_Sporny: Yeah, what's there. I don't think we can do it any other way because the citations exist in the SIDS spec. I think…
Manu_Sporny: what I'm trying to get across is let's just use DIDs as examples everywhere and not use an HTTPS URL for a SID because Yeah.
Joe Andrieu: For that I'm good with you on that.
Joe Andrieu: I think from a spec standpoint it needs to go to the SIDS spec,…
Manu_Sporny: Yeah. That's right.
Joe Andrieu: but I agree with you from an example perspective.
Manu_Sporny: Yep.
Joe Andrieu: Let's just use SIDS instead of HTTPS. However, I need to socialize my rebuttal to your dislike of SIDS. I think SIDs should be used for centralized identifiers. For example, WebVH shouldn't be a decentralized identifier because it has a centralized control structure just like a URL.
Manu_Sporny: Yep. Yeah,…
Joe Andrieu: So, I actually think the folks behind the web stuff and…
Manu_Sporny: I agree with that.
Joe Andrieu: are there multiple different efforts trying to do it in different ways. One of them should pick up the CI and say, "Hey, we want to take this to the next level and add certificate transparency to a CI standard." That I would get behind.
Joe Andrieu: I think if we're going to have a centralized root authority but we want to be able to expose verification methods in this manner let's standardize it I don't think we have the appetite of people who want to go do that so we are sort of just in this broken state in terms of that the people who care about this are not necessarily the people who are driving the standard around it sadly. Okay, cool.
Manu_Sporny: Angry with all
Joe Andrieu: All right. we have roughly 10 minutes left and we got through most of this. Is there So, should we just merge it? Are we good enough for that? Go ahead, M.
Manu_Sporny: Yeah, I'm happy to do that after the call. I was going to try to capture the last five minutes to talk about test suite and…
Manu_Sporny: just put an idea in people's heads and then maybe we talk about it next time around.
Joe Andrieu: Okay, that sounds good.
Joe Andrieu: Yeah, we did have test suite and potentially triage,…
Test Suite Discussion
Test Suites
Joe Andrieu: which we're not going to get to, but let's talk about testuite and I'll go ahead and stop sharing. Excellent.
Manu_Sporny: Yeah,…
Manu_Sporny: just real quick, we had a discussion in the VC recognized entities call two weeks ago about what are we doing for the test suite there because it requires kind somewhat of not a complex back and forth but at least an exchange of credentials to see if you did the right thing. So in recognized entities it's effectively the minimum case is like hey give I am the verifier I want you to go through a workflow you're going to give me a recognized entity credential maybe one or more as the holder and you're going to give me a VC. I'm going to receive it into my workflow.
Manu_Sporny: I'm going to do verification and then I'm going to do a bunch of validation and then I'm going to tell you whether or not you were successful by maybe issuing a credential to you erroring out, I'm wondering if we can use the same pattern for this spec. because I know we can off mechanism using that. I think we could do a keybased one. I am struggling on the biometric I mean I think we could do a biometric based a static image profile photo based one. I don't think we could do a video based one easily. what are the thoughts there? I heard some push back from Brent.
Manu_Sporny: He said it would be quote wildly inappropriate for us to require VCOM as a part of the test suite. I don't know if I agree with that statement because the working group is working on VCOM. but I'm sensitive to people, getting cranky about that. that's the proposal.
Manu_Sporny: Could we make this a really simplified workflow where we have the holder present a VC and another thing in the presentation that demonstrates that they got through the workflow successfully. That's it.
Joe Andrieu: So mostly that sounds pretty good.
Joe Andrieu: I wanted to rebut Brent's position which is that the test suite is not something that every imple should use to try out their implementation. the test suite is something we run to demonstrate that every feature in the specification has an implementation that's interoperable.
Joe Andrieu: So if we have enough implementations that DIDCOM or VCOM or whatever transport protocol we want to use, then I think it's perfectly legitimate to build a test suite that uses a technology that lets us do it. In the same way that if we write our test suite in Python or JSON or JavaScript or whatever, those things don't matter. we're not making people use VCOM for any particular thing. But if you want to demonstrate through the test suite that you have implemented the features, we need a way to do it. so I think your proposal is pretty good, Manny. I do have the same questions about how do we get real biometric workflows in there? but on the surface, it sounded like it started well.
Joe Andrieu: Scott, what thoughts do you have about how could we get a real biometric template check in some sort of flow? Have you thought about sort of the test suite side of this yet? Scott, if you're trying to reply, you're still on mute. All right, we may have lost Manny, what's the next step then for the test suite thread?
Manu_Sporny: probably working through the details with Dave Longley to see if this is something that we can easily do. I'd have the same questions on recogn if it works for recognized entity it'll work for this group.
Manu_Sporny: So I just need to work through details with Dave. and I think Stephen Curran might be trying to help us out on test suites as well. So it's just some detail work that we need to just work through the details is next.
Joe Andrieu: …
Joe Andrieu: next step is let the entities work settle and then hopefully we can adopt it. And I guess we'll need to get folks volunteering to maintain that.
Joe Andrieu: But let's get that work to the next point where we can look at it.
Manu_Sporny: Sounds good.
Joe Andrieu: Any other thoughts before we Just got a couple minutes left. with that, let me thank you all for your contributions. U Manny, feel free to merge that PR. and we'll work through the rest of those issues in good time. And thanks for that contribution, Manny. I appreciate it. All right. Thanks everyone.
Denken_Chen: Thanks.
Elaine_Wooton: Wow. Meeting ended after 00:56:36 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.