Why "The API can be called by an application server or other 3rd party server"

[AxelNennker]

Problem description

The API can be called by an application server or other 3rd party server to establish the identity of the device currently being used by the mobile subscription.

https://github.com/camaraproject/DeviceIdentifier/blob/main/code/API_definitions/CAMARA%20Mobile%20Device%20Identifier%20API.yaml#L39

Expected action
All Camara APIs can be called from any device, be it server, smartphone, laptop.

Not sure, why this sentence is here.

If somebody thinks that calling the API from a server is a security "requirement" then this should be documented.
If it is common practice to send the OIDC code or the access token to a server, and then call a Camara API from there, then that adds an additional place where the code or access token can be stolen or leaked. There should be a risk assessment.

For this API I suggest removing that sentence.

Additional context
My recommendation:

• Native Apps should use PKCE
• Camara should use sender-constraint access tokens. See e.g. DPoP.

Sending the authentication code or access tokens from the OAuth2 client, that requested them, to a different server changes the OAuth2 security considerations.

[eric-murray]

Once the user stories in #73 are merged, I will update the API description

[AxelNennker]

Why wait?

#78

[eric-murray]

In the statement in question, "can" means "is able to", not "must". So it is undeniably true that an application or other 3rd party server can call the API, and I don't see the need to remove that statement.

Rather, if there is a use case where the device itself calls the API, then I'd like to understand how that would work and then extend the text to include that possibility as well.

But what authorisation flow would the device use in this case? CIBA is the obvious flow if the device is calling the API unprompted by an external application server, but if the device does not know its own IMEI, it probably does not know its MSISDN either. And it can only know its public IP / port by asking an external server, such as DNS or a 3rd party API.

And if the authorisation code flow is to be used, how would the device (or application on the device) trigger this if not sent a redirect to the /authorize endpoint by an external application server? Would the device independently call the /authorize endpoint with a redirect_uri back to itself (redirect_uri="http://localhost/...")? I can't see such local redirects being approved. I guess some "dummy" redirect_uri could be approved which the device ignores and just calls the /token endpoint anyway. But then we are moving well away from the OIDC standard.

So it's not clear to me how either 3-legged authorisation flow works for a standalone device without an external server involved.

[AxelNennker]

I am not saying that there is no server. In the use case I am thinking of the user installs e.g. a API consumer mobile app or the user navigates to the API consumer webpage on their mobile device using some Internet browser. Most if not all mobile apps have backends/servers and webservers are servers by definition. So, there is most likely a server.

I would remove that "server"-sentence because that sentences is better suited to be in a use case document, I think.
It is not necessary in a API-yaml file because the API can be called from anywhere, from the device or from a backend/server.
(Yes, I know the difference between must and can)
If in the use case the server calls the API, then it can do that. But the API can be called from anything that has an Internet connection.

Insurance-Company Mobile App calls DeviceIdentfier API use case:

• precondition: mobile app is registered for URL e.g. https://supainsurance.example.com/consume_code e.g.

  • Android App Link https://developer.android.com/training/app-links#android-app-links
  • iOS https://developer.apple.com/documentation/xcode/supporting-associated-domains

• user installs API consumer's mobile app

• user creates an API consumer account on API consumer backend or logs-in to existing account

• user taps on something in the mobile app that needs API

• mobile app opens browser for OIDC authorization code flow (with PKCE)

• user is authenticated by API Producer and consents to API use by API consumer

• redirect from browser to mobile app via registered URL

• mobile retrieves access token (using PKCE code verifier)

• mobile app send API request with Authorization: access token

• API responds with device identifier, model, manufacturer

• mobile app sends device identifier, model, manufacturer to mobile device insurance server

• insurance contract for mobile device is created.

Note: the consent can be collected at any time in the mobile app, either in a mobile app's first run experience or when the API is used.
If the consent is collected in the first run experience and the access token might be expired when the API is used, then a refreshtoken should be requested in the first-run experience and a fresh accesstoken requested when the API is used.