> the Issuer must be involved in the disclosure process, This is exactly the kind of privacy issue the 3 party system is trying to improve on.
I don't need the department of motor vehicles with me, when I prove my age to buy an age restricted beverage. I don't need their permission to disclose my age, from a credential they issued.... they should not know what they don't need to know. The issuer is a data controller. The holder is often both a data controller and a data subject. > providing a data disclosure API like userinfo by the Issuer I don't agree that providing an API is more reasonable than providing a data format that supports disclosure. (JWP, SD-JWT, Merkle Proofs, various ZK formats including snarks, starks, etc...) That being said, I have built such an HTTP based API for BBS+ Linked Data Proofs, where a subset of an RDF graph is obtained from the issuer's signature over the original RDF graph. https://w3c-ccg.github.io/vc-api/#derive-credential warning this is all fairly old, before the work moved to CFRG: https://w3c-ccg.github.io/ldp-bbs2020/ The query format (uses JSON-LD Frame): https://w3c-ccg.github.io/vp-request-spec/#query-by-frame (alternative https://identity.foundation/waci-didcomm/v1.0/#deterministic-rendering-of-the-json-ld-frame-object ) https://github.com/transmute-industries/verifiable-data/tree/main/packages/bbs-bls12381-signature-2020 ^ The signature format has since been changed, and there is code rot here now. Having the issuer present in all presentations made by a holder essentially removes the autonomy of the holder... it defeats the value of the 3 party system (which might not be the right system for all use cases anyway). It's also related to these sections: - https://www.w3.org/TR/vc-data-model/#subject-holder-relationships - https://www.w3.org/TR/vc-data-model/#holder-acts-on-behalf-of-the-subject Regards, OS On Mon, Oct 10, 2022 at 2:45 PM AJITOMI Daisuke <[email protected]> wrote: > 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 > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
