Conversation
|
Thanks @wes-smith, the introduction is now clearer. What I miss is the "why". Why is it necessary to have this augmentation? You said something on the call whereby the original barcode may contain information that is not present in the original credential. In other words, the original barcode is not a binary representation of the credential; instead, logically speaking, the original barcode may be considered as a special form of credential statement that is not present textually. If that is the case, it should be explicitly said in the intro, and provide examples on that type of extra data. I am also looking at the examples.
Maybe it is helpful to have some clear terms to differentiate between the two categories of our algorithms, and also have terms that differentiate the "original" barcode from the "generated" one. This could also be used to make it very clear what ecdsa-xi-2023 is used for, and that section may be ignore by any implementer that works on the simple case only. |
I'm getting a bit tripped up on the word "original" in what you wrote. Re: why it is necessary, take the example of a document that already contains an optical barcode - like a US driver's license, which typically contains a PDF417. Adding a VCB to that document shouldn't be done by adding a standalone barcode, duplicating the data from the existing barcode - instead, the existing barcode should be reused to include a VCB, in a form where the digital signature protects the existing data.
Agreed :)
Another indicator is that the credential subject includes all of the data from the document. In the "augment" case, that data typically already exists in the barcode, so the credential subject doesn't need to duplicate it.
Agreed :)
I suspect this is the core of the confusion here. The original barcode is the barcode that has now been augmented to contain the VC. It sounds like the point you are making is "you could just put all the data that was in the old barcode format into a VC and have it be simple" - which is true, but the "augment" case is not about doing that, but about adding cryptographic security to an existing barcode format. See this example from the test vectors - those are the bytes that the PDF417 contains. The first ~3/4 of those bytes are the typical layout of a US driver's license (essentially key value pairs), and the suffix beginning
Yes, I think the core problem here is how to communicate the above nuances - terms like "original" and "generated" I think are causing confusion more than they are helping here :). |
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
|
I believe I understand now what led me astray. First of all, for whatever reason, I understood the term "barcode data" to mean the, shall we say, pixels of the barcode. But what you mean is the "information contained within the barcode" as it says in the introduction. Maybe it should be said clearly somewhere that this is what we mean by the term "barcode data" in this document. Also, we should also spell out (e.g., in the examples) that "augment" means the creation of a new barcode, whose data includes the original barcode data plus the corresponding signed VC. The reader should not be required to go through the example to fully realize this point. Thanks for your patience. I am looking forward the rest of the changes. |
dlongley
left a comment
dlongley
left a comment
There was a problem hiding this comment.
I only struggled with one sentence here, not quite sure what language to suggest but I made an attempt.
| printing processes. This adds tamper resistance to the barcode while | ||
| optionally enhancing the barcode to provide information related to whether or | ||
| not the physical document has been revoked or suspended by the <a>issuer</a>. | ||
| information about either the barcode itself or the subject of the barcode. |
There was a problem hiding this comment.
| information about either the barcode itself or the subject of the barcode. | |
| information in the barcode or about other information in the barcode. |
|
This was discussed during the vcwg meeting on 21 April 2026. View the transcriptClarify the two major VC Barcode use cases. by wes-smith · Pull Request #44 · w3c/vc-barcodes · GitHubWesley_Smith: And there is go ahead. Ivan_Herman: So I'm sorry I asked so many questions from that one… Ivan_Herman: because it was not clear to me and there is still something which you just said which strikes me. Wesley_Smith: Go ahead. only. Ivan_Herman: When you say it appends at the end of the barcode, what does that mean for a QR code? Ivan_Herman: If the barcode is a QR code, it doesn't make sense to say the pens to the end. Yeah. Dave_Longley: I don't know if you want to answer that. my response is somewhat in response to that. I had similar struggles with at least one sentence in the PR and I think it has to do with separating whether we're talking about the data in the code The barcode being an optical code that is pixels ink on a card or on a piece of paper or whatever. Dave_Longley: And I think we need to do a slightly better job of expressing that because when we talk about Ivon was just saying the inserting something at the end of a barcode I think is probably too in the details and thinking about a PDF 417 and putting information at the end of the data that is expressed in a barcode which then changes how the barcode's expressed but depending on what type of optical code it is It might literally look like more ink on the end of a barcode, but in the case of a QR code, it's not going to be expressed in that same way. Dave_Longley: So I think we need a slight clarification that the two different kinds of VCs you can have here are one where the VC itself is all of the data that gets expressed in an optical code or you take existing data that's already expressed as an optical code and you augment that data in some way with a VC and that VC then expresses some kind of information about the other data that's being augmented. And then you produce a new barcode from all of that… Wesley_Smith: Yeah. Dave_Longley: which may not involve just appending some more pixels on the end of something or it might be totally different. And go ahead of Ivan_Herman: Thank you very much, Dave, because I thought that I was the only one who doesn't understand anything. I had exactly the same problem with the pixels versus the data that pixels refer to. so that's very much in line with and that also something that is not only for this introductory part not for the only. The same kind of problem arises in the description of the examples that follows this part which mixes these things and even when we come to the crypto suit later which makes use of the existing data there again it's a bit unclear where the data comes from and what kind of data is put there. Ivan_Herman: So that's not only for the introduction, it's for the whole presentation of the document that this is relevant. Wesley_Smith: Yeah, absolutely. Good discussion. strongly agree. I will note that with respect to one clarification when I said append to the end of the barcode, that was loose conversational language. I don't think any where anything in the PR uses the term end. it doesn't need to be the actual end of the barcode. you augment the barcode somehow. I think that maybe it would be useful to make clear that from the perspective of VC barcodes and this technology, barcodes are essentially immutable things, if they exist, they exist. And you're not when we say we're changing augmenting an existing barcode, it doesn't mean augmenting the ink and pixels of a barcode that already has actually been printed. Wesley_Smith: it instead refers to the data. need to figure out how to communicate that nuance somehow. Definitely agreed. one thing that I would like to bring up which I'm curious to have the group's perspective on. So, let me see if I can find a link to it. we define a type optical barcode credential. and however the current specification text and again let me find a link here. I believe the current specification text only uses the type optical barcode credential for the augment an existing barcode use case. Wesley_Smith: So, if we were to just take a VC and put it in a QR code and print that on a document, which is a totally legal and very useful thing to do with the VC barcode the spec contain the optical barcode credential type. even though it at least appears to be something that could be well described as an optical barcode credential. So, I think we could maybe generalize that type, but I will note that if we do that, we'd have to make sure that we don't need to get the coupling back between the optical barcode credential type and… Wesley_Smith: the constraints on the other use cases mechanisms in some other way. Go ahead. Ivan_Herman: I don't think I agree with… Ivan_Herman: what you say. So if I take the simple case where I generate the barcode from an existing VC with all the signatures and whatnot. for me in a way that's a rendering method. I don't want to mix the two things but it's the similar thing. You are rendering something which is there and the VC itself doesn't change whether you render it by printing the JSON and giving it a piece of paper or by putting it into a barcode. So that's separate. The notion of a type is only for the credential itself. <Wesley_Smith> Verifiable Credential Barcodes v1.0 Ivan_Herman: the other type when you have the augmented thing. In a way, I would also question whether it is a good idea to have a separate type for that for the same reason. But you could say that if there is an added semantics to it namely that it is a type that requires a specific type of crypto suite. namely the one which uses I don't remember the name the one which is defined in this spec. so that's a kind of an added semantic to the credential as a type. Ivan_Herman: So it can be justified but when you don't use that there is no justification to a type or change the type in my Yes. Wesley_Smith: That makes sense. Wesley_Smith: I think another way to phrase what you were saying is in the first use case once you get to the VC you're done. You've already understood everything that you needed to understand to but in the second use case, you're not done because you need to go look at the rest of the barcode to produce the hashes that you need to verify the signature and so on and so forth. so that makes sense and I totally agree. my concern more is about maybe it's just a naming concern honestly. Optical barcode credentials sounds a whole lot like both of those things. but there is value to having a type that is coupled to some of the semantics as you said in one use case but not really in the other use case. Wesley_Smith: So, Dave Longley, go ahead. Dave_Longley: Yeah, Avon just said a lot of the things I wanted to say in response to that. So, I'm strongly in agreement with what Avon just said. I think in the first case, we're just talking about a VC. You can render it however That could be JSONLDD text on a screen. It be a QR code, could be some other kind of optical barcode, could be whatever rendering you want. and in the second case we are talking about a VC that is specifically about other data that is typically rendered and specifically in this case for this spec in an optical barcode. that's where that type comes from. It's a little bit awkward and there's a little bit of conflation because you do care about what the data format is behind whatever barcode it is you're trying to augment. Dave_Longley: fundamentally you are looking at an optical barcode. There's some kind of data that's behind it and you want to add a VC to augment that data and then reproduce that same barcode in that same format. That is the whole use case. and so optical barcode credential doesn't fully capture that. It doesn't capture the full typing of what it is you're augmenting. if I remember correctly, I think unfortunately there's not another type that's on there that would speak to what kind of data it is, but I think the specs also going for a general solution especially when it uses the protected component index and there is other information there. So sorry the spec was loading slow. I was trying to take a look. Dave_Longley: So there is other information when you use an optical barcode credential where you talk about the subject which is the optical barcode or the data behind it and the subject of your credential at that point to give an example from the spec is an AMVA driver's license scannable information. that actually makes a whole lot of sense. So the subject you're targeting with your credential is the scannable information that's inside of that optical barcode. And then that protected component index is saying which fields inside of the scannable information are protected by this VC that is an optical barcode credential. the more I just read all that, the more comfortable I actually got with so I don't know that I actually have an issue with the way it's currently modeled. Wesley_Smith: Okay. … Wesley_Smith: thank you. Avon, go ahead. Ivan_Herman: I'm sorry. Ivan_Herman: I have a question for what Dave said just to make it very clear. You said that the subject of the VC is the data behind the optical barcode. For me until now my mental model was that the subject is whatever is in the credential. It's just that what is described in the VC is not the whole information Ivan_Herman: about that subject. And these two statement are not identical. Dave_Longley: Yeah, I actually meant to put my hand up, not thumbs up that day because I think in this so when we're talking about the first case… Greg_Bernstein: That's Dave_Longley: where you just take a VC and render it however you want, which could be an optical barcode, the subject is whatever the credential is about and so on. I think in the optical barcode credential use case, the subject is the scannable information that's already in the barcode and you're making a statement about that information and saying these parts that thing has a bunch of components inside of it. These are the components that are protected by this credential. And so this credential is stating the information in this barcode or the other information in this barcode is protected or… Dave_Longley: these other fields in other information in this barcode are protected by this credential. And so this credential is really about the other information that is in the same barcode in which it resides. Wesley_Smith: Plus one. Wesley_Smith: It's protected component index is just an indirection, it's as Dave said, the subject of the credential is elsewhere and what's actually in the credential is just a lookup mechanism that specifies exactly what data elsewhere is the subject of. Wesley_Smith: Go ahead. Ivan_Herman: I would love to see that statement put clearly in the introductory part that this whole PR is all about… <Wesley_Smith> Verifiable Credential Barcodes v1.0 Ivan_Herman: because that was not clear for me at all. Now I have a different view of the whole thing and it should be clear in the introduction already. <Wesley_Smith> there is no information in credentialSubject other than an "index" against the externally available subject information Wesley_Smith: Yeah, absolutely can do that. Ela, go ahead. Elaine_Wooton: Yeah, I don't if it's confusion or not. so the optical barcode credential is going to be the thing that you add that is in addition to the data that was already there for the second use case. And then in the third to last sentence we have that whatever it is it says is protected by the digital signature. So I think we need to make clear what the digital signature is as compared to the optical barcode credential. Elaine Wooton: Ivan_Herman: We lost Elaine_Wooton: And I'm not I accidentally hit the button. So it may be that it doesn't me need to be made clear, but it's not clear to me… Elaine_Wooton: what the relationship is by. So, if the thing that we're augmenting with is the digital signature, then isn't the digital signature the optical barcode credential? And I think it's not,… Wesley_Smith: Yeah. No,… Wesley_Smith: it's a Sorry. Elaine_Wooton: but I think we need to make it clear. And I'll tell you why. Because the digital signature, that's the term that AMA is using for a bunch of things. So, we want to make sure that Wesley_Smith: No, it's a really good point. So what we're adding is it is a digital credential which contains a digital signature and most of the time when you see that pattern the digital signature in the digital ial just covers the digital credential itself. but here we use a different mechanism so that the digital signature covers not only the credential but also the other data in the barcode. so we need to be explicit about how that works. I know that there's some technical discussion about that later in the specification and… Elaine_Wooton: Yeah. Yep. <Dave_Longley> the second case is: "there's already some data rendered as a barcode, let's make a VC about that data and then generate a new barcode that has both the VC and the original data in it" Wesley_Smith: it's specified algorithmically and so on. but as you're pointing out that doesn't really help somebody trying to read the introduction and understand what's going on. Ivan_Herman: I… Wesley_Smith: All right. Ivon and Elaine if you guys could go ahead and add brief comments to that with respect to what we talked about today that would be really helpful. I would love to be able to just make those changes immediately, but unfortunately today I cannot. Ivan_Herman: what I hope is that the system will work and whatever we discussed will appear automatically. Wesley_Smith: True. Excellent. Okay. I love that. Ivan_Herman: If I put a topic with the reference to the PR. It should go through all the mirrors that we have. Then at the end of the day, it will be there. Ivan_Herman: I hope. Wesley_Smith: That sounds so thanks. That's probably going to wrap up discussion for that We're running low on time for VC barcodes. so I will make those changes and I expect we'll want to have another discussion about that before it gets merged. So maybe we'll close out that topic next week and hopefully merge that Ivonne, I saw that you raised a PR adding some sort of script support workflow script to the barcodes repo. I have approved this. I don't know what you are envisioning in terms of the future of that if it needs group discussion, if it should just get merged. What are you thinking? Ivan_Herman: I would like money to have a look at it just to be on the safe side. Ivan_Herman: Several eyes is better than one pair. But in theory the only thing we have to do is to merge it and from that point on the acid now will work out. Wesley_Smith: Go ahead, Greg. Ivan_Herman: But it's better if money manu or someone who knows how these things work not only me have a look at it. That's all. Greg_Bernstein: What does the Akidna script in general do? Greg_Bernstein: Do I know what kidnas is wonderful little animals? I don't know what the script does. Ivan_Herman: The akidna script is a YAML file for the GitHub. What's the official name with GitHub workflow script? Ivan_Herman: I always for mix up the name action akidna action script … Dave_Longley: Some GitHub actions, maybe GitHub workflows. Ivan_Herman: what it does is that once a PR is merged then it will run a script which is provided by WCC … Ivan_Herman: which picks up the document and the possible references to images and other diagrams and whatnot and it will automatically create a version dr in practice… Greg_Bernstein: Okay, that's the publishing thing. Greg_Bernstein: Okay, the draft publishing. Okay. Thanks, Ivan_Herman: what this means that it blurs the difference between an editor's version and the published version of the draft. the content wise the two are the same. <Benjamin_Young> GitHub Workflow Action YAML Thing Wesley_Smith: All right, that sounds good. if we need Manu's review, I expect that isn't super timesensitive. I know Mu is traveling, so he might not get to it for a little bit. that's fine. I think that probably wraps up the VC barcodes portion of this call. thank you guys for the time. Greg, do you want to take us into DI land? <Dave_Longley> :) Greg_Bernstein: … Wesley_Smith: I'll topic it in the chat. Greg_Bernstein: I do have a couple questions that probably might be answered by Ivonne. those FPWDs which stand for first public working drafts are going in or have gone in which means we're going to have the new short name. So we're going to have 1.1s on these documents. Greg_Bernstein: So, are we ready to start formal PRs and… Greg_Bernstein: updates on the 1.1s? is that work able to start now? Ivan_Herman: It has become formal last Thursday. Ivan_Herman: And… |
| A barcode containing a Verifiable Credential can be added to a document. | ||
| This Verifiable Credential will typically contain some or all of the data | ||
| from the document. In this use case, however, the barcode will generally | ||
| contain only the Verifiable Credential. |
There was a problem hiding this comment.
The word "document" is confusing here, as we use the word "document" often to refer to HTML pages, XML documents, and data files in general. We might want to say a physical document to distinguish here.
The last sentence is confusing as well. It says "this use case", but doesn't explicitly distinguish it from the first use case in the first sentence? I'd suggest changes, but I'm having a hard time distinguishing what this paragraph is attempting to convey.
| Documents that already contain barcodes can augment those barcodes with a Verifiable | ||
| Credential for improved security. Here, the Verifiable Credential contains a digital | ||
| signature that protects not only the Verifiable Credential itself but also the | ||
| data that already exists in the barcode. |
There was a problem hiding this comment.
Speaking explicitly to the use cases might be a better option here. The description is too vague to be useful to highlight the distinction.
5 participants
This PR reworks introductory paragraphs to make clearer that there are two ways you can use a Verifiable Credential Barcode:
It also contains some small editorial fixes.
Resolves #38.
Partially addresses #37.
A followup PR will restructure the main technical content of the specification to reflect the above dichotomy - that PR will finish addressing #37.
Preview | Diff