Consent Management in FAPI

[Torsten Lodderstedt]

It seems a complete API authorization approach for regulated use cases needs a consent management beyond standard OAuth.

This ticket is a spin-off from https://bitbucket.org/openid/fapi/issues/271/rename-and-adjust-fapi-profiles and shall capture requirements and ideas around that topic.

[Torsten Lodderstedt]

I copied the last statement of @Dima Postnikov in #271:

In terms of what Australia need to achieve the requirements above (my interpretation):

• Ability to convey authorisation requests.
• Ability to handle complex / fine-grain consents objects.
• Ability to support redirect and decoupled authorisation flows for initial authorisation and renewals.
• Ability to synchronise consent between different parties (pull and push).
• Possibly, ability to support multiple concurrent consents.

‌

[Torsten Lodderstedt]

Ability to convey authorisation requests.

Ability to handle complex / fine-grain consents objects.

I think RAR provides a mechanism to convey arbitrary authorization request data in a type safe manner. In conjunction with authorization code flow, PAR is in my opinion the best option to transfer the data in a reliable way. With CIBA, the auhorization_details parameter can directly be sent with the initial request.

‌

[Torsten Lodderstedt]

Ability to support redirect and decoupled authorisation flows for initial authorisation and renewals.

What’s the difference between initial authorization and renewal from a client’s perspective?

Possibly, ability to support multiple concurrent consents.

Should be possible by using distinct client_id per use case. I think this matches the use cases @perlboy has given in #271.

If these client ids need to be co-related, e.g. in order to issue the same PPID, the relationship between the client_id and the respective legal entity must be represented in the AS (and the registry). This can be implemented in many ways. At yes.com, we maintain this relationship in our RP directory. There is also a mechanism in OpenID Connect called “sector identifier uri“ (https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation) to maintain the relationship between different client ids.

‌

[Torsten Lodderstedt]

Ability to synchronise consent between different parties (pull and push).

To me this sounds like an attempt to synchronize shared state across different clouds, which is always a challenge. What’s the rational and what are the detailed requirements and use cases?

I think, a client will never be allowed to do more than revoking a consent (or grant), potentially a part of a grant just because the user’s consent is required for any upgrade.

I cannot image a user will do more than revoking a grant at the AS. I hardly believe the AS could add additional features to a consent just because it does not know what the client would ask for.

In “traditional” OAuth, the client is “notified” of a change in consent

• by a HTTP status code 403 when trying to access an API
• by a HTTPS status code 401 or 403 when trying to refresh an access token

and will start a new authorization process in order to obtain the missing grant.

What’s wrong with this approach?

[Michael Schwartz]

You are re-inventing UMA…

[Torsten Lodderstedt]

right now we are discussing requirements

[Stuart Low]

I think RAR provides a mechanism to convey arbitrary authorization request data in a type safe manner.

As a starting point I like where RAR is at but I’m not totally across how attributes necessary for different jurisdictions can be conveyed. As I understand the RAR spec right now there is a type included in the payload and there is a paragraph in the draft referencing “extensions”. I’d like to spend some time taking the ACDS requirements and mapping this to what it’d look like in RAR.

In conjunction with authorization code flow, PAR is in my opinion the best option to transfer the data in a reliable way.

I like where PAR is at right now but I don’t think PAR and RAR should be looked at in isolation. In my opinion, we should consider a merge of “Pushed Rich Authorisation Request” or PRAR. I note flexibility of how a payload gets to the AS is roughly analogous to OIDC’s Request Object by Value and Request Object by Reference so I think it seems wise to support a similar delivery workflow for RARs (ie. supply the RAR via Value AND/OR RAR via a Reference AND/OR RAR via Pushed Value) allowing for implementation specific decisions.

With CIBA, the auhorization_details parameter can directly be sent with the initial request.

Once again, I’d like to spend some time taking the ACDS requirements and mapping this to what it’d look like relative to CIBA.

What’s the difference between initial authorization and renewal from a client’s perspective?

The renewal is intended to be lower friction than the initial authorisation. Currently the CX research conducted by Data61 only covers initial authorisation. The thought here is that a user should be able to efficiently renew authorisations across multiple agreements, preferably in a streamlined way (ie. a bulk consent renewal process). HOW to do this hasn’t been deeply evaluated.

Should be possible by using distinct client_id per use case. I think this matches the use cases @perlboy has given in #271.

I may have miscommunicated the first time round but there’s definitely a requirement to have multiple use cases for a single client_id. The regulator wants an environment where a single “app” has multiple standalone consents granted dependent on feature access the consumer wants. It is expected these multiple consents would be explicitly tied to separate token sets and only utilised for the specific use case in a “logical separation” environment within the organisation.

If these client ids need to be co-related, e.g. in order to issue the same PPID, the relationship between the client_id and the respective legal entity must be represented in the AS (and the registry). This can be implemented in many ways. At yes.com, we maintain this relationship in our RP directory. There is also a mechanism in OpenID Connect called “sector identifier uri“ (https://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation) to maintain the relationship between different client ids.

Is that what sector identifier uri was really designed for? Discussion within ACDS has revolved around using this to allow for transition of IdPs. Associating further business logic to it seems “risky” from a business use case perspective.

To me this sounds like an attempt to synchronize shared state across different clouds, which is always a challenge. What’s the rational and what are the detailed requirements and use cases?

The policy vision here is that a user would be able to load a single dashboard at any party and see their consents across all OPs and RPs. Logistically this is rather difficult to achieve without accidentally disclosing information to unrelated parties. I think this is why @Dima Postnikov has been highlighting “consent as a resource” which seems like a pathway to at least partially achieving this although the concept of granting a third party access to view consents would result in the consumer being required to know who they setup agreements with, this seems counter intuitive. Consequently I suspect some form of “agreement discovery protocol” would need to be created but this risks unintended information disclosure (again).

I cannot image a user will do more than revoking a grant at the AS. I hardly believe the AS could add additional features to a consent just because it does not know what the client would ask for. [… snip …] What’s wrong with this approach?

Actually, nothing really, the challenge here is how to present it to a user. CX research has indicated users barely understand consent let alone multiple consents. When we throw in mutability to consent (ie. “add features”) they become even more confused. But if, on a consent dashboard you then list multiple OP<->RP pairs and say they are separate that is also confusing. Consequently, many Holders (ie. OPs ie. Banks) are looking at presenting these multiple consents as one entry but then cancelling part of it is confusing too….

I don’t think I’ve really answered your question here because it’s seen as confusing either way but suffice to say there is a desire to have “immutable consents” but present them in a single unified way. I suspect the policy objective here is in conflict with the technical reality so once again all I can say is what I’ve already said twice before which is to map this out against the ACDS requirements and see where we stand.

You are re-inventing UMA…

There’s definitely overlaps that UMA would be useful but there’s also some parts which are unsuitable.

Hope this helps at least somewhat!

[Torsten Lodderstedt]

I may have miscommunicated the first time round but there’s definitely a requirement to have multiple use cases for a single client_id. The regulator wants an environment where a single “app” has multiple standalone consents granted dependent on feature access the consumer wants. It is expected these multiple consents would be explicitly tied to separate token sets and only utilised for the specific use case in a “logical separation” environment within the organisation.

An app can use multiple client_ids to separate different use cases. That directly gives you separate token sets. Why do you want to invent a new protocol feature instead?

Is that what sector identifier uri was really designed for? Discussion within ACDS has revolved around using this to allow for transition of IdPs. Associating further business logic to it seems “risky” from a business use case perspective.

yep. That’s exactly the use case sector identifiers have been invented for (although this aspect can be solved using other patterns, as I mentioned).

What does „transition of IDPs“ mean? You are not talking about migration of user accounts?

[Stuart Low]

An app can use multiple client_ids to separate different use cases. That directly gives you separate token sets. Why do you want to invent a new protocol feature instead?

This approach was evaluated and rejected on the basis that it was seen as overly complex for implementers, that transport layer certificates were intended to be tied to client_id’s (resulting in a cascading complexity problem for holders terminating TLS at the border) and that holders would be faced with a potentially exponential number of clients to manage.

yep. That’s exactly the use case sector identifiers have been invented for (although this aspect can be solved using other patterns, as I mentioned).

Wrongly or rightly, the idea of being able to maintain PPID’s across different clients by using sector identifier uri would likely be seen within ACDS as an anti-pattern of what was intended whereby PPID’s are specifically designated as being unique per consent (ie. should never overlap, ever…).

Update: Interestingly in recent updates the definition of PPID within ACDS has been reduced to simply “unique customer” versus “unique consent”.

What does „transition of IDPs“ mean? You are not talking about migration of user accounts?

No, the primary discussion around support for sector identifier uri has been to allow data recipients the ability to change the endpoints/hostnames of their IdP without requiring the reestablishment of consents. Ie. Alter their IdP endpoints without obtaining new PPID’s. This has been discussed within the ACCC Register github here: https://github.com/cdr-register/register/issues/39

‌

‌

[Torsten Lodderstedt]

PPID’s are specifically designated as being unique per consent (ie. should never overlap, ever…)

Well, wouldn’t that mean the client id per consent is the perfect fit? Just create a PPID per client id and you are done. No need for sector identifier et all.

re TLS certs: mTLS for OAuth ties client ids to certs and not the other way around. This makes authentication of multiple client ids with the sane key pair/cert an easy task.

[Stuart Low]

Well, wouldn’t that mean the client id per consent is the perfect fit? Just create a PPID per client id and you are done. No need for sector identifier et all.

Err… you’re suggesting a client id per consent or even per customer? This would result in a 1:1 relationship of a banks customer with a client id. Literally, millions of client id’s…

re TLS certs: mTLS for OAuth ties client ids to certs and not the other way around. This makes authentication of multiple client ids with the sane key pair/cert an easy task.

The ACDS specifies that mTLS is bound to an access token which, by definition, is bound to a specific client_id?

It states this is the same approach as 6.2.1 of the UK Open Banking Information Security Profile, which isn’t well linked but I believe it references this document that states “shall verify that the client identifier bound to the underlying mutually authenticated TLS transport session matches the client that the access token was issued to;”

‌

[Torsten Lodderstedt]

I mean client id per use case, i.e. PPID per client id & user.

mTLS: this sounds like an additional constraint beyond the mTLS draft, since the mTLS draft ties the access token to the fingerprint of the certificate used by the client not the client id.

[Stuart Low]

I mean client id per use case, i.e. PPID per client id & user.

I feel there may be some confusion here. PPID is a reference to an end user (what ACDS calls a “Consumer” or “Customer”) which seems out of scope in this context. ACDS is purely B2B comms, there is no direct browser based access.

A client_id per use case seems more logical but was rejected for the reasons given above:

This approach was evaluated and rejected on the basis that it was seen as overly complex for implementers, that transport layer certificates were intended to be tied to client_id’s (resulting in a cascading complexity problem for holders terminating TLS at the border) and that holders would be faced with a potentially exponential number of clients to manage.

I do agree though that from a pure OIDC/OAuth perspective it is perhaps the simplest solution but I do think it’s also quite inflexible. It also doesn’t solve for time based limits so this would need to be solved somewhere else anyway.

mTLS: this sounds like an additional constraint beyond the mTLS draft, since the mTLS draft ties the access token to the fingerprint of the certificate used by the client not the client id.

Maybe it is, I’d probably defer to @Ralph Bragg on this one since I believe he wrote this part of the OBUK spec.

[Torsten Lodderstedt]

This document https://www.accc.gov.au/system/files/ACCC CDR Rules Framework (final).pdf defines the requirements with respect to CDR in Australia. It distinguishes between consent (given at the data recipient/TPP/client) and authorisation (given at the data holder/ASPSP/AS).

The main requirements affecting the protocol I deduced are:

• each side must notify the other side of withdrawal/revocation of authorisation/consent
• authorisations shall be application specific (where a data recipient may have multiple applications)

‌

[Stuart Low]

‌

The main requirements affecting the protocol I deduced are:

each side must notify the other side of withdrawal/revocation of authorisation/consent

authorisations shall be application specific (where a data recipient may have multiple applications)

I’m wary of having the requirement distilled into these bullet points because I don’t believe it provides suitable coverage.

There is some discussion ongoing about what is a “notification”. There seems to be growing support for the idea that a notification can be an error code rejecting access stating “Consent Withdrawn” versus a deliberate push of the event from a Holder to a Recipient. As I understand it, this is under consideration by the ACCC but at this stage the existing approach of a CDR specific push notification from Holder to Recipient is still mandated.

Also, a clarification on the above language “authorisations shall be application specific (where a data recipient may have multiple applications)”. It is actually “authorisations shall be purpose specific (where a data recipient may have multiple purposes)”. This is an important nuance.

[Torsten Lodderstedt]

There is some discussion ongoing about what is a “notification”. There seems to be growing support for the idea that a notification can be an error code rejecting access stating “Consent Withdrawn” versus a deliberate push of the event from a Holder to a Recipient. As I understand it, this is under consideration by the ACCC but at this stage the existing approach of a CDR specific push notification from Holder to Recipient is still mandated.

Sounds reasonable. Was this broad up recently? I’m asking because I already mentioned this as the way in “traditional” OAuth to “notify” the client (https://bitbucket.org/openid/fapi/issues/276/consent-management-in-fapi#comment-55405088), which remained unnoticed.

Sidenote: shouldn’t the error description be “Authorization Withdrawn“?

Also, a clarification on the above language “authorisations shall be application specific (where a data recipient may have multiple applications)”. It is actually “authorisations shall be purpose specific (where a data recipient may have multiple purposes)”. This is an important nuance.

Why do you think this is an important nuance?

[Tom Jones]

This distinction is not a nuance at all. It goes to the heart of the privacy legislation, especially that in California. People do want to know why the data is being collected. otoh it is important where there is more than one brand that the user associate the request with the requestor. Still an application name is not that brand.

[Torsten Lodderstedt]

I`m struggling to understand the meaning of your comment.

I asked for the nuance between application and purpose. You are bringing up requestor and brand now.

In my experience, although application and purpose are quite different from a conceptual perspective, in reality purpose and application most likely will be the same. Why? Simply because the recipient must ensure purposeful use of the data received. It therefore must somehow compartmentalise its architecture to retain the association between data and purpose. Using distinct applications is an obvious choice.

‌

[Tom Jones]

Neither the law nor the specs should direct the developer on how to implement a solution. The user cares about the result - there is no concept of application in the user’s mind. There is, however, the concept of brand in everything that user user does online. So the brand is something the user can understand and something that purpose and grants can be bound to. The problem that FAPI (and OpenID in general) has had is the binding of anything that people understand to a url associated with a legal entity is obscure. The brand association seems to be a requirement for some of the UK OBIE participants; at least that is the way i read some of the comments.

[Joseph Heenan]

mTLS: this sounds like an additional constraint beyond the mTLS draft, since the mTLS draft ties the access token to the fingerprint of the certificate used by the client not the client id.

I believe it’s compliant with the standard. OBUK does not use self-signed MTLS. OBUK allows long lived access tokens, and they didn’t want to those access tokens & authorizations to become useless when the client rotated the MTLS key (as would happen if the access token was bound to the certificate fingerprint), hence they used signed certs and bind the access token to an identifier in the cert.

In my opinion (which happens to match what happened in the Australian specs) it’s better to mandate refresh tokens for long lived consents, which means after key rotation the client just obtains a new access token using the refresh token.

‌

[Torsten Lodderstedt]

I agree.

Depending on a client_id in the cert means:

• one cannot use the same cert for multiple client ids (which mTLS is explicitly designed for)
• this binding needs to attested, which requires a CA and precludes self-signed certs
• this binding needs to be checked, which goes beyond the mTLS for OAuth spec

I’m curious:

• What’s the rational for using long-lived access tokens? I’m asking since in order to have fresh user/account data available at the RS, one cannot use self-contained access tokens but is forced to use (and this limited to) handles & token introspection.
• How long do access tokens live in UK OB?

‌

[Joseph Heenan]

What’s the rational for using long-lived access tokens? I’m asking since in order to have fresh user/account data available at the RS, one cannot use self-contained access tokens but is forced to use (and this limited to) handles & token introspection.

I think that some banks did not want to (or possibly couldn’t in the required timescales) implement refresh tokens. I know in particular that one bank / TPP hates refresh tokens as they want to query the user’s available balance during a VISA payment authorisation (which has a strict time limit of something like 200ms) and they see the need to often swap a refresh token for an access token during this process as adding an unnecessary step that inevitably adds undesirable latency, hence they prefer long lived access tokens. (I am just quoting what they said; I don’t fully agree much of their rational!)

I’m not sure I understand what you meant by “in order to have fresh user/account data available at the RS”, but certainly there are issues with revoking self-contained access tokens that mean many (all?) implementations using long lived access tokens would use introspection to check the validity on each/most API calls.

(There is already a ticket on this topic; https://bitbucket.org/openid/fapi/issues/262/should-long-lived-access-tokens-be )

‌

How long do access tokens live in UK OB?

I think currently the longest an access token can live is 90 days, as the user is required to reconsent every days and I think the current methods for renewing a consent all involve a new authorization code grant and hence a new access token.

‌

‌

‌

[Tom Jones]

There is a conflation of the concept of consent as described in the GDPR and what the bank considers to be consent to make a transaction.

I might be best if these two concepts were separated as the long-lived consent to share data should have never been conflated with any other purpose.

[Torsten Lodderstedt]

@Joseph Heenan long living access token require token introspection. This means additional latency with every request in comparison to added latency for access token refresh. Moreover, I don’t see the problem with respect to the Visa use case. Make the access token good for a couple of minutes and you have a better balance.

[Daniel Fett]

FWIW, there will be a separate Grant Management document for FAPI 2.0.

[Joseph Heenan]

(Apologies for replying almost 2 months later…I missed the previous response arriving)

long living access token require token introspection. This means additional latency with every request in comparison to added latency for access token refresh.

I don’t disagree.

However it is a tradeoff.

Moreover, I don’t see the problem with respect to the Visa use case. Make the access token good for a couple of minutes and you have a better balance.

The VISA issue is comparing:

a) RP obtaining a new raccess token, RP call the api (no introspection by RS)

b) RP calling the API (and introspection by RS)

The argument was simply that ‘b' was in practice in UK banks often faster for the VISA use case and there’s a hard deadline of 200ms so faster is better.

(Personally I think the entire concept is flawed; expecting that either approach will reliably happen in under 200ms when relying on statutory access granted by PSD2 is daft.)

‌

The FAPI WG has so far been reticent to outright ban/discourage long lived access tokens, even though this causes issues with RP key rotation as noted above. I think I’ve lost track of what point we were/weren’t trying to make though.

‌

[Stuart Low]

Is this issue deprecated in favour of Grant Management API discussions?

[Tom Jones]

What is the answer to stuart’s question?

[Dima Postnikov]

Grant Management specification addresses this issue.

[Tom Jones]

I looked for consent in the spec, but see only three very vague references. As near as i can tell there is no proof of user consent in any way shape or form. I hope that is wrong - enlighten me.