-Can the expiry date be modified?
-Is the expiry date explicitly owned by the owner, ie can anyone else
change the expiry date?
-Should there be a default expiry date if the owner doesn't assign one
upon creation?
-Can the expiry date be changed after a record has already past the
expiry date? ie Can i set the expiry date to tomorrow, and then
tomorrow change the expiry date to two weeks from now, or even the day
after tomorrow?
-Does the host provide the expiry date based on the conflict/disaster
circumstances or does the individual giving their data provide the
expiry date?
Here is the relevant text from http://zesty.ca/pfif/1.3/#data-expiry:
3.3. Data expiry mechanism
If present, the expiry_date field indicates when a record should be
deleted to preserve the privacy of the personal information it
contains. Conforming PFIF implementations must meet the following
requirements:
-Within one day after expiry_date, a PFIF repository must make the
contents of the PERSON record and any associated NOTE records
inaccessible to all external clients, including users and machine API
clients.
-Thereafter, if the repository exports its data through an API, it
should continue to export a placeholder record in the place of the
expired PERSON record. This placeholder should have the same record
identifier, keep the same expiry_date value, and have both source_date
and entry_date set to the time that the placeholder was created. All
other fields of the placeholder record should be present and empty.
-Within 60 days after expiry_date, a PFIF repository must permanently
and unrecoverably delete all local copies of the data in the PERSON
record and any associated NOTE records.
A PFIF repository can delete an existing original record by updating
the record and setting its expiry_date, source_date, and entry_date to
the current time. The expiry mechanism described above would then
cause this deletion to propagate to other conforming PFIF
repositories.
On Thu, Feb 10, 2011 at 5:36 PM, CrisisCommons <crisis...@gmail.com> wrote:
>
>
> Begin forwarded message:
-Can the expiry date be modified?
-Is the expiry date explicitly owned by the owner, ie can anyone else
change the expiry date?
-Should there be a default expiry date if the owner doesn't assign one
upon creation?
-Can the expiry date be changed after a record has already past the
expiry date? ie Can i set the expiry date to tomorrow, and then
tomorrow change the expiry date to two weeks from now, or even the day
after tomorrow?
-Does the host provide the expiry date based on the conflict/disaster
circumstances or does the individual giving their data provide the
expiry date?
I tent to agree with Jim. In the old version of Sahana at least we tried to incoorporate different data sensitivity classifications http://wiki.sahanafoundation.org/phase2/doku.php/dev:security and our security access mechanisms were based on these classifications. However in hindsight we probably implemented too many classifications, when something a little simpler would have been sufficient to propagate the level of sensitivity of that record.
Also to Tim's point on enforcing a contract on expiry would be most welcome in the spec and it would be a good interop test to certify systems that fully implement that contract. For the same reasons as above the source organization has to have the ability to remove or change replicas of their data on the web.
Hello Chamindra,Thanks for the feedback.On Fri, Feb 11, 2011 at 10:10, Chamindra de Silva <cham...@opensource.lk> wrote:On the issue of sensitivity classifications, I think they would only be useful if we had agreed-upon, actionable meanings for the classifications. I'm open to discussing this for a future version of PFIF but would rather not hold back PFIF 1.3.
I tent to agree with Jim. In the old version of Sahana at least we tried to incoorporate different data sensitivity classifications http://wiki.sahanafoundation.org/phase2/doku.php/dev:security and our security access mechanisms were based on these classifications. However in hindsight we probably implemented too many classifications, when something a little simpler would have been sufficient to propagate the level of sensitivity of that record.
Also to Tim's point on enforcing a contract on expiry would be most welcome in the spec and it would be a good interop test to certify systems that fully implement that contract. For the same reasons as above the source organization has to have the ability to remove or change replicas of their data on the web.I agree that this makes a good interoperability test. In the new draft, section 3.3 (Data expiry mechanism) specifies a set of requirements that PFIF repositories must fulfill for handling deleted/expired data; do you see any problems with it?