Allow dynamic consent to be transmitted to allow distributed data sharing between network participants

[ravi-prakash-v]

Health and wellness service booking and fulfillment often require sharing of medical history and prescriptions. To allow consented sharing of such data, there is a need for a consent framework to be baked into the architecture of the protocol to allow transmission of a consent request from a data consumer containing the information needed and the purpose of the request. As a response, the data owner should be able to provide a consent token to the data consumer. Upon receiving the token, the data consumer should be able to access the requested information for a specified period of time.

[imbdb]

Please add some description.

[ravi-prakash-v]

@imbdb added description and changed title to a more generic summary.

[pramodkvarma]

I would prefer this to be loosely coupled from beckn specs quite similar to payment authorization. Can we model it same as an independent flow triggered from DHP?

1. Provider platform want payment/data from user
2. They need to trigger that by sending a payment/data authorization request URL to app provider
3. App provider shows it to user
4. User clicks URL
5. If the URL is https it takes them to a payment/data gateway where payment/data authorization options can be chosen,
6. Or if the URL is a deeplink URL like upi:// or depa:// app can also trigger it directly
7. And user completes payment/data authorization

The above approach allows various countries to plugin their own payment/data authorization mechanisms without having to bake it into beckn itself.

What do you think @core-wg-admin ?

[ravi-prakash-v]

Yes @pramodkvarma I agree. But the consent authorization url must be sent to the application provider via DHP APIs right. Where do you propose the Provider Platform send this in the schema?

[pramodkvarma]

That's an option, yes. But make sure design accommodates various different architecture that may exist for consent management. But in general yes an https URL or any deepl-linkable URL can be sent back by provider which in turn triggers appropriate consented data sharing flows. In India, it will be DEPA based.

[bharatkashyap]

I would prefer this to be loosely coupled from beckn specs quite similar to payment authorization. Can we model it same as an independent flow triggered from DHP?

1. Provider platform want payment/data from user
2. They need to trigger that by sending a payment/data authorization request URL to app provider
3. App provider shows it to user
4. User clicks URL
5. If the URL is https it takes them to a payment/data gateway where payment/data authorization options can be chosen,
6. Or if the URL is a deeplink URL like upi:// or depa:// app can also trigger it directly
7. And user completes payment/data authorization

The above approach allows various countries to plugin their own payment/data authorization mechanisms without having to bake it into beckn itself.

What do you think @core-wg-admin ?

Added beckn/DHP-Specs-backup#32 on similar lines: adding data fulfilment information to the order object which will trigger the consented data sharing flows.