> > Would I be correct in assuming the concern is not in the data formats > themselves, but in the potential protocols being used to issue these > credentials?
Yes, you are correct. As I wrote in my response to John, I am talking only about the higher level protocols that handle JWP/SD-JWT. I may have confused you with the example of the digital COVID vaccination certificate. I mentioned it as an example of the higher level protocol that would allow an Issuer to not become a personal data controller, and did not address any of the pros/cons of other aspects (e.g., the basic design problem of disclosing all user attributes without authorization, adopted format itself and so on). I am a little sorry that the protocol issues I mentioned were out of place as a topic for discussion here. From: Mike Jones <[email protected]>: > Changes made to the draft charter in response to feedback during the BoF > were: > > - Said that the charter is for the JOSE working group > > Anyway, the reopening of the JOSE WG (not a new JWP WG) is very welcome to me. Best regards, Daisuke 2022年10月15日(土) 1:27 David Waite <[email protected]>: > On Oct 14, 2022, at 9:23 AM, AJITOMI Daisuke <[email protected]> wrote: > > If you are not aware of the difference and insist, "I (as a Holder) have > the right to freely disclose the issuer's data (related to me) !!!!!!!!", > then I have to explain the difference at least. > > > > Simply put, the difference is that an existing DMV doesn't provide a > personal data disclosure API (such as /userinfo), while JWP/SD-JWT does (at > least, SD-JWT does). > > > > The former includes the case where the Issuer provides only a public key > (for example, via jwks_uri) to verify the signature of the issued data. > > A typical example is the digital COVID vaccination certificate in the > US. And I don't think that these cases are problematic. > > > > On the other hand, the latter(JWP or SD-JWT) assumes that the Issuer > will provide a personal data disclosure API, which returns JWP or SD-JWT > formatted data respectively, as a service. In this case, to my > understanding, the Issuer is a personal data controller and has to fulfill > various responsibilities for personal data management (**See question2 > mentioned in my first post**) and the Holder cannot act as other than a > proxy of the Issuer. > > I said that if you are arguing that the holder does not have to act as a > proxy for the issuer, please tell me the rationale (**See the response to > David's post**). > > Apologies Daisuke, I appreciate your effort to explain the difference but > I do not quite understand as JWT, SD-JWT, and JWP are all data formats. > > My existing process for getting a digital COVID credential (particularly > SMART Health Cards) was to have my pharmacy, my insurance provider or my > state government to vouch for vaccination data. This was a VC based on a > FHIR document of vaccine records, e.g. I was vaccinated at this time at > this organization with this vaccine purpose, variant/manufacturer, and the > lot number. > > It also includes identifying information such as my full name and date of > birth, as well as values which could be used for multi-party correlation > based on the record (if full name and birth date were somehow not enough to > do so) > > While having someone be able to get their own medical records like this is > empowering, the primary use case in people’s minds was to prove sufficient > vaccination for entry or participation in some activity. That did not rely > on giving nearly as much personal data. In addition, some of the data and > extra requirements of the system (e.g. to have someone show another form of > photographic identification with their full name) existed because the QR > code was just signed data and did not supply a way to show any additional > cryptographic proof that I was the subject of the credential. > > That lack of additional proof also meant there was no providence of the > record - not only could the recipient share information, but there was no > way to tell if there had been consent granted for them to do so. For > example, there was an app meant to verify the data in the credential and to > list the full name so that people could consume these credentials. However, > if I scanned a COVID credential using the built-in camera app on my phone, > it instead imported their health record and allowed me to present it in the > future. > > Different COVID credentials existed, with different capabilities. For > SD-JWT or JWP as a data format to replace the JWT credential above and to > solve these privacy concerns seems like a pretty clear data protection win. > > Would I be correct in assuming the concern is not in the data formats > themselves, but in the potential protocols being used to issue these > credentials? For instance, that they are issued interactively (via out of > scope protocols) and potentially refreshed (via an API), vs being a static > ‘vaccination certificate’ handed to the user in the form of a scannable > image? > > Or is the concern more that these types of data formats encourage the > ability for the data itself to be manipulated in certain ways in general, > e.g. by a holder agent to reduce the amount of information shared. The > concern then is that manipulation would cause the software holding the > credential to be considered a data processor with a relationship with the > original issuing authority under certain regulations, rather than merely an > agent under the user’s control? > > -DW > > > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
