Fwd: New draft of PFIF 1.3 specification, dated February 10

[CrisisCommons]

Begin forwarded message:

From: Ka-Ping Yee <k...@google.com>

Date: February 10, 2011 8:05:45 PM EST

To: pf...@googlegroups.com

Subject: New draft of PFIF 1.3 specification, dated February 10

Hello everyone,

Thank you for your continued feedback on PFIF.  A new draft of the PFIF 1.3 specification is now available here:

    http://zesty.ca/pfif/1.3

Please reply to the public PFIF list, pf...@googlegroups.com, with your thoughts and concerns.  If you see no concerns with it, that feedback is useful too.  (Note that this message is being copied to a few other lists, so be sure to address your feedback to pf...@googlegroups.com.)

The major change in this draft is that it explicitly permits the original repository to change an existing record.  This is necessary so that the original repository can make corrections to incorrect data, and also so it can expire or delete an existing record.

My target date for freezing PFIF 1.3 is one week from today.  If you have any comments, please send them in before 17:00 PST, Wednesday February 16.

Thank you!

—Ping
Google Crisis Response

[Tim Schwartz]

Sorry for the mass email, I thought it was important to copy in the
relevant text from the PFIF 1.3 Draft dealing with expiry date and
bring up a few points.

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

[Ka-Ping Yee]

Hi,

I've responded to Tim's questions on the PFIF list; please see http://googlegroups.com/group/pfif .

—Ping
Google Crisis Response