xri message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Privacy
- From: "Sakimura, Nat" <n-sakimura@nri.co.jp>
- To: xri@lists.oasis-open.org
- Date: Thu, 27 Mar 2003 09:44:33 +0900
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,
--
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]