Hi Torsten,
> The issuer is not involved (and perhaps wouldn’t even know the verifier). > >From the Issuer's perspective, this is simply "unauthorized disclosure”, right? The personal data handled in a system based on the Issuer-Holder-Verifier model is supplied by the issuer and the Issuer should still be the data controller. Could you please tell me on what basis such unauthorized disclosure is allowed? As I said in my email to David, I believe that the Holder can only be a proxy of the Issuer (a.k.a. data processor on GDPR) on the Issuer-Holder-Verifier model. Let me ask one additional question. In the digital driver license system, an Issuer is a driver license issuing and management service and a Verifier is a digital driver license reader app. Obviously it would be more natural for the Verifier to be the Issuer's RP but why does the Verifier need to be the wallet's RP and not the Issuer's RP? What exactly is the wallet in this example? I don’t understand how you came to that conclusion. Can you please explain? > Regarding case a), it is because, from my perspective that the Issuer must fulfill the responsibilities of the data controller even in the Issuer-Holder-Verifier model, the Issuer must be involved in the disclosure process, and providing a data disclosure API like userinfo by the Issuer (such as my counter proposal) is much more reasonable way than SD-JWT or JWP. Regarding case b), I think the reason is obvious. Best regards, Daisuke 2022年10月10日(月) 21:24 Torsten Lodderstedt <[email protected]>: > Hi Daisuke, > > Am 10.10.2022 um 05:41 schrieb AJITOMI Daisuke <[email protected]>: > > Hi Torsten, > > Thank you very much for your response in detail and sorry for taking your > time. > > First, I realized I had made a big mistake. I had assumed that the Holder > was supposed to show the QR code to the Verifier, but it was quite the > opposite! > > 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. >> > > > the wallet sends the data to a HTTP endpoint to the verifier. > > Well..., do you mean that the wallet must be online in your design? > > > That or the transaction is performed via BLE or NFC. > > > Anyway, in your design, I am assuming that each time the wallet discloses > the Holder's claims to the Verifier, it must pass the Verifier's client_id > to the issuer to get the verifier's public key for the validation of the > signature > > > Nope. In this model, the wallet is an OAuth AS. So the authentication > happens between verifier and wallet. The issuer is not involved (and > perhaps wouldn’t even know the verifier). > > , or pass the client_id and the public key to check if it is valid, is > this correct? In any OAuth flow, client authentication and authorization is > performed (or at least the validity of the client_id is checked) before > issuing the token. We can assume that the same level of security is > provided, correct? Since both the wallet and the Issuer are online. > > > the wallet sends the data to a HTTP endpoint to the verifier. > > At the very least, I have found that the Verifier must also be online and > have Web-PKI server cert and serve a HTTPS endpoint. And I have also found > the wallet (the holder) must leave access logs in the Verifier that it does > not originally need to leave at all, along with its user agent information. > > > I agree, it’s basically the Holder that is offline. > > But in your design, the issuer, wallet, and verifier must all be online, > right? Nevertheless, from my perspective that the Holder is merely a proxy > for the Issuer, > > > I think that’s the difference between our mental models. As stated above, > the wallet is an OAuth AS itself and does not need to interact with the > issuer - at least this is one of the benefits of issuing SD-JWTs in advance > and using it multiple times in comparison to a on-demand JWT issuance. > > the Issuer cannot prove that the holder has consented to the personal data > disclosure, including the content of that consent. > > > It doesn’t need to. > > > If all components are online, why can't a simple solution be adopted where > the issuer provides an endpoint (like /userinfo) for selective disclosure? > Do you really need SD-JWT? I'd like you to consider this in comparison to > my counter proposal. > > 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. >> > > I wrote most of what I wanted to say in my reply to David but, > > I think that the Holder can only be the "data processor" (acting on behalf >> of the controller) in the Issuer-Holder-Verifier model because the Holder's >> personal data was designed and created by the Issuer for its own service >> and clearly belongs to the Issuer as the data controller. "If issuance is >> just handing the subject of the information their data back", the Issuer >> should get the Holder's (user's) consent to process the data but it is not >> mandatory in GDPR. I think this fact is one of the proofs that the personal >> data belongs to the data controller under GDPR. >> > > This is case a). > > That might mean the wallet becomes a new “data controller” if it is hosted >>> software. >>> >> >> Yes, of course, through some delegation process, the wallet (wallet >> provider) could be a data controller. But in this case, the wallet should >> be regarded as an Issuer (IdP). I believe that this should not be >> considered an Issuer-Holder-Verifier model, but rather an existing 2-party >> model (IdP-RP) with the original Issuer decoupled. >> > > And this is case b). > > In case a) the Holder must act on behalf of the Issuer (and thus fulfill > various data controller responsibilities), while in case b) the original > Issuer should be decoupled. In both cases, the understanding is that the > JWP/SD-JWT are not helpful. > > > I don’t understand how you came to that conclusion. Can you please explain? > > best regards, > Torsten. > > > Best regards, > Daisuke > > > 2022年10月9日(日) 17:11 Torsten Lodderstedt <[email protected]>: > >> 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
