Unclear how AuthZ/AuthN works with Marketplaces

[chrishowell]

Is there a clear description of how AuthZ/AuthN is meant to work when a Marketplace is involved?

From the existing documentation there's no mention of a Marketplace, and it looks like the AF must communicate directly with each MNO.

Is it the intention that every application provider registers with every MNO they need to communicate with?

[eric-murray]

Hi @chrishowell

I'm not sure this is an issue for CAMARA. Could you expand on your concerns and how this might affect the work of CAMARA?

CAMARA is primarily about defining APIs through documentation (primarily the OAS definition) and the code base for example implementations. An API consumer cannot just expect to download the API definition, run it through a code generator and then have a client implementation that will work for their use case. Some of the details in the API definition (e.g. apiRoot and, relevant to your question, details of securitySchemes) will be specific to each API provider (i.e. network operator).

So the client will anyway have to get this customised version of the API definition from each network operator that they want to send requests to, and that documentation will tell them what to do if they want to access the API. If they are going through an aggregator, then the responsibility for "registering" with the network operator to use the API will fall to the aggregator, but that does not change how the network operator will implement AuthZ/AuthN.

I can't imagine that any network operator would outsource AuthZ/AuthN completely to a third-party marketplace. But that marketplace can hide that complexity from their clients by publishing their own version of the API definition with the specific of their implemented security schemes.

Should three legged OAuth security be mandated for an API, it will be required that the end user themselves authorise the transaction, even if they are accessing through a third-party marketplace. The marketplace will thus need to support this "pass through" between client and network operator. This is an issue for the Identify and Consent Management sub-project, which has not yet started work.

[shilpa-padgaonkar]

@chrishowell : I agree here with the comments from @eric-murray. Camara APIs will be offered by network operators across several channels- Marketplaces/Aggregators being one of them and the network operators would have a consistent way of implementing authN/authZ.

I also noticed that you had added some comments to the consent doc PR. We agreed within commonalities to start a dedicated subproject around the consent and identity topic and close the PR in commonalities.

Please subscribe to the mailing list of this subproject (https://github.com/camaraproject/IdentityAndConsentManagement) so that you can be updated with the meeting invites that will be sent out in the next days if you wish to actively participate here.

[chrishowell]

Thank you for your responses.

I wasn't imagining that the network operators would be delegating Auth to a third-party, but I think there's a need to make this is similar as possible between each API provider.

From a marketplace perspective though, I do think three-legged OAuth with be a barrier to entry for ASPs.

I look forward to discussing the consent and identity topic further in the dedicated subproject :)