Exposing timezone in timestamps - privacy concern?

[Vladimir Dzhuvinov]

To file the comment I made the other day in the F2F meeting.

Our concern was that TZ info in timestamps may give away additional information about the user that’s not really required for the purpose of timestamps.

Torsten made the comment - about about passports, ID cards and similar proofs which presumably are issued in jurisdiction specific calender time. There I don’t find an issue with having a TZ.

I.e. for some types of data a TZ may be useful, for others not really necessary. The task would be to determine where or to spell out a general rule.

[Torsten Lodderstedt]

are you suggesting to use normalised time data (UTC) to increase privacy?

[Joseph Heenan]

Torsten made the comment - about about passports, ID cards and similar proofs which presumably are issued in jurisdiction specific calender time. There I don’t find an issue with having a TZ.

Dates (e.g. date_of_expiry on passports) appear to be timezone-less in the current draft, and that seems correct to me.

It’s properly an overly technical detail, but I believe calculations on these dates are always done ignoring timezones (as opposed to in the timezone of the issuer), i.e. a UK (UTC+0… ignoring daylight savings) passport with expiry date 2020-31-12 presented in San Francisco (UTC-9) is valid until the end of day local time where it is presented, i.e. in San Francisco the document is valid until 2021-01-01T09:00Z.)

‌

[Joseph Heenan]

For actual timestamps, I think I’d tend to agree that always presenting them in UTC makes sense, i.e.  ISO 8601:2004 [ISO8601-2004] YYYY-MM-DDThh:mm:ssZ format - if there’s a need to communicate a location or other information about the verification this should be done separately.

[Torsten Lodderstedt]

I suggest to add a remark to the privacy considerations but not make it a mandatory requirements.

[Vladimir Dzhuvinov]

Yes, my suggestion was to consider using UTC (Z), unless there is a good / compelling reason to include a TZ.

How about following “should” in the privacy considerations:

Timestamps with a time zone component can potentially reveal the person’s location. To preserve the person’s privacy timestamps within the verification element and verified claims that represent times SHOULD be represented in Coordinated Universal Time (UTC), unless there is a specific reason to include the time zone, such as the time zone being an essential part of a consented time related claim in verified data.

Privacy is becoming an increasingly important concern and it would help to get trust framework designers to consider the time zone aspect of times / timestamps in the verification element and in time claims.

[Torsten Lodderstedt]

please review https://bitbucket.org/openid/ekyc-ida/pull-requests/21/incorporated-vladimirs-proposal-and/diff

[Torsten Lodderstedt]

PR merged