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.

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
Changes from all commits
Commits
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
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

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?

### 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