eric-murray
commented
1 month ago Once the user stories in #73 are merged, I will update the API description
Open AxelNennker opened 1 month ago
eric-murray
commented
1 month ago Once the user stories in #73 are merged, I will update the API description
AxelNennker
commented
1 month ago eric-murray
commented
1 month ago 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
commented
1 month ago 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.
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.
Problem description
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:
Sending the authentication code or access tokens from the OAuth2 client, that requested them, to a different server changes the OAuth2 security considerations.