mobility-data-specification
mobility-data-specification copied to clipboard
Authorization Consistency Across MDS
Is your feature request related to a problem? Please describe.
Currently each MDS API has its own descriptions of authorization methods and options.
Provider: Entire Auth.md page with JWT recommended
Agency: Authorization section that requires JWT
Policy: Authorization is not mentioned
Geography: Authorization section and bearer token language with public option
General Information: Authorization is not mentioned
Describe the solution you'd like
These disparate authorization descriptions should be consolidated across MDS and likely put into the General Information page with sections for JWT. The content from Provider could be a starting point, with additional subsections around optional JWT auth, public feeds, etc. Then each API can reference and link to the appropriate section consistently.
Is this a breaking change
- I'm not sure
Impacted Spec
For which spec is this feature being requested?
agencypolicyprovider
Describe alternatives you've considered
N/A
Additional context
This came up in a Working Group call on Oct 7 2020.
I think this is a very good idea. Whenever we write this unified authentication information, we should also note that the current reference implementation makes certain assumptions about the claims in the JWT provided by clients to gate certain data (e.g. only certain clients are authorized to view unpublished policies).
See notes from the WG call this week.
- Not complex to fix, but a bit tedious
- Max can volunteer to do PR at some point
- Docs and organizing, not breaking or not, not changing
- May identify areas for improvements along the way
As part of the #506 #644 #796 work, authorization across MDS will be more consistent and clear.
Note to make sure as part of 2.0 work we also make sure Policy, Geography, and Jurisdiction is required to be public, as promised here: https://github.com/openmobilityfoundation/mobility-data-specification/blob/main/general-information.md#optional-authentication
I've been meaning to work on this, based on extensive work on the Lacuna side that we're happy to share.
That would be great to share what you are thinking. Seems like it would align well with the Agency/Provider work.
Do you think this is resolved with #796 @marie-x ? If not we can move to future release or cleanup now when making release candidate.
I haven't done the writeup yet. If we can get the reconciliation work done, then I can work on this. Else defer I think. Don't feel strongly either way.
Complete with #835. If you have any recommended changes, leave a comment here for future inclusion during release review process.