Hi Torsten, Thanks for your quick response.
Verifier authentication and authorization is the task of the wallet (on > behalf of the holder). How authentication/authorization is performed > depends on the protocol for credential presentation. In case of OpenID 4 > Verifiable Presentations (which is OAuth based), the verifier is identified > via its client id and authenticated using one of the various OAuth > mechanisms. > I just want to understand correctly what you are talking about, so could you please answer me more specifically by using a specific use case (QR-code)? In the use case where a Holder discloses some claims as a SD-JWT to a Verifier via QR code, is there any way to prevent or mitigate disclosure by mistake if the Verifier is malicious? I'd like to know a specific way for the wallet (on behalf of the Holder) to confirm the validity of the Verifier before showing the QR code. ... or is the QR-code use case out of scope? As I mentioned in the previous post, I believe that in the selective disclosure transaction on the Issuer-Holder-Verifier model, only a Holder can be offline, while an Issuer and a Verifier must be online (the Verifier must be able to access the Issuer), is this understanding correct? If it is not correct, again, I'd like to know a specific way by which the Holder confirms the validity of the Verifier before the disclosure, without the communication between the Verifier and the Issuer. Excellent question! I’m not a lawyer (and this a legal question). What I > assume is > a) either the wallet provider acts on behalf of the issuer under a data > processing agreement or > b) the wallet provider becomes another data controller after the user > consented with the transfer of the credential to the wallet. > This question is not from a lawyer's perspective but from the perspective of an engineer/operator who has to manage personal data though. I have a lot to say in response to this answer of yours, but I would appreciate it if you could answer the above questions first. Best regards, Daisuke 2022年10月8日(土) 18:24 Torsten Lodderstedt <[email protected]>: > Hi, > > > Am 08.10.2022 um 08:26 schrieb AJITOMI Daisuke <[email protected]>: > > > > > > Hi folks, > > > > I could be making a big mistake but I don't really understand the need > for JWP or SD-JWT. > > > > Let me ask two questions about the Issuer-Holder-Verifier model that JWP > and SD-JWT are premised on. > > > > 1. How does a Holder confirm the validity of a Verifier before the > selective disclosure? > > > > In the typical use case where a Holder selectively discloses some claims > to a Verifier using a QR code or NFC, is there any way to prevent or > mitigate disclosure by mistake if the Verifier is malicious or infected > with malware? It is impossible for a user to visually determine whether the > QR code reader device (or app) is malicious or not. > > > > In order to confirm the validity of the Verifier (as in the general > OAuth flow), I suppose that the Verifier must be authenticated by the > Issuer each time before the Holder's claims are disclosed. At least, it > looks to me that SD-JWT is a dangerous solution because it discloses > linkable personal data without any Verifier validation. > > It is important to notice that in the verifier/holder/issuer (aka > Verifiable Credentials model aka decentralized identity model) the issuer > needs to rely on the wallet (provider) to handle the credential/claims > disclosure properly. The issuer should therefore validate the wallet and > its security and privacy mechanisms before issuing a credential. > > Verifier authentication and authorization is the task of the wallet (on > behalf of the holder). How authentication/authorization is performed > depends on the protocol for credential presentation. In case of OpenID 4 > Verifiable Presentations (which is OAuth based), the verifier is identified > via its client id and authenticated using one of the various OAuth > mechanisms. > > > > > 2. How does an Issuer fulfill its responsibility as a personal data > controller? > > Excellent question! I’m not a lawyer (and this a legal question). What I > assume is > a) either the wallet provider acts on behalf of the issuer under a data > processing agreement or > b) the wallet provider becomes another data controller after the user > consented with the transfer of the credential to the wallet. > > best regards, > Torsten. > > > > > My understanding is that the Issuer is responsible for the Holders' > personal data management because the Issuer is providing selective > disclosure of the personal data as a service. This means that the Issuer > can be regarded, for example, as a 'controller' as defined in GDPR. At this > time, the Issuer has various responsibilities regarding the protection of > the personal data. The following is a partial list: > > - Record and maintain logs of the data disclosures to third parties (the > Verifiers) for a certain period of time. > > - Notify a supervisory authority of the scope of impact and > countermeasures in the event of an incident, such as a personal data breach. > > - Demonstrate that the Holder has consented to the disclosure of his or > her personal data. > > - etc. > > > > In this Issuer-Holder-Verifier model where an Issuer is not necessarily > involved in the disclosure transaction between a Holder and a Verifier, how > does the Issuer fulfill the above responsibilities? I suppose that in order > to preserve the audit log containing the Holder's consent in a manner that > even the Holder cannot repudiate, the Issuer would have to be involved in > the disclosure transaction each time, similar to question 1. > > > > I have seen some people say that it is a kind of privacy invasion for an > Issuer to be able to track every disclosure transaction by a Holder, but I > think that is false. The Issuer is recording the transaction data for > compliance with a legal obligation as a personal data controller, and any > deviation from this should be prohibited by law. I think that preventing > data breach to malicious or compromised Verifier is much more privacy > protective. > > > > Anyway, my point is that in light of the obvious security measures that > an Issuer should take (Question 1) and the general personal data protection > legislation (Question 2), in the selective disclosure transaction, only a > Holder can be offline, while an Issuer and a Verifier have to be online. > > > > If this assumption is correct, then neither JWP nor SD-JWT is necessary, > and the solution to be adopted may vary greatly. > > > > For example, a solution where (1) a Holder generates and passes to a > Verifier an short-lived token indicating the user's consent to the > selective disclosure protected by end-to-end encryption between the Issuer > and the Holder, and (2) the Issuer provides endpoints for the selective > disclosure that requires the short-lived token and Verifier authentication > is simpler and more secure than JWP or SD-JWT. It is also more compliant > with a general personal data protection regulation. Furthermore, in the > end-to-end encryption, the Holder generally uses an ephemeral public key so > the unlinkability of the disclosed claims is also achieved naturally. > > > > I would appreciate your feedback on the above. > > > > Sorry for the long post. > > > > Best regards, > > Ajitomi, Daisuke > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
