-
Notifications
You must be signed in to change notification settings - Fork 31
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. | ||
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). | ||
|
||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
@@ -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. | ||
|
There was a problem hiding this comment.
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.