> 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
