Hi Orie, The concerns that I raised in this thread should originally be resolved before the W3C Verifiable Credentials WG was established, and I think it was out of place to mention them here. So I’d like to stop talking about this topic but:
Similar to how the DMV does not control your ability to present your > driver's license to 3rd parties Not similar. Completely different. If you are not aware of the difference and insist, "I (as a Holder) have the right to freely disclose the issuer's data (related to me) !!!!!!!!", then I have to explain the difference at least. Simply put, the difference is that an existing DMV doesn't provide a personal data disclosure API (such as /userinfo), while JWP/SD-JWT does (at least, SD-JWT does). The former includes the case where the Issuer provides only a public key (for example, via jwks_uri) to verify the signature of the issued data. A typical example is the digital COVID vaccination certificate in the US. And I don't think that these cases are problematic. On the other hand, the latter(JWP or SD-JWT) assumes that the Issuer will provide a personal data disclosure API, which returns JWP or SD-JWT formatted data respectively, as a service. In this case, to my understanding, the Issuer is a personal data controller and has to fulfill various responsibilities for personal data management (**See question2 mentioned in my first post**) and the Holder cannot act as other than a proxy of the Issuer. I said that if you are arguing that the holder does not have to act as a proxy for the issuer, please tell me the rationale (**See the response to David's post**). I believe that all you have to do is not to insist that "Issuer's data is mine!" without any rationale, but to provide the rationale I requested. No one has provided any evidence for this, at least so far. Finally, I am not adhering to my opinion. I am just asking for the rationale, and if someone can provide it, I can change my opinion. P.S. In my first post, I presented a simple solution to achieve both selective disclosure and its unlinkability while avoiding the underlying concerns I presented. I'd like to hear your opinion on that. Best regards, Daisuke 2022年10月14日(金) 0:39 Orie Steele <[email protected]>: > Inline: > > On Thu, Oct 13, 2022 at 8:26 AM AJITOMI Daisuke <[email protected]> wrote: > >> > 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. >> > > The key here is that the disclosure IS authorized, by the data holder... > they are the one that chooses to disclose... > > Similar to how the DMV does not control your ability to present your > driver's license to 3rd parties. > > Issuer's don't control data in the 3 party system, after the holder has > the credential, the holder can choose to disclose what they have / can > prove, based on what the issuer has allowed. > > The only control the issuer retains is revocation, or expiration. > > OS > > >> >> 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 >> > > > -- > *ORIE STEELE* > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries> >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
