Consent Info
The "Consent Info" API allows developers to easily validate whether they have the necessary permissions to process User's personal data for a specific Purpose before using other CAMARA APIs.
Introduction
The Consent Info API allows API Consumers to easily validate whether they have the necessary permissions to process User's personal data for a specific Purpose before using other CAMARA APIs. It provides a simple true/false response and, when applicable, a URL to direct the User to manage their Consent.
API Scope
The current API implementation is applicable to any mass-market Orange France mobile customer, including SOSH customers.
Subscribe to the API
You get the Authorization header credentials when you register your application on the Orange Developer Console.
API Authentication
HTTPS requests to the REST API are protected with CIBA 3-Legged OAuth.
In short, the API Invoker (e.g. Application Backend or Aggregator) before to request Consent-Info, needs to request a Three-Legged Access Token from Orange Authorization Server. The process follows the OpenID Connect Client-Initiated Backchannel Authentication (CIBA) flow.
Step 1: request the OAuth authorization code from the Application Backend
The API Invoker provides in the authorization request (/bc_authorize) a login_hint with a valid User identifier together with the application credentials (client_assertion & client_assertion_type) and indicates the Purpose for processing Personal Data. The Orange implementation follows the CAMARA scope definition. The scope must be set to:
opendid dpv:<dpvValue> <technicalParameter>. dpv stands for Data Privacy Vocabulary.
Note on JWT usage via client assertion:
client_assertion is a JWT used by a client to authenticate itself to an authorization server, while client_assertion_type specifies the type of assertion being used, typically indicating it is a JWT. Together, they facilitate secure client authentication in OAuth 2.0 and OpenID Connect protocols. API consumer as to define JWK keystore in settings tab of the application in Orange Developer
For current implementation only ServiceProvision dpv value is managed, which means that:
- the scope in the
bc-authorizemust be set toopenid dpv:ServiceProvision consent-info:retrieve
Request:
curl -X POST \
'https://api.orange.com/openidconnect/ciba/fr/v1/bc-authorize' \
--header 'Accept: */*' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'login_hint=tel:+336666666' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=eyJhbGciOiJSUz...1jjGg' \
--data-urlencode 'scope=openid dpv:ServiceProvision consent-info:retrieve'
Response:
200
Content-Type: application/json
{
"auth_req_id": "y_azuw2HT4fWYPb0-0w2DBhaEq8",
"expires_in": 120,
"interval": 2
}
Step 2: Request the OAuth access token
Once the client application gets the authorization code, the API Invoker polls the token endpoint by making an "HTTP POST" request by sending the grant_type (urn:openid:params:grant-type:ciba), auth_req_id (OperatorAuthReqId) and the the application credentials (client_assertion & client_assertion_type) parameters
If the transaction succeeds, in the POST response, the acccess_token is provided.
Request:
curl -X POST \
'https://api.orange.com/openidconnect/ciba/fr/v1/token' \
--header 'Accept: */*' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=eyJhbGciOi....iuT111jjGg' \
--data-urlencode 'auth_req_id=y_azuw2HT4fWYPb0-0w2DBhaEq8' \
--data-urlencode 'grant_type=urn:openid:params:grant-type:ciba'
Response:
200
Content-Type: application/json
{
"access_token": "OFR_28Fp...Jb60y3KPvcZaOTHJ_sFnjOmyHN5PxXG...osYpKu3gA4utWicDw",
"token_type": "Bearer",
"refresh_token": "4bwc0ESC_IAhflf-ACC_vjD_ltc11ne-8gFPfA2Kx16",
"expires_in": 120,
"id_token": "OFR_28Fp...Jb60y3KPvcZaOTHJ_sFnjOmyHN5PxXG...osYpKu3gA4utWicDw"
}
Step 3: Access protected resources using OAuth access token
In order to call our API, the access_token is mandatory.
Specific documentation about consent-info/retrieve resource is provided below.
API Description
Summary of resources
This API has one resource retrieve.
Summary of methods and URL
| Use case of operation | URL method |
|---|---|
I want to create a request to retrieve the validity status of the API Consumer data processing for a given User, scope(s) and Purpose. The API Consumer is identified by the client_id parameter deduced from the access token. | POST "https://api.orange.com/camara/ofr/consent-info/v0.1/retrieve" |
Summary of request body parameters
In bold parameters currently available in Orange France API
| Name | Type | Description | Mandatory |
|---|---|---|---|
| phoneNumber | string | Create a request to retrieve the validity status of the API Consumer data processing for a given User, scope(s) and Purpose. The API Consumer is identified by the client_id parameter deduced from the access token. Must not be provided when the phone number is deducted from the access token | No |
| scope | string (array of) | List of requested scopes. The scope is a string that represents the access rights that the API Consumer is requesting from the User like for example: location-verification:verify | Yes |
| purpose | string | The reason for which personal data will be processed by the API Consumer. CAMARA defines a standard set of Purposes which can be used by API Consumers to specify the reason for their intended personal data processing. CAMARA uses the W3C Data Privacy Vocabulary (DPV) to represent these purposes e.g. dpv:FraudPreventionAndDetection or dpv:RequestedServiceProvision. | Yes |
| requestCaptureUrl | boolean | A boolean flag indicating whether the API Consumer requests API Provider to return a Consent capture URL: - If set to true the API will include a captureUrl in the response body if applicable. - if set to false the API will omit the Consent capture URL from the response. | Yes |
Summary of response parameters
| Name | Type | Description | Mandatory |
|---|---|---|---|
| statusInfo | object | Provides information about the validity status of the requested data processing for the specified scope(s) and Purpose. It contains details of whether the processing of the data is currently valid and, if not, the reason why. The expiration date of the validity may be also provided if applicable. | Yes |
| captureUrl | string (url) | URL where the User can provide the necessary Consent. This field is only present in the API response if the API Consumer requests it and if the following conditions are met: - statusInfo*.statusValidForProcessing is false, and statusInfo*. - statusReason is PENDING, REQUESTED or EXPIRED. Please note that this field is only applicable when the User Consent is required to enable valid data processing. A unique URL is provided to authorize all items in the statusInfo list that require user action. | No |
Details on statusInfo:
| Name | Type | Description | Mandatory |
|---|---|---|---|
| scopes | string (array of) | List of requested scopes. The scope is a string that represents the access rights that the API Consumer is requesting from the User like for example: location-verification:verify | Yes |
| purpose | string | The reason for which personal data will be processed by the API Consumer. CAMARA defines a standard set of Purposes which can be used by API Consumers to specify the reason for their intended personal data processing. CAMARA uses the W3C Data Privacy Vocabulary (DPV) to represent these purposes e.g. dpv:FraudPreventionAndDetection or dpv:RequestedServiceProvision. | Yes |
| statusValidForProcessing | boolean | Boolean flag that shows the validity status of the requested data processing for the specified scope(s) and Purpose. | Yes |
| statusReason | string | This field must be present if statusValidForProcessing is false. It indicates the reason why the requested data processing is not permitted for the specified scope(s) and Purpose. It provides API Consumers with additional context on the current validity status, helping them to understand its applicability and the next steps they may need to take. | No |
| expirationDate | string (date-time) | The date and time at which the validity of the data processing is set to expire or has expired. It applies mainly to time-limited Consents, or other cases where a specific duration of validity is defined for the data processing. | No |
Explanation on **statusReason **values:
- PENDING: The requested data processing has not yet been established or fully validated under the applicable privacy regulations. For example, the User has not yet provided Consent when it is required.
- REQUESTED: The permission for the requested data processing has been submitted but has not yet been granted or confirmed. This is common when the API Consumer has initiated a request for Consent capture, but the User has not yet completed the process. For example, this occurs when a notice prompting the User to provide Consent has been displayed, but they have not yet made a decision.
- REVOKED: The User has actively withdrawn their permission for the requested data processing after previously opting in. For example, the User revokes their Consent for the data processing.
- OBJECTED: The user has opted out of the requested data processing, despite a previous explicit opt-in not being required. This is common when the User has exercised their right to object to data processing under the applicable privacy regulations.
- EXPIRED: When applicable, the validity of the data processing has ceased due to the passage of time or a pre-defined condition. This is common for time-limited Consents.
Request
curl -X POST "https://api.orange.com/camara/ofr/consent-info/v0.1/retrieve"
-H "Authorization: Bearer {your access token}"
-H "Cache-Control: no-cache"
-H 'accept: application/json'
-H 'Content-Type: application/json'
-d '{
"phoneNumber": "+123456789",
"scopes": [
"location-verification:verify"
],
"purpose": "dpv:FraudPreventionAndDetection",
"requestCaptureUrl": true
}'
Response examples
Case 1: Ready For processing:
200 OK
Content-Type: application/json
{
"statusInfo": [
{
"scopes": [
"number-verification:verify"
],
"purpose": "dpv:FraudPreventionAndDetection",
"statusValidForProcessing": true
}
]
}
Case 2: Consent in required and capture url was not requested:
200 OK
Content-Type: application/json
{
"statusInfo": [
{
"scopes": [
"location-verification:verify"
],
"purpose": "dpv:FraudPreventionAndDetection",
"statusValidForProcessing": false,
"statusReason": "REQUESTED"
}
]
}
Case 3: Consent in required and capture url was requested:
in this example an existing consent was granted but was expired.
200 OK
Content-Type: application/json
{
"statusInfo": [
{
"scopes": [
"location-verification:verify"
],
"purpose": "dpv:FraudPreventionAndDetection",
"statusValidForProcessing": false,
"statusReason": "EXPIRED",
"expirationDate": "2023-07-03T14:27:08.312+02:00"
}
],
"captureUrl": "https://example.org/consent-capture-url"
}
Case 4: Consent is revoked:
Valid case when explicit consent is the legal base.
200 OK
Content-Type: application/json
{
"statusInfo": [
{
"scopes": [
"location-verification:verify"
],
"purpose": "dpv:FraudPreventionAndDetection",
"statusValidForProcessing": false,
"statusReason": "REVOKED"
}
]
}
Case 5: Consent is objected:
Valid case when legitimate interest is the legal base.
200 OK
Content-Type: application/json
{
"statusInfo": [
{
"scopes": [
"location-verification:verify"
],
"purpose": "dpv:FraudPreventionAndDetection",
"statusValidForProcessing": false,
"statusReason": "OBJECTED"
}
]
}
Most frequent errors
If invalid input are provided in particular for the device identifier a 400 error is triggered.
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"code": "INVALID_ARGUMENT",
"status": 400,
"message": "Client specified an invalid argument, request body or query param."
}
If the client provided a phone number within the access token but also provide it in the API payload an error 422 is end back.
HTTP/1.1 422 Unprocessable Content
Content-Type: application/json
{
"status": 422,
"code": "UNNECESSARY_IDENTIFIER",
"message": "The phone number is already identified by the access token."
}
There are some cases where your client application will no longer gain access to API resources, and get an error back.
Please check the following points:
- Here, you attempt to use an expired or revoked access_token and you get an invalid token error. You will have to request a new access_token. As an example:
HTTP/1.1 401 Unauthorized
Content-Type: application/json
{
"code": "UNAUTHENTICATED",
"status": 401,
"message": "Authorization failed: ..."
}
- Here, you removed your subscription to the API so that the capability to generate an access_token is not allowed anymore. As an example:
HTTP/1.1 403 Forbidden
Content-Type: application/json
{
"code": "PERMISSION_DENIED",
"status": 403,
"message": "Operation not allowed: ..."
}