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

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: blueroofmusic@gmail.com
<blueroofmusic@gmail.com>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Fri, Jul 3, 2020 at 5:21 AM Thomas Fossati <Thomas.Fossati@arm.com>
wrote:

> Hi Michael,
>
> Thanks for raising and articulating this point.
>
> On 01/07/2020, 02:54, "Michael Richardson" <mcr+ietf@sandelman.ca> 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.
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>