Add security scheme

[osarrat]

No description provided.

[osarrat]

There is so far no security scheme specified in this interoperability standard.
As a consequence, each implementation may prefer to user a different approach, and thus the organization which will try to interact with several providers may need to implement a different approach for each provider.

As a basis for discussion, the apiKey approach coming from RDEX+ is proposed here. RDEX+ used to propose 2 different schemes. The apiKey scheme is the only one proposed here because in the end, it is simpler to have only one approach, and the first know implementation of this standard (in the https://github.com/fabmob/comptemobi project) is using already apiKey.

[ccyrille]

Hi @osarrat ,

Thanks for the proposal ! Why not use the more conventional naming "X-API-Key" for the header?

Also, your description is very specific to 2 endpoints while this authentication scheme apply to nearly all of them. It seems wrong.

[adelcasse]

Hi @osarrat and everyone,
I agree with @ccyrille, I think "X-API-Key" would be better than api_key.

[giffarda]

Hi all,

Yes I agree too. on MCM gateway project we used the "X-API-Key" header too.

[osarrat]

Fixed !

The api_key variable has been renamed to the more standard name X-API-Key.

[ccyrille]

@osarrat thanks! Could you also remove references to specific endpoints in the description please?

[osarrat]

Could you also remove references to specific endpoints in the description please?

I understand the underlying reason : to avoid dependency between this description and some routes that may change in the future.
But in my opinion, there is a need to specify somewhere that those routes MUST control that the operator calling a GET /bookings or POST /booking_event MUST be an operator involved with the driver of the passenger of the specified booking.
Do you think that this requirement would better be specified in the description of those routes ?

[ccyrille]

@osarrat yes I definitely think it would (be better in the description of the specific routes). Thanks for the proposal :)

[osarrat]

I've moved the rule into the description of all routes where it should apply.

[giffarda]

This requirement requires that provider has stored a reference table with X-API-Keys given to each operator and operator DNS names. Provider should be verify the concordance.

As discussed in a workshop with @osarrat, this control can be a problem for an intermediate solution like the Mon Compte Mobilité Gateway. Indeed, Gateway obtains an API Key from the provider but offers provider services to other partners like MaaS.