Privacy

["Sakimura, Nat" <n-sakimura@nri.co.jp>]

Title: メッセージ

Allow me to think loud in this mailing list.

It is a privacy issue which should/should not be involved in XRI requirements.

 

At the F2F meeting I was convinced that given appropriate plug-in architecture for the security provision, this issue could be largely deferred to the follow on TCs. I am not so sure now.

 

Let me first define "Privacy data". According to EU directive and Japanese Privacy act (both are derived from OECD privacy principles so are very similar), it is "Any data stored in relation to a personally identifiable data." An example of personally identifiable data is the combination of a person's last and first name in a certain context.

 

XRI requirement for the Human readability probably implies that there will be a XRI reassign able identifier that is very similar to a person's real name. Then, any bits resolved using this human readable identifier and thus stored with this identifier (e.g., permanent identifier stored with human readable identifier) is likely to be categorized as "Privacy data".

 

Once it becomes a "Privacy data", it needs to fulfill bunch of requirements from the EU directive etc. XRI probably needs to be able to cater such requirements.

 

Some of the prime example of such requirements are:

 

- Any collection of privacy data must be done with the pre-declared and agreed to purpose statement.

- A person  can decline the request for the data.

- A person can ask the other party to disclose what data the party holds about the person.

- A person can ask the party to remove any specific data about him, and the party must comply with it.

- Audit traceability is required and access log to the privacy data must be kept to ensure that any illegal data usage can be tracked.

 

These seem to require couple of things to XRI (and follow ons):

 

- Rudimentary contract framework : Required for the pre-declaratin of the purpose statement and the consent to it.

- Access control based on the contract

- Data removal request message format

- Standard access/audit log for the resolution.

 

My question is: "Is it really possible to push all these to follow-on TCs without taking at least some consideration in the basic addressing and resolution framework that current TC is trying to tackle?"

 

Your input is much appreciated.

 

Regards,

 

--

Nat Sakimura, Nomura Research Institute.
xns name: =sakimura email: n-sakimura@nri.co.jp
http://www.marimba.org/~sakimura/blog/