Web conference notes, 2020.10.15 (Joint Working Group City Services)

Joint Working Group - City Services

Meeting ID: 671 331 832 - https://zoom.us/j/671331832

One tap mobile: +19294362866,,671331832# US

Dial by phone: +1 929 436 2866 (US) (Find your local number)

Attendees

Add your own name, link, and organization during call

Notes and or transcript of the call with presentation, document, GitHub links and calls to action.

Metrics

See previous presentation on this
Authorization should be the same as Agency, eg JWT.
Scenarios:
- Cities can serve API to expose aggregated report data to trusted parties: eg, departments with their city, researchers.
- Cities can serve API to provide data back to Providers to ensure alignment on counts for billing, enforcement, policy alignment.
- Providers can serve API to cities. Bird asked for this previously. Note this would not be a replacement for /trips. (In addition, Special Groups can be used for this.)
Need to add the above clarifications to the proposal, including who hosts the file in which scenario.
Add not saying this does not replace the requirement for disaggregated data, but it may solve some of the same use cases.
Cities can opt into the Metrics endpoint from Providers
Need to talk this conversation to other OMF committees. Will present to Privacy Committee at meeting next Wednesday. Will discuss at WGSC Checkpoint next Friday.

Special Groups

See previous doc about this
From Spin: providers are already sending this data and more to cities in spreadsheets, in different formats and methods and report formats
This data will not be added to the raw trips endpoint
Will be incorporated as part of the core metrics
We should call out in the spec that application of this data should be tied to specific use cases.
K-anonymity values should be across all of Metrics to limit reidentification risks.
OMF will establish a minimum in the spec. Maybe different values with different metrics? Spacial/temporal difference of a city can affect values
Spin, E&A, and OMF can work on proposed values.
No field will be in the spec to pass in a k-value, but maybe the k-value can be returned in the payload so consumers know what it is for that request
Low income only for this release. Adaptive vehicles, students, unbanked, subscribers, access methods, etc are other possible future groups, but may have so few trips as to not appear in most requests due to k-value limits.
Spin + San Francisco can come up with a example use cases for adaptive vehicles in the future, showing how and why that's measured and how the data could be used. Could be part of webinar or blog post with more details.