Allow for consent receipts to carry authentication information

[crtahlin]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

In a use case where Person A wants Data controller B to have access to his data at Data controller C and a consent is needed, it would make sense to include authentication info (permission? API info?) with the given consent in a way that B can get to data at C.

Describe the solution you'd like
A clear and concise description of what you want to happen.

When a consent is given by A to B, B can get to the data that is held by C.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[LALeVasseur]

Crt - Can you please add more details in the Description field regarding what fields need to be added to the consent receipt?

[crtahlin]

@LALeVasseur Actually, i would considered this obsolete.

Explanation:
We are going in the direction of "consents" also including more technical information about the data being shared as well as the authentication information to get to the data at a data provider. This is the idea stated in the IHAN Blueprint (https://media.sitra.fi/2018/11/14144842/261018-ihan-blueprint-2.0.pdf). Currently we are working to specify the contents of "consents" in more detail, and the Kantara consent receipt should definitely be a part of that (https://ihan.atlassian.net/wiki/spaces/IHANPUBLIC/pages/27000845/Consents+in+IHAN+version+for+comments).

But, extending the Kantara consent receipt to include all that information is outside of the scope of Kantara Consent receipt, as it is meant to be human readable and satisfying the needs of the human parties in the exchange to be inormed of the nature of the exchange (not the machines communicating to get the data).

Should I close the issue?