> > 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
