Phil_L_(P1): Okay I was curious that you mentioned that you did internally decided that the need to use sort of existing processes and systems which were PDF depend if you will lead you at this stage to focus on encompassing the verifiable credential as an attachment to the PDF through the QR code but I was wondering is. ✪
Phil_L_(P1): And some sense looking at the rendering of the data in a Json file into something that could be more approximating a fully rendered text document of the sort to PDFs generate as a second phase so that you didn't have to deal with that particular problem that I suspect Dimitri's going to be talking about in later in the session or was there some other reason beyond that other than the not wanting to have to. ✪
Phil_L_(P1): Icon building a renderer that could make it look pretty for. ✪
<deb_everhart> but isn't the wallet the way the person controls the record?
Phil_L_(P1): No it does it I think that you're making a very Salient point that there's only so much transition you can make in one jump and at and the bigger problem isn't the technology so in so much as it is the humans that need to be able to feel comfortable with it so I think that's a very good observation thank you. ✪
<john_kuo> Wouldn't that be more of a lineage of revocation and re-issuance?
<dmitri_zagidulin> @John - revocation (of previous versions) might not be needed or appropriate. Because each VC says "at this point in time the following is true"
<dmitri_zagidulin> revoking such a VC says "actually, that VC WASN'T valid at that point in time"
Phil_L_(P1): Thank you I didn't that I think Dimitri is what I was asked about in the versioning system that Marty was describing which is if let's say that a new version is available when the individual opens their wallet to look at a particular credential presumably the credential the wallet has been has been informed that there is a new version available to prompt them to do that if the individual. ✪
<marty_reed> On the revocation discussion, I'd love to hear/see any demonstrations of revocation.
<marty_reed> currently validation fails if there is a new version in the parent system
Phil_L_(P1): Assuming that you would you're saying that the validation would fail when if they decided to send it to a third party and I just wanted to verify that that's what the intent in the current thinking would be and I guess sure yes that you know the way in which the question was posed to the person holding the wall at the holder is that there's a new version the credential available. ✪
Phil_L_(P1): Declined to accept that and just send the existing one you have because it is signed and the like the question is is the presumption that the verifier knows the new exhibit new version is available somehow and therefore would decline verification of the one that was sent to a an employer or some other entity and they then chose to verify try to verify that one. ✪
Phil_L_(P1): Well it to put to full 12 Marty because he talked about it in the ocp but I'm also interested in McMaster case because it sounds like the way it's currently designed the coming back to the Mother Ship so to speak as part of the current designs of the system which would potentially allow them to be able to decline a credential that's been updated and the individual has failed to download the newest version so I just want to verify that too. ✪
<deb_everhart> don't registrars already submit "in progress" student data, such as NSC PDP data reporting and current enrollment requests from students and others, such as the enrollment letter shown?
<deb_everhart> I thought in progress reporting was a common use case
<phil_l_(p1)> Thank you James. Great work!
<deb_everhart> thank you James!
<phil_l_(p1)> The anchored resource mechanism has greater applicability to other cases where the size of the "thing" is too big to be included within the credential itself.
Keith: I think maybe I can just dig deeper on display because I think that there can be differences in how well it's display information like what's it take Atticus talk about what kind of information like typically I mean other while it's that I've been involved in you just say things like issue or info like contact support info and then the contents of the VC itself and maybe images so like I've often thought that while it vendors can independently choose how to show that information but I do I mean I totally agree with you. ✪
Keith: a point that when you want to display things like issuer logo. ✪
Keith: This PDF image then you need ways that wallets you know you don't want to get a crop properly you want to be able to get it sized properly as you can display it properly is that what you mean by this because is that what you mean by display a my capturing it correctly or are you mean other things as well. ✪
Keith: And I just like it's up to wallet that I mean that's kind of the beauty of the market is that the the wallet with the best presentation kind of will you know be preferred be preferred by consumers is that rather than some sort of like trying to do static what is it often like display will be one of the key areas of differentiation between wallets how well they do display. ✪
<kaliya> QR codes that are static with VC s dangerous
Phil_L_(P1): Yes I guess what I wanted to say that it seems to me that the hash link approach that you described is actually a broadly applicable to any kind of circumstance where the content of an object is bigger than is reasonable to include in the in the VC itself and so by you know focusing on how you would apply that to different circumstances such as the image on a card and what's presented when it's displayed. ✪
<kaliya> Very dangerous because the can be super easily copied and replyed
Phil_L_(P1): then is the composite of the polled image from wherever the Third. ✪
<dmitri_zagidulin> @Kaliya - great point
<dmitri_zagidulin> which suggests the need for templating (rather than static image)
Phil_L_(P1): And the rendering of the thing of the way it's done traditionally on the plastic would be indistinguishable from the plastic itself so I think that's the probably the most productive approach and the one I would urge us to consider the biggest problem that that and UND just described is the the same problem of payload size you can do that for small DC's but you can't do it for VCS that contain much like evidence and things like that. ✪
<phil_l_(p1)> are there privacy concerns there if the destination is itself encrypted?
Kaliya: I'll just say what I said in chat stata QR codes. ✪
Kaliya: And I guess the same is true for barcodes but you know static QR codes with verifiable credentials within them that are signed are very very very dangerous the reason being is that they are entirely copyable and replayable. ✪
<phil_l_(p1)> Excellent point Kaliya
Kaliya: Is this not true of verifiable presentations that are you can't copy and replace because their presentations not the original credential so I have an unfinished but readable paper about this largely written by John Jordan that I think I'll try and send a list I'm sick right now otherwise I'd send it to chat right now but. ✪