Re: [Rats] should Evidence containers be explicit about Personally Identiable Information?

[Laurence Lundblade <[e-mail]>]

What is PII and what is not PII is almost entirely dependent on the end-end use case and who the relying party is.

Illustrative example: The UEID (serial number) of a device is definitely PII when using a web browser to access multiple web sites, but it is not when a router is attesting to the network management center. Even the web browser case is not clear cut. The UEID (serial number) might not be considered PII when accessing a banks web site, because you’ve told the bank to “remember this device” (and the bank knows everything about you anyway).

I don’t think we can have a flag indicating which data is PII in Attestation Evidence/Results. I don’t think we can say that this particular EAT claim is PII and that one is not in any absolute sense.

We can’t assume that the Verifier will always be trusted with PII, because sometimes it is run by the relying party.  

On the other hand, sometimes the Verifier will be a highly trusted privacy proxy. It will receive claims that are not privacy-preserving and strip them out or otherwise anonymize them before sending on to the relying party.

I think at both the architecture and EAT levels, the best we can do is write privacy considerations — things that should be considered for particular deployments. Maybe future IETF standards that are very specific to use cases will be able to be more specific, but that’s for later.

Most of the text in section 11 of the -04 draft seems OK, but I think additional text like this is needed and hopefully addresses Kathleen’s comments.

Every claim in Attestation Evidence and Attestation Results is potentially PII (Personally Identifying Information) depending on the end-end use case of the attestation. Each deployment of attestation must take into account how each claim may or may not be used in a privacy violating manner by the relying parties receiving the attestation.

In cases where the device sending attestation is owned by the relying party, little to no consideration for privacy is needed. In other cases, such as when a mobile phone is used to access a large number of web sites, apps and services, privacy must be considered very thoroughly.

These are some strategies that can be used to address the privacy issue:

* Determine that a particular claim is not privacy violating in the limited context of use. For example, a router sending its serial number to the network management center that owns the router violates no one’s privacy.

* Simply omit the claim. For example, omit the serial number from attestations sent by a phone to web sites it connects to.

* Prompt the user. For example, ask the user if it is OK for a particular web site to access location data.

* Use a privacy proxy service between the device and the relying party to remove or anonymize the privacy violating claims.

Other strategies than these may be used. The selection of strategy is highly dependent on the relying party, end use case and governmental regulation (e.g., GDPR). The selection of strategy may also vary claim-by-claim in a single attestation.


LL