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

[Ira McDonald <[e-mail]>]

Hi Laurence,

+1 to your whole rationale and suggested text.

Cheers,
- Ira


*Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted
Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*








*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [e-mail]
<[e-mail]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*


On Wed, Jul 8, 2020 at 3:38 PM Laurence Lundblade <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>