Grant vs Consent confusion

[Jacob Ideskog]

This is a more general issue that I place here for discussion.

When reading the Grant Management spec from an implementation perspective, vs when listening to the discussions and use-cases I feel that there is a discrepancy between the intent of the specification and the text. The difference between a Grant and a Consent is clearly defined in section 1.1. However the specification mostly deals with Grants, but the use-cases and discussion often are about consents.

From an implementation perspective I know that consents are handled very differently between vendors, and that it is often the consented data that is interesting to the end-user. 

To give some examples:

• When a Grant expires, does that mean that the consent expires? In either case it’s worth defining
• If a new Grant is created for already consented to scope, client and resource-owner, should a new consent be required?
• Revoking a Grant, does that revoke the consent?

I think this needs to be clarified in greater detail in the specification as it will lead to big differences in implementation and prohibit interoperability.

‌

[Dima Postnikov]

Thanks Jacob, great questions.

We have tried to clarify this before and I agree there is still some room for confusion. I will try to walk through some previous discussions and we can make suggestions on how to improve the language in the specification afterwards.

The diagram below is the one I used last year for discussion on similar topic:

‌

We recognised that “consent” is a broader concept which has slightly different scope and legal meaning in different countries. In different ecosystems, consent might be owned by different parties. AS might not see the full details of consent granted to a client, client would only communicate to AS a relevant part of the consent.

“Authorisation” or “grant” is specific technical construct required to implement consent on AS side. It exists today in each AS internally and contains detailed permissions that AS and RS can interpret and enforce.

In a very simple implementation (including business and legal definitions) consent and grant can be almost the same, but usually they are not.

Grant management externalizes this internal construct for the purpose of visibility and management by a client.

Some of the answers:

• When a Grant expires, does that mean that the consent expires?

  yes

‌

• If a new Grant is created for already consented to scope, client and resource-owner, should a new consent be required?

This probably depends on a specific scenario. Usually grant is created as a part of consent establishment. Some ecosystems might allow for concurrent consents and grants with the same permissions and some might not.

‌

• Revoking a Grant, does that revoke the consent?

‌ yes

Let me know if you have any feedback on what I’ve tried to describe.

‌

‌

[Jacob Ideskog]

Hi Dima,

Thank you for the reply. I agree with your picture and your general conclusions that Grant and Consent are sometimes but not always mapped one to one. I think we can probably find more cases that justify explicit mentions and clarifications (although I don’t have anymore right now).

To clarify points such as those I raised, even if the answer is “it depends”, is necessary in my opinion, and I’m happy to assist if I can in this area.

One important point that you raise, and that I’m fully aware of is that obtaining Consent from the user may not be the job of the AS. That’s OK, but should be clarified. However, since there is a relationship between the Consent and the Grant which surfaces during management of the Grant, I think it makes sense to highlight this. For example, even if the AS doesn’t manage the consents, it may need to reach out to a Consent service to revoke the status when the Grant is revoked. I suppose it could also be vice versa if a consent API is used, such as in OBB, and the consent is revoked there. That may require the API to reach out to the AS and revoke any associated Grants. That would break the assumption that it is the client that manages its own Grants. It might even be worth considering Security Events between the AS and the potential Consent API.

I imagine that the current implementations of AS:es today have invented various representations of a Grant already and its relationship to Consent. So there will be a challenge to map that into what this specification declares. I think we should take the chance to define the relationship between the Grants and the Consents in more than just their definitions to help implementors adjust and adapt.

[guy moyo]

Hello,

is this way wrong?

‌

Consent: Global agreement between the User, and Client.

Grant: Specific agreement between the User, and Client. Agreement details inside authorization_details.

‌

Relation: Consent 1 --- * Grant

‌

A grant will always be associated with consent.

Deleting a consent means deleting all grants associated with that consent.

[Jacob Ideskog]

I think that makes sense. The agreement details could also come in scope etc.

I probably wouldn’t call it Global, but at least OP wide.

[Jacob Ideskog]

I’ve given this a great deal of thought, and I agree with the spec that consent is something else that is not part of the scope, even though they may be technically linked in some implementations.

If I can come up with a wording that can help avoid the confusion that led me down this path I’ll make a PR with a proposal. If my reading led me down that path, others might read it the same way.

From my perspective we can close this issue.

[Dima Postnikov]

Thanks Jacob

[Dima Postnikov]

No changes required