> Hope you can make the call today. Sorry, it was too hard for me to attend the meeting at 2am JST.
I don't know what kind of discussion took place at the BoF last night, but let me add a few things: I knew that the SD-JWT was out of scope so I was not going to object to the reopening of the WG because of the concerns about the SD-JWT. I said that I had no capacity to disagree with the adoption because I don't know JWP well. However, if many other people say that the JWP depends strongly on the Issuer-Holder-Verifier model, then I must disagree with the adoption, as well as JD-JWT. I believe that the specification that can encourage unauthorized data disclosure should not be standardized by the IETF. Best regards, Daisuke 2022年10月12日(水) 23:09 John Bradley <[email protected]>: > Thanks for the response. > > JWT—SD is not part of this proposed work. > > We are aware of that work and the proposed charter notes that liaison will > happen between the groups. > > Hope you can make the call today. > > John B. > > Sent from my iPhone > > On Oct 12, 2022, at 4:48 AM, AJITOMI Daisuke <[email protected]> wrote: > > > >> However that seems to be a bit out of scope for the topic at hand. > > > You are right, I was only pointing out that the higher level protocols > using JWP/SD-JWT, which are based on the Issuer-Holder-Verifier model, have > fundamental problems. In fact, the I-H-V model itself is the problem though. > > Anyway, since SD-JWT seems to assume only the I-H-V model, I must strongly > oppose proceeding with this standard as is. > > On the other hand, I cannot judge whether JWP is based on only the I-H-V > model. At least I cannot prove that it depends on the I-H-V model. > ...I don't know what I am talking about, but using JWP may make the > implementation of predicate-based disclosure easier, etc. > > > Is there a concrete argument for not allowing JOSE to be adapted to > support the new algorithms? > > Thus, I cannot disagree with the adoption, at least from my perspective in > this thread. > > If I could make one request, I would like to see the JOSE WG reopened > instead of creating a new JWP WG. > > Best regards, > Daisuke > > 2022年10月12日(水) 1:23 John Bradley <[email protected]>: > >> 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 >> >> 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 >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
