Consent Management API DRAFT proposal for Controlled Capture Delegation#43
Consent Management API DRAFT proposal for Controlled Capture Delegation#43
Conversation
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports |
| - "location-verification:verify" | ||
| purpose: "dpv:FraudPreventionAndDetection" | ||
| consentStatus: "PENDING" | ||
| ConsentText: |
There was a problem hiding this comment.
Add a version or lastUpdated field to track legal text updates.
| $ref: "#/components/responses/Generic403" | ||
| "404": | ||
| $ref: "#/components/responses/Generic404" | ||
| /consents/retrieve-info: |
There was a problem hiding this comment.
When requestConsentText is false, this API is similar to consentInfo ?
Consent-info will disappear and be replaced by this one ?
| - Consent Management | ||
| parameters: | ||
| - $ref: "#/components/parameters/x-correlator" | ||
| - $ref: "#/components/parameters/Accept-Language" |
There was a problem hiding this comment.
Do we have only on accepted langage or can we pass a list with an order ?
| description: | | ||
| This operation allows the API Consumer to create a Consent for a given User, scope(s) and Purpose. The API Consumer is identified by the `client_id` parameter deduced from the access token. | ||
|
|
||
| The API Provider will set the creation date of the User Consent to the current date and time when the `createConsent` operation is invoked successfully by the API Consumer. |
There was a problem hiding this comment.
we should specify the consistent use of UTC timezone to avoid ambiguity for creationdate and expirationdate.
|
|
||
| This approach simplifies API usage for API consumers using a three-legged access token to invoke the API by relying on the information that is associated with the access token and was identified during the authentication process. | ||
|
|
||
| ## Error handling: |
There was a problem hiding this comment.
Perhaps i missed it but there is no specific error message dedicated to an invalid or non-existent consentTextId.
It would be advisable to add one to improve robustness and traceability, especially for server-side validation.
|
A new, independent repository for the Consent Management API has been created: https://github.com/camaraproject/ConsentManagement. Further details can be found at camaraproject/APIBacklog#292. Following the group's agreement in the last ICM call, the content of PR #43 has been included in camaraproject/ConsentManagement#3. That PR will be merged as an initial API draft in the new repository. Thank you, @sebdewet, for your time and comments! I propose creating a new issue in the new repository to discuss your comments above. Eventually, we can apply any changes that the working group (WG) agrees on to the initial API draft proposal in a new pull request (PR). Leave it to me; I will create the issue. |
What type of PR is this?
What this PR does / why we need it:
This PR is intended to create a DRAFT proposal for a Consent Management API that enables Controlled Capture Delegation feature for API Consumers.
Which issue(s) this PR fixes:
Fixes #42
Special notes for reviewers:
Changelog input
Additional documentation
camaraproject/APIBacklog#276
camaraproject/APIBacklog#277
camaraproject/IdentityAndConsentManagement#327
#42