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

From: Thomas Fossati <[email-masked]>
Date: Fri, 3 Jul 2020 09:20:50 +0000

Hi Michael,

Thanks for raising and articulating this point.

On 01/07/2020, 02:54, "Michael Richardson" <[email-masked]> wrote:
> I had asked in my aside, if the *ARCHITECTURE* document should create
> a requirement on Evidence (such as EAT) that it should *explicitly*
> flag when it contains PII.
>
> [...]
>
> So part of my question was should we debate this now, and make this an
> architectural requirement for all containers?

Personally, I am not convinced that an in-band pii flag is needed.

On the Attester side, the privacy problem can be addressed by an
attestation API that allows the caller to selectively turn off claims
that are PII -- either with per-claim switches, or by presenting
pre-canned PII-revealing and PII-hiding interfaces to the Evidence
generation service. We expect the attesting endpoint to make the right
decision about what can be hidden and what needs to be revealed
depending on context.

On the Verifier side, I'd expect that the log/audit anonymisation and
retention policies for Evidence are an integral part of the service
configuration.  So, no need for an in-band signal about what is to be
considered PII since the Verifier is going to be made aware of it by
some out-of-band means.

That leaves the RP, which I'm not fully sure about.  However, my gut
feeling is that the Attester will have to trust the RP to do the right
thing since no in-band pii flag will ever be able to restrict what a
malicious RP can do with the obtained PII.

Am I missing anything?

cheers, t

PS: Maybe there is a requirement for EAT profiles to specify in their
privacy considerations what claims are PII and what is the expected
treatment by actors in the attestation chain.  This is EAT's job, not at
the architecture doc level though.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Ira McDonald <[email-masked]>
Date: Fri, 3 Jul 2020 14:33:39 -0400

Hi Thomas,

+1

Only the Attester (with advice from the real human owner/user and/or system
administrator) can decide what is actually PII.  Various standards and
regulations
have failed miserably to crisply define what is PII.

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: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Fri, Jul 3, 2020 at 5:21 AM Thomas Fossati <[email-masked]>
wrote:

> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 04 Jul 2020 19:11:18 -0400

> Personally, I am not convinced that an in-band pii flag is needed.

Just to be clear, the alternative is an out-of-band PII flag, which is to
say, a configuration on the Verifier for that claim.

This implies that the Verifier always knows all the claims that it will
receive, and that Verifiers and Attesters are never upgraded
out-of-sequence.

Remember that some of this question came up because we were discussing
whether a Verifier would have to provide Evidence as to it's trustworthiness
to the *Attester* before the Attester would trust it with PII Evidence.

Now, consider that we have some use cases for mutual Attestation (Hi Guy!)
and, and maybe we wind up with another way in which to deadlock...

    > decision about what can be hidden and what needs to be revealed

Yes, but that's not really the point.
It's not that the Attester code base does not know which claim contains PII
or not, it's that it doesn't know if it can rely upon the Verifier to do
the right thing.

Can this even work across legal jurisdictions with different requirements and
mandates?

    > Am I missing anything?

I think that up to know there has been a single vertical of Attester/Verifier/RP
being all built by the same vendor.  Things like changes to what is PII,
or introduction of new claims could be coordinated internally.

As we move towards a multi-vendor situation the rollout of new claims will
occur in an unpredictable way.

    > the architecture doc level though.

I'm okay if the answer is that EAT will include some kind of flag, but
that we don't have to assume it exists at an architectural level.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 04 Jul 2020 19:14:09 -0400

> have failed miserably to crisply define what is PII.

*WHAT* is PII is not at all relevant.
  I'm not asking for any determination of that, and if you got that impression,
  then I have failed to present the discussion well.

I am asking the question,
    [having determined that something is (or isn't) PII, ]
does the Attester need a way to signal this in-band to the Verifier?

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 6 Jul 2020 09:25:48 +0000

Hi Michael,

On 05/07/2020, 00:11, "Michael Richardson" <[email-masked]> wrote:
> As we move towards a multi-vendor situation the rollout of new claims
> will occur in an unpredictable way.

Maybe the privacy dual of EAT's "MUST ignore unknown claims" is: "apply
the same privacy policy you'd use for PII claims to claims that you
don't understand"?

> > PS: Maybe there is a requirement for EAT profiles to specify in
> > their privacy considerations what claims are PII and what is the
> > expected treatment by actors in the attestation chain.  This is
> > EAT's job, not at the architecture doc level though.
>

What about:

1. EAT requires its profiles to explicitly highlight any potential PII.
   This will inform the privacy behaviour of the Verifiers that decide
   to support a certain profile.
2. For *unknown* claims included in Evidence that is produced according
   to a given profile, the requirement for the Verifier is to treat
   those unknown claims as PII.

Cheers, t

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Jul 2020 12:51:50 -0400

> the same privacy policy you'd use for PII claims to claims that you

Ys, that sounds like it will work in an acceptable way.

The parable of the lighthouse vs warship returns though: the lighthouse does
not in way consider it's location to be PII.
Yet the tourist's smartphone at the lighthouse does consider it PII.

    > those unknown claims as PII.

I think that this probably errs in the correct direction.
Do you think that statement #2 is an architectural statement that must be
applied to all conveyances?

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 7 Jul 2020 08:30:41 +0000

Hi Michael,

> applied to all conveyances?

I'd think so.

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 8 Jul 2020 12:38:43 -0700

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

---

From: Ira McDonald <[email-masked]>
Date: Wed, 8 Jul 2020 18:02:38 -0400

Hi Laurence,

+1 to your whole rationale and suggested text.

Cheers,
- Ira

On Wed, Jul 8, 2020 at 3:38 PM Laurence Lundblade <[email-masked]>
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.
>
> * 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.
>
> * 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
>