CIBA MUST not become two-legged #268
Conversation
|
It is correct that the current CIBA implementations skip the involvement of an authentication device when consent collection is not required. But the fundamental problem here is with the mandate that every privacy sensitive API flow requires three-legged authentication; in fact that is not always true, only the identification of the resource and its resource owner is always required, not their authentication. The access token generated is linked to the decisions made by the authenticated resource owner and therefore is the trustful source for API invocation. Ways out of the problem could be: Having a secure mechanism for identifying the target resource of an API call is a separate issue which should be addressed in another pull request or CAMARA issue. |
|
I assume we are not going back on mandating three-legged tokens as described here:
I think Option 1 is not something we can just "agree" upon. We want to be interoperable and we, each API provider, must be compliant with applicable privacy regulations. Privacy regulations exist to protect the end-user/data-subject, and, I think, we cannot ignore them because they lead to inconvenience of the API Consumer or API provider. Regarding option 2:
So, under the provisions above client credentials flow can be used, but then it should be clearly stated instead of turning CIBA into a two-legged flow. @ALL, please review, provide suggestions and consider approving this PR. |
|
Amongst various timestamps, a 3-legged access token contains client information (client id), audience info, a reference to the data subject (sub) and the list of data scopes (could be privacy sensitive data scopes). The token is generated after successful check with the consent management. Why do you think that this token is not valid ? The consent data was captured by an authorized resource owner for a data subject. It does not lose its credibility, but because the data subject is not authenticated when information related to the data subject is retrieved. I understand that CIBA flow requires this authentication and it makes sense for the use cases, CIBA was invented. But why do you see a problem, if the system is using the information which the authorized resource owner has captured earlier? |
|
Whilst we're not using CIBA as it was originally intended in the spec, it's obviously not feasible to always include the end-user's phone as the Authentication Device in the CAMARA Backend Flow, the end-user does not need to be (nor want to be) actively involved in these use cases when consent collection is not required. We could posit that CAMARA is compliant with the spec by considering that the Resource Owner delegates their authentication/authorisation to the Consent Master when they grant consent (or when consent isn't required as a legal basis). They haven't given up their privacy rights, they've just delegated the parroting of their current choices to the Consent Master. When CIBA is used and consent needs to be collected, the end-user's phone is the Authentication Device; when consent does not need to be collected the Consent Master acts as the Authentication Device. |
|
What if some bad service providers mis-use checking APIs to check information from subscribers who are not their customers. When we detect and punish the service providers, subscribers information is already compromised. It would not pass the regulator's rules in my country. So we need 3-legged option to deploy in Vietnam. Otherwise we cannot comply with CAMARA in this case and have to deploy a variant CIBA flow in fact. |
|
CAMARA mandates that every privacy sensitive information API requires 3-legged authentication including consent capture. Case 1: valid access token! Case 2: consent is not required
So, we don’t see a challenge in using the CIBA flow as defined by the CAMARA ICM guidelines. |
| ExpO->>BE: HTTP 200 OK {"auth_req_id": "{OperatorAuthReqId}"} | ||
| end | ||
| loop Invoker polls until consent is granted or until expires. If granted in advance, token returned in first poll | ||
| Exp0->>FE: Out-of-band consent capture Push/SMS/Email/other |
There was a problem hiding this comment.
should this not go to the Auth Device (User) instead of to BE ?
There was a problem hiding this comment.
Should this CIBA flow not also show the different cases (as per Gaurav's comment (consent not yet granted, consent already granted, no consent needed, consent validity expiry), to stress that consent is only asked for when needed ?
The out of band consent request, and the loop on the back-end is only needed if consent was not yet granted, or if the consent validity expired.
I understand that this flow assumes that it is sufficient that the current step 2 identifies the "End User" (on the Auth Device) based on a valid login_hint, so no additional authentication of that "End User" is imposed. However that does not it mean it could not be done (with its own validity duration) if the Operator so desires.
so something like
opt If User Consent is required for the legal basis of the purpose
ExpO->>Consent: Check if Consent is granted
end
alt If Consent is Granted or Consent not needed for legal basis
ExpO-->>FE: 302
Location: invoker_callback?code=Operatorcode
else If Consent is NOT granted - Out of Band Consent Capture within CIBA Flow
Note over FE,ExpO: Start user consent capture process
following Section 3.1.2.4 of the OIDC Core 1.0 spec.
ExpO-->FE: Out-of-band consent capture Push/SMS/Email/other
Loop with polling .... (from current CIBA flow)
If the user refuses consent
ExpO-->>FE: 302
Location: invoker_callback?error=access_denied
else If the user grants consent
ExpO-->>FE: 302
Location: invoker_callback?code=Operatorcode
end
or something like that ?
There was a problem hiding this comment.
The flow in the PR is "broken", you can check the existing one here https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md#ciba-flow-backend-flow. Which, of course, would need to be edited with whatever changes we end up agreeing here.
|
I think this issue/PR raises a valid and fair technical concern. But at the same time, when the existing documented flows were agreed, it was generally assumed that API providers would integrate with partners under a contractual agreement that limited their actions (e.g. only using the phone number in their user base, etc...) and established a certain level of trust. As mentioned in the past, there was concern about contacting the user every time a new access token was requested. Again, I'm not saying that what is reported in this issue is wrong, but there is also some context behind these flows that the WG should already know or at least be reminded of. Also, the existing flows do not convert CIBA into a two-legged flow. The user rights to opt-in and opt-out are still maintained, and the access token is indeed associated with the user identifier. If CAMARA, or CAMARA ICM, now wants to question if the level of trust in the API consumer is not sufficient, that is what can be re-evaluated and agreed in this PR and issue. But the WG should also consider this context and the usability aspects. |
|
Hi @Elisabeth-Ericsson , I do not understand your comment.
My comment does not contain the word valid. In GDPR the data-subject is the one granting consent or not. The API Consumer can now send
The API Consumer would learn whether all those individuals who are associated with those phone numbers opted out, granted consent or not This is maybe more obvious with a login_hint=ipport:80.144.147.25:12345. |
The "legs" in a three-legged flow are: Client, end-user, Authentication Server. If CIBA does not send a message to the user's authentication device then there is no User-leg. I think that is then a two-legged flow and no personal information should be processed.
The user's rights cannot be maintained if the user is not involved in the process.
The consent cannot be "informed" if the user is not in the process.
Yes, there is some User identifier but we do not know much about that identifier. Maybe that is easier to see if we consider the login_hint to be an IP-address, which was re-assigned by the CSP to a different user device 5 minutes ago. |
If we were a ferry provider and the law requires us to provide lifeboats, then we have to provide lifeboats regardless whether our ferry service exists since 1900 and never provided lifeboats. The lifeboat drill is inconvenient for crew and passengers, but if the ferry sinks passengers are happy it happened and we are happy because the insurance is paying us. And the captain and ferry owner don't go to jail. Yes, ICM should consider privacy and user consent, and user experience and usability. |
Very ingenious. Please don't twist my words, I just gave the context. Now the WG can discuss and agree what is best for the users and for CAMARA.
100% |
|
Does GDPR not allow for "enduring consent", where an end user effectively says to an API provider "any time API consumer <insert name here> asks for personal information <insert personal information here>, you can give it to them until I tell you otherwise"? Or does GDPR require that the end user be given the opportunity to modify their consent each and every time their personal information is provided to or processed on behalf of that API consumer? |
|
GDPR absolutely allows for consent decisions to persist and not require confirmation on every processing; otherwise the whole world would grind to a halt. If you tick a box to consent to marketing information being sent, and then leave the website or shop or whatever, there's no opportunity for a company to access the individual to re-check that consent every time they want to send marketing information. This is the same situation. The user has consented to their data being processed for a purpose, and the ASP/CSP can continue processing data for that purpose until/unless the user opts-out; the option to opt-out doesn't have to be provided on every processing. |
True, but not the topic
The problem is different. The API Consumer could use CIBA to ask for an end-user authentication and consent for any user identifier. If CIBA does not send a message to the authentication device there is not User authentication at all, and we are sending personal information back to the API Consumer without User authentication and without end-user consent. ps: OIDC Authorization Code Flow is different because there we have network-based authentication of the User. So, OIDC ACF does not have this privacy problem, if we are reasonably sure that subscriber equals end-user, and OIDC ACF does not have the problem that the flow degenerates to a two-legged flow. |
But if the end user has already consented to provide that personal information to that specific API consumer, why do they need to re-confirm that consent every time the data is requested? End user authentication is not required - they have already agreed that the information can be provided to the API consumer whenever they ask. The end user should have been told how that consent can be revoked, and not need to constantly be given an unsolicited opportunity to do that. |
The difference between the current OIDC Authorization Code Flow and the CIBA Flow in described in CAMARA API Access and User Consent is that in OIDC ACF we always have a subscriber authentication through network-based authentication or the end-user authentication by whatever authentication method the API provider supports. The topic of this issue is, that in many cases there is NO User authentication in CIBA. The end-user might have already consented but without any User authentication we no not know who the User is. Even if there is a contract that binds the API Consumer to behave according to the relevant legislation that might no be enough. One end-user (attacker) might enter a MSISDN of a different end-user (victim) into the API providers web-form, who then sends a CIBA request to the API Provider who then leaks personal information, the consent status, about the victim to the attacker. |
Either the MSISDN is a valid user identifier or it is not, This is a legal question, not a technical question, and so CAMARA are not best placed to answer this. The user does not have to be the human who happens to be holding the mobile device when the API request is received. If the MSISDN can be a valid user identifier, then API providers should be allowed to fulfil requests based on enduring consent when they consider that it does identify the end user, without CAMARA mandating that the user has to be included in the loop somehow. If they are wrong, that's their problem. If it can never be a valid user identifier under any circumstances, but simply a clue as to who the user might be or how they can be contacted, then maybe CAMARA should remove MSISDN as an option and mandate API consumers provide unique and unambiguous user identifiers. But I do not think this is true - MSISDN can be an user identifier for many use cases. |
It is true that the MSISDN is a User identifier. No doubt about that. The question in this issue is not whether the MSISDN is an User identifier. The question is whether it is OK to use CIBA without any authentication. We have client credentials which authorize the API consumer, but no User authentication if CIBA does not send the authentication message to the authentication device. That might be OK in some circumstances but I still think that if no authentication message is sent to the authentication device then CIBA is a two-legged flow which should not be used if personal data is processed. |
I think we can leave that to API Providers based on their own confidence as to whether the personal information they are processing is that of the user identified by the MSISDN. The only guidance CAMARA should give is "do not break the law". |
The PR proposes some text, please review and propose suggestions how to improve that proposal. |
|
In Authorization Code Flow the API Provider's Authorization Server can do network-based authentication and in some cases that is enough that we are "sure enough" that subscriber equals end-user (data-subject). If the Authorization Server is not "sure enough" then the Authorization Server cannot determine the consent status of the end-user and SHOULD proceed with end-user authentication and end-user consent collection if there is no "prompt=none" in the request. If there is a prompt=none then "consent_required" should be returned in the error response. With CIBA in contrast to Authorization Code Flow, the Authorization Server would rely on the user identifier from the Authorization Reqest (login_hint) which even the API Consumer does not know whether that user identifier belongs to the end-user sitting in front of the e.g. laptop. CIBA is an authentication protocol that authenticates the end-user and gather their consent. Neither the API Consumer nor the API Provider's Authorization Server can rely on the value of login_hint. If the Authorization Server cannot rely on login_hint's value, the user identifier, then the Authorization Server cannot check the consent status based on that user identifier. Relying on the user identifier would defeat the purpose of CIBA which is to authenticate the user and collect their consent by sending a message to the authentication device. |
Many readers and many API Providers of our ICM documents are new to CIBA and consent. I think privacy and consent is very important for many API providers.
If CIBA is used in the way described then it is a two-legged flow and the above mandatory use of three-legged access tokens is not met. I think this part "whether user consent has already be given" cannot be implemented without some confidence that the user is authenticated or was authenticated in the past. A phonenumber provided by an attacker or the API provider just does not provide that confidence. If an API Provider is only offering two legged flows and does not need to care about privacy and consent with their use cases, then they should use a two legged flow and they should not use CIBA. I think readers of CAMARA APIs Access and User Consent Management might think that they are using a three-legged flow if they use CIBA while the current description of the CIBA flow is not a three-legged flow if no message is sent to the authentication device. |
|
Sorry, @Elisabeth-Ericsson by committing d6c76a5 your suggestions became outdated. I am going to address your comments/suggestions now |
Co-authored-by: Elisabeth-Ericsson <[email protected]>
Co-authored-by: Tanja de Groot <[email protected]>
What type of PR is this?
What this PR does / why we need it:
User consent cannot be checked based on the login_hint value alone and without sending a message, because then CIBA would be a two-legged flow. In a two-legged flow user consent checking is, probably, not relevant because two-legged flows only consider the API Consumers credentials.
The three-legged CIBA flow is necessary if Consumption Device and Authentication Device are different devices. If Consumption Device and Authentication Device are the same, then OIDC Authentication Code Flow SHOULD be used.
The Authentication Server MUST send a message to the Authentication Device, identified by login_hint, because otherwise there would be no User authentication at all.
Which issue(s) this PR fixes:
Fixes #258
Additional context
Note: In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design.