Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consistent User Authentication and Consent Collection #229

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Consistent User Authentication and Consent Collection #229

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a81a909
Consistent User Authentication and Consent collection
AxelNennker Nov 14, 2024
d0e8088
Multi-SIM error only if CIBA
AxelNennker Nov 15, 2024
e258335
unify business and private case to end-user != subscriber case
AxelNennker Nov 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions documentation/CAMARA-Security-Interoperability.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,6 +66,30 @@ All network connections MUST use TLS 1.2 or better.

The OIDC Authorization Code Flow is defined in [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html)

### Consistent User Authentication and Consent collection

It is up to the operator to make a decision when consent collection is needed or not, based on the scope(s)/purpose declared by the API client and aligned with local legislation, ensuring that all operators under the same regulatory framework adopt a *consistent* approach.

This document defines that if the optional prompt parameter is absent from the OIDC authentication request then the API consumer uses network-based authentication to identify the subscription. If the subscription identified by network-based authentication cannot assure that the end-user equals the subscriber then an error MUST be returned.

Examples for cases where the authorization server cannot assue that the end-user equals the subscriber:
```
* A business owner has one contract that is associated with multiple MSISDNs
then the authorization server cannot assume that the end-user is the subscriber.
* A family has several contracts which all have the same subscriber then the authorization server cannot assume that the end-user is the subscriber.
```

The API provider could start User-Interaction to resolve the above cases, but that likely leads to different behaviour by different API producers.

The document defines that if the optional prompt parameter is absent from the OIDC authentication request and network-based authentication identifies one subscription that belongs to one person and that person does not own other subscriptions with that API provider, then the API provider can assume that the subscriber equals the end-user.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree, see my comment above.

The decicion whether consent needs to be collected or not is then determined by the API provider
* by determining the legal basis of the purpose e.g.: contract, legitimate_interest, consent, etc,
* and then checking if consent is required for the legal basis of the purpose
* and then checking whether consent was already granted or revoked out-of-band.

If consent needs to be optained then the API provider optains it according to [OIDC section 3.1.2.4](https://openid.net/specs/openid-connect-core-1_0.html#Consent).


Copy link
Collaborator

@jpengar jpengar Nov 14, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe #228 and #229 are adding a significant amount of supplementary information, which, as previously stated, may be appropriate for instances such as clarifying prompt parameter behavior. However, if we reach a specific conclusion in #215, wouldn't it be more efficient to address the issue by simply including that concise and straightforward conclusion in the profile document?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I strongly suggest that PR content be kept as concise as possible, focusing on clarifying the conclusion proposed in #215 and using the same wording. This is in line with the intention to reach an agreement on the conclusion in #215 comments. The proposed PR content introduces additional topics that will require more detailed discussion in ICM. These topics could be initiated in parallel in new issues, although it would be necessary to ascertain whether they can be included in Spring25. Otherwise, it will be challenging to merge this PR.

If the WG considers that we have not yet reached a final conclusion in #215, this should be addressed as a priority.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is an attempt to come to a conclusion in #215 by specifying behavior of the authorization server that is interoperable.

OIDC provides everything we need.

  • the API consumer can test the water with prompt=none and if the response is "consent_needed" the API consumer can start OIDC consent collection with prompt=consent.

### Cross-Site Request Forgery Protection

CAMARA REQUIRES cross-site request forgery (CSRF) protection.
Expand All @@ -86,6 +110,8 @@ Communication with the Backchannel Authentication Endpoint MUST utilize TLS.

CIBA allows the Client to get the authentication result in three ways: poll, ping, or push. This profile allows clients to use the *poll* mode. In the Poll mode, the authentication result is retrieved by the Client by polling the token endpoint using the new grant type.

If the the login_hint is not sufficient to identify one device, e.g. a phone number is specified but several subscriptions for the same phone number exist, then the authoriztion server MUST return an error code `DEVICE_NOT_FOUND` (???).

### Optional Parameters

The parameters `binding_message`, `user_code`, and `requested_expiry` are currently not implemented in CAMARA and for interoperability this document defines that the authorization server SHOULD ignore them.
Expand Down