New API Proposal - Consent URL API

documentation/API proposals/API_Proposal_Consent_URL_API.md

@@ -0,0 +1,12 @@
+| **Field** | Description | 
+| ---- | ----- |
+| API family name | Consent URL API (TBC)| 
+| API family owner | Telefonica |
+| API summary | Current consent management is based on: <br>- **Frontend flow (Authcode)**: Since the authorization code grant involves the interaction with application front-end, consent can be captured directly from the user through the application browser. Taking advantage of the frontend flow, consent can directly be captured through an interactive dialogue with the End-User,  <br>- **Backend flow (CIBA)**: Out-of-band consent capture is employed in backend flows as part of asynchronous CIBA flow, where operator gets in charge of reaching the End-User and capturing the consent if needed, based on the channels that each operator supports (e.g. push notification with fallback to SMS, etc...). <br> Developers are therefore mandated to capture the consent in the frontend flow, or delegate the moment of capture in the operator, which may or may not be able to reach the customer in a succesful way. <br><br> With the proposed API, the developer will be able to request for a consent capture process when they find it's more suitable, by specifying the scope(s) and purpose that they require to access data from a specific end-user. <br>The API takes advantage of the developer's knowledge of the customers, based on the use case that they manage, to trigger the consent capture process in the moment and channel that best fit with each customer, while ensuring that the privacy management and ownership remains in the operator. The process can be included in onboarding processes, where developer can gather the consent in advance getting ready by the moment the API(s) need to be called.|
+| Technical viability | The API creates a consent capture URL, provided by the operator and following same or similar interactive dialogue as in frontend flow, that allows the developer to provide a consent capture process to the end-user, based on the requested API scope and purpose that the developer is later going to use. <br>**Inputs Explained:**<br>- **User identifier**: Phone number of the end-user, which identifies the line whose consent is required to access the specific service.<br>- **Scope**: List of API PIScope(s) and a specific  purpose, following the format defined by [CAMARA-API-access-and-user-consent.md](https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-API-access-and-user-consent.md) <br>**Output:**<br>- **Consent URL**: URL containing the content capture procedure of the telco, including its own subscriber authentication. |
+| Commercial viability | **Current use cases validating the service:**<br> 1. **Consent capture during end-user onboarding**: The developer, when registering the user in a digital or physical procedure, can take advantage of the presence of the end-user during the process to pre-capture the consent for the set of APIs that the user is later going to require. <br> 2. **Consent capture in application notification**: Developers can push a notification in their app so that customers can access directly to the consent capture process in this easy-to-access place. <br> 3. **Consent capture campaigns**: Applications can create campaigns by email or other channels to capture the consent for substantial chunks of their user base. | 
+| YAML code available? | NO<br> To be provided  |
+| Validated in lab/productive environments? | YES |
+| Validated with real customers? | YES |
+| Validated with operators? | NO<br> |
+| Supporters in API Backlog Working Group | Telefonica |