> On Oct 9, 2022, at 8:49 PM, AJITOMI Daisuke <[email protected]> wrote:
>
> Hi David,
>
> Thanks for your "terse" reply :-)
No problem!
> 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.
At the end of the day, something like a JWT is just integrity protected data. I
expect it to have the complexity and nuances of non-integrity-protected data,
with the added wrinkle that some right-to-be-forgotten efforts may be muddled
by non-repudiation.
There are features to export a copy of your own data; having them be in the
formed of signed statements arguably isn't a big reach.
There are plenty of sites which share information about people (such as social
media feeds and public profiles). Having these available for other parties than
the subject in the form of signed statements also also arguably isn't a big
reach.
One of the values of having a user-controlled agent with integrity-protected
data would be to try to get the user to decide who should be a data controller,
rather than the issuer having to be controller to a limitless number of
processors. Managing those sorts of relationships has been feedback I’ve heard
as to why OAuth and OpenID Connect services had less uptake in public
government services. Have the user just decide where they want to share a
document themselves “air gaps” them from several technical, privacy and
political issues.
>> 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.
Issuing authorities are trusted (through traditional models - e.g. direct,
brokered, or indirectly brokered trust) to make certain claims about a subject.
An organization which provides a wallet can also be an issuing authority -
although like privacy pass scenarios, having multiple roles be provided by the
same entity has a significant privacy impact.
A self-hosted wallet is not really trusted; it can help the user to self-assert
claims, but those have been shown to be more difficult to rely upon (at least
without a reputational trust system.)
>> 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.
I would agree with your conclusions - if holders are legally only able to be
classified as data processors under the issuing authority as a data controller.
That sort of legal responsibility could dramatically change architectural
requirements by the parties.
However, I don’t believe the holding agent will typically be a data processor -
similar to how my browser doesn’t become a data processor when I download a ZIP
file, and why that site doesn’t have to start worrying about traceability on
that ZIP file and its contents after it was downloaded. Change that scenario so
the recipient is a third party and make the ZIP of medical records, and all of
a sudden the technology protocol and data formats will have quite different
regulatory requirements.
Apologizing for being vague here; I’m hitting the edge of my understanding on
current interpretation of GDPR and similar regulations.
-DW
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
