This is an interesting discussion on how higher level protocols might use this work. However that seems to be a bit out of scope for the topic at hand.
The decision to be made is if modifications to the existing JOSE container formats are needed to support the newer privacy-preserving signature algorithms that will be approved by the CFRG. I guess a legitimate position might be that the new algorithms somehow damage privacy or security, so JOSE should not support algorithms approved by the CFRG. People on the list argue that higher-level protocols would benefit from support for these algorithms like BBS+ in JOSE. So there seems to be demand. Is there a concrete argument for not allowing JOSE to be adapted to support the new algorithms? Remember the workgroup we are talking about chartering is neither approving the individual algorithms nor defining the legal policy structure for how there use in the EU. This is simply a container format exercise. I hope the Virtual BOF tomorrow can answer if this work needs to be done and if there are people interested in doing it. Regards John B. > On Oct 11, 2022, at 5:58 AM, Orie Steele <[email protected]> wrote: > > > 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 > <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/ > <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 > <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://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 > > <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/#subject-holder-relationships> > - https://www.w3.org/TR/vc-data-model/#holder-acts-on-behalf-of-the-subject > <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] > <mailto:[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] > <mailto:[email protected]>>: > Hi Daisuke, > >> Am 10.10.2022 um 05:41 schrieb AJITOMI Daisuke <[email protected] >> <mailto:[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] >> <mailto:[email protected]>>: >> Hi Daisuke, >> >>> Am 08.10.2022 um 23:31 schrieb AJITOMI Daisuke <[email protected] >>> <mailto:[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] >>> <mailto:[email protected]>>: >>> Hi, >>> >>> > Am 08.10.2022 um 08:26 schrieb AJITOMI Daisuke <[email protected] >>> > <mailto:[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] <mailto:[email protected]> >>> > https://www.ietf.org/mailman/listinfo/jose >>> > <https://www.ietf.org/mailman/listinfo/jose> > > _______________________________________________ > jose mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/jose > <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
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
