Hi Daisuke, > Am 08.10.2022 um 23:31 schrieb AJITOMI Daisuke <[email protected]>: > > > 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?
QR Codes can be used in various different ways. In our design, we use the QR Code to render a request for credential presentation, which is scanned by the holder with the wallet app. This request is authenticated with a signature based on the verifier’s key material. After successful authentication, authorization, and consent the wallet sends the data to a HTTP endpoint to the verifier. > > 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. I agree, it’s basically the Holder that is offline. The degree of Internet connectivity needed on the Verifier end varies between use cases. The cryptographic validity of the credential can typically be validated with the credential presentation alone. There might be some DLT based approaches requiring access to the actual key material associated with a DID. With raw public keys or certs, this isn’t the case. Whether the credential was issued by a trusted issuer requires additional data, might be the issuer‘s public key as trust anchor or some kind of trust chain. This data can be cached or configured. If the credential can be revoked by the issuer, the verifier also needs to access revocation data. Whether this data can be cached depends on the revocation policy, i.e. how long it is acceptable until a change is put into effect. Whether the verifier needs to communicate with the issuer depends on the mechanism. OCSP alike mechanisms would require it. All other mechanisms I‘m familiar with can also be hosted someplace else. > >> 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. Look forward to see your follow up questions. best regards, Torsten. > > 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
