[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Privacy
Nat, It's a
great question. The XRI TC has the requirement to ensure that the XRI syntax does
not REQUIRE identifiers that will reveal personally-identifable data. But this
requirement is not hard to fulfill. For example, the use of a completely
non-semantic identifier (for example, a UUID) would not require the use of any
personally-identifiable data. But your
use case, where a human-readable identifier that contains
personally-identifiable data (such as a person's real-world name) is coupled
with a permanent identifier, is indeed a data structure that would fall under
the EU Directive and Japanese Privacy act. And I'm sure there are many other examples
of how human-readable semantic identifiers could be used to reveal personally-identifiable
data. The question is whether mechanisms for controlling the privacy or
security of such data should be in the scope of the XRI TC. My own
point-of-view (and it's just one) is that we should limit the scope of the XRI TC
to defining syntax and a basic resolution mechanism that may not fully address
secure resolution or privacy-protected resolution because, as you say, those
issues may not be solvable without specifying XRI data interchange mechanisms. And
we agreed at the f2f that this would be the focus of the follow-on TC. So it's
looking like that TC will need to form sooner rather than later. I've had this
conversation with several other TC members who feel the same way, so we'll need
to start looking at creating the charter pretty shortly. Best, =Drummond -----Original
Message----- 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]