Data Retention Requirements

Abierto
  • ¿Algo no está bien?
#685 3 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Área
api, data

Línea de trabajo

Comienza revisando la Requirements API y la especificación de requisitos; después, lee las issues relacionadas #608 y #646 para conocer el contexto existente. El trabajo requeriría un modelo de retención definido que cubra los casos de uso indicados de agencias y operadores, y habría que actualizar la documentación de requisitos para definir el comportamiento resultante.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Policy privacy Requirements
Is your feature request related to a problem? Please describe.

With MDS 1.2 and the Requirements API, it is possible for the first time for Agencies to specify which data they need, and which data should not be shared. This is a major step forward for Data Minimization by allowing for the creation of best practices and example Requirements files that describe how to make minimal data requests for common use cases.

A related step I'd love to see MDS take is to describe data retention practices. This could cover some or all of the following capabilities:

  • Allowing Agencies to specify a minimum duration for data retained on operators' systems
  • Allowing Agencies to specify a maximum duration for data retained on their own (or a chosen aggregators') systems
  • Allowing operators to specify a maximum duration that they retain data and/or
  • Allowing Agencies to specify a maximum duration for data retained on operators' systems

These requirements could be expressed at the API, endpoint and perhaps even the field level. Here are some example use cases:

  • An agency specifies that they require status events to be retained by operators (ie queryable) for at least 6 months
  • An agency specifies that they will hold onto metrics data for up to five years, but will only hold onto disaggregate trip data for 1 month.
  • An agency interested in trying Geography Driven Events specifies that they will hold onto GDE event data for up to one year, and they will hold onto full event data for one month (to allow for the verification and evaluation of GDE data).

A note on aggregate data
My intention with this issue is to allow for explicit requirements around the retention of raw (particularly sensitive) data being delivered via MDS. This seemed like a good place to draw the line for now, but aggregate data can also sometimes be sensitive. It's an open, related question whether and how MDS might someday attempt to describe the retention of data that has been aggregated, analyzed etc.

Describe the solution you'd like

I'm imagining this as an extension to the Requirements API.

Is this a breaking change

Probably, insofar as it might allow for the creation of breaking requirements on operator implementations. Possibly this could be avoided with a conditional period, as we allowed for with Requirements in 1.2.

Impacted Spec

For which spec is this feature being requested?

  • requirements
Additional context

See also the #608 and #646.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
753
Forks
255
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openmobilityfoundation/mobility-data-specification

Todos los issues de openmobilityfoundation/mobility-data-specification

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.