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

[Michael Richardson <[e-mail]>]

Thomas Fossati <[e-mail]> wrote:
    > 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...

    > 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.

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?

    > 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?

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.

    > 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.

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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-