Hi David, Thanks for your "terse" reply :-)
This question is perhaps better served in another forum such as the openid > connect list, where the protocols for exchanging such messages are being > created as OAuth extensions. Sorry. I just want to say that both JWP and SD-JWT may not be necessary at all, but I have so much to say and it is taking a long time... In that sense, there’s an open question on whether the wallet is a “data > processor” (acting on behalf of the controller), or if issuance is just > handing the subject of the information their data back. > Ah, you seem to be aware of the essential issue behind my questions. You said what I was going to say before I did, 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. If you think that the Holder can be something other than a data processor (a proxy of the Issuer) in this Issuer-Holder-Verifier model, please provide a rationale. This is one of the things I most want to know. 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. The goal is to limit communication between the issuer and verifier to a > minimum. When they do communicate (such as to determine if a credential has > been revoked), it is almost the verifier fetching information from the > issuer, and such requests for information should not be about the > credential or the holder specifically. > Therefore, from my perspective that the holder can only act as a proxy for the Issuer (can only be a "data processor"), this goal is false and rather the Issuer should capture the disclosure transactions between the Holders and the Verifiers as much as possible and should take appropriate security measures to protect the issuer's personal data whenever possible. My counter proposal in my first post is not just an idea. I believe it is a relatively good way to achieve selective disclosure when the holder is offline (when the holder cannot do the OAuth dance), under the condition where the Holder can only act as a proxy of the Issuer. Could you comment on my proposal? (If needed, I can write more details about this proposal.) 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. > Best regards, Daisuke 2022年10月9日(日) 17:04 David Waite <[email protected]>: > > > On Oct 8, 2022, at 3:31 PM, AJITOMI Daisuke <[email protected]> wrote: > > Torsten: > >> 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? > > > This question is perhaps better served in another forum such as the openid > connect list, where the protocols for exchanging such messages are being > created as OAuth extensions. I’ll try to keep this terse here and encourage > the discussion to move to that other forum if possible. However, those who > know me have not to my knowledge described me as “terse”. > > A malicious verifier is an ambiguous concept - some consider multi-billion > and trillion dollar public companies to be malicious. Instead, let’s say > the wallet (as a holder’s user agent) is responsible for giving them an > informed choice as to who they are sharing data with, and maybe what that > party claims they will do with that data. > > Since the verifier is a client in an OAuth-based exchange, there is a > client identifier. There are other extensions (existing and proposed) which > can leverage this identifier to help reason about the verifier. > > One example is OpenID Federation, which defines a format (entity > statements) that contain not just operational metadata, but can be resolved > up a trust graph to trust roots. A wallet can use this to reason about > verifiers that it has never heard of before – if they chain up to a trust > root that the wallet knows of, it can present who the user is interacting > with a higher degree of certainty. > > Like OAuth, the client metadata contains operational metadata like > redirect_uri - even if a malicious party created a request that looked like > it was from a trustworthy verifier, the response is not sent to the > malicious party but to the verifier-controlled URI. > > However, since you brought up cross-device invocation with QR codes, there > is a risk that the malicious party will not generate a new URL/QR code > themselves, but rather display one that the legitimate verifier created as > part of an unauthenticated request. The malicious party initiates a > request, the verifier creates a QR code, which the malicious party shows to > an unsuspecting holder. They scan it with their device, and the user agent > represents it as being from the issuer. The user consents, which sends the > response back to the verifier with all the information, which gives the > malicious party (and not the holder) the benefits of the success. > > This is because QR codes do not allow for any sort of binding to a > communication channel. Since the request starts on one device and ends on > another, we do not have the typical technical mechanisms (like session > cookies) to detect this. > > Instead, other measures need to be taken. Asking the user to verify the > issuer identity matches what they expect is simple, but has been > insufficient to prevent phishing attacks in other venues. > > A more successful measure is to have application scenarios which > discourage such attacks, such as requiring phishing-resistant > authentication first before showing such cross-device QR codes. Additional > logic could also attempt to gain a confidence score that the two devices > are likely operated by the same person. > > 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. > > > “It Depends”. The goal is to limit communication between the issuer and > verifier to a minimum. When they do communicate (such as to determine if a > credential has been revoked), it is almost the verifier fetching > information from the issuer, and such requests for information should not > be about the credential or the holder specifically. > > Whether parties need to be online during credential issuance and > presentation is something that protocols and credentials are designed for. > > There are certainly use cases (such as those in ISO 18013-5) where fully > offline behavior between a holder and verifier is essential. This is > because losing internet access cannot result in loss of services or rights, > such as whether to operate a motor vehicle or (in the US) to identify > yourself to get through a certain transportation checkpoints. > > For credentials which are actively being issued by an issuer as part of an > ongoing relationship, one can ‘vend’ a number of credentials for future > use, refetching if one runs low or credentials expire. Depending on the > validity time frame, some communication (such as revocation checks) might > no longer be required. > > SD-JWT, as a single-use-unlinkable credential is somewhat optimized for > this usage. A single-use-unlinkable credential means you restrict yourself > from presenting it multiple times - not for security reasons but for > privacy/correlation reasons. In addition to correlation via values like > ‘jti’ or ‘exp’, the cryptographic signature itself is a correlation handle. > > JSON Web Proofs has a goal to also define multi-use-unlinkable credentials > leveraging newer cryptographic techniques - while the attributes being > released might be usable for correlation, the cryptography itself cannot > be. This makes things significantly more complex, but potentially allows > for anonymous credentials which might outlast the issuers who created them. > > 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. >> > > 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. > > > “Data controller” in the EU is a term used to define the obligations under > the GDPR. In that context, it is more about the ‘why’ you retain and > process data affecting the ‘how'. > > In that sense, there’s an open question on whether the wallet is a “data > processor” (acting on behalf of the controller), or if issuance is just > handing the subject of the information their data back. That might mean the > wallet becomes a new “data controller” if it is hosted software. > > That said, if you are thinking of the term “personal data controller” to > mean something different, clarifying that may help us answer your question. > > -DW >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
