Data Retention Requirements

Aperta
  • Qualcosa non va?
#685 3 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Ambito
api, data

Direzione di ricerca

Inizia esaminando la Requirements API e la specifica dei requisiti, quindi leggi le issue correlate #608 e #646 per conoscere il contesto esistente. Il lavoro richiederebbe un modello di conservazione definito che copra i casi d’uso indicati delle agenzie e degli operatori, oltre all’aggiornamento della documentazione dei requisiti per definire il comportamento risultante.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Nessun dato sulla lingua
Stelle
753
Fork
255
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openmobilityfoundation/mobility-data-specification

Tutte le issue di openmobilityfoundation/mobility-data-specification

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.