Multi Party Consents

[Stuart Low]

From @Yaron Zehavi https://bitbucket.org/openid/fapi/issues/407/grant-management-lifecycle#comment-60599018

• Issuing tokens upon 1st approval but before full consent seems sub-optimal. I’m aware this is how some API standards like Berlin group get things done, but I’m against it as it introduces higher complexity due to tokens that are "half baked" in the sense that they don't represent full authority to act
• Furthermore, managing authorization sub-resources is cumbersome for all parties. Additional challenges exist in multi-party flows as some consenting parties may not be digital-averse users, or may be digital but wish their identity remains unknown to client which contradicts with asking them to follow a redirect approval flow
• Improved solutions can be suggested for multi-party consent. Actually that was the main reason I recently joined FAPI WG. I propose that an AS serving a redirect based flow upon receiving 1st approval of a multi-party consent, shall instruct client to use CIBA polling until full consent is reached. Technically, the return redirect would return CIBA error=authorization_pending, and would provide the client additional details for CIBA polling such as the handle (which can be used as a secure ephemeral container for consent details making additional persistence not necessary). Moving to CIBA to wait for pending multi-party consent decouples the client from subsequent approvals, maintains the other approvers' privacy and supports other ways of receiving approval including non-digital methods

‌

[Ralph Bragg]

We already discussed the need to add CIBA style polling, ping, back off retry logic into Grant Management. Isn’t there a TODO ticket already?

[Dima Postnikov]

Assuming we are discussing redirect flows…

1. In some use cases, for example, account aggregation it’s ok to have an access token used by the client as-is assuming some accounts were authorised for sharing (partially authorized grant). End user might benefit from seeing some data coming through even if it is not a complete set. In this scenario @Ralph Bragg has suggested that we need to look at a way to rate limit requests https://bitbucket.org/openid/fapi/issues/408/grant-management-errors-rate-limiting.

2. In other use cases, for example. credit assessment, the client might choose to wait till all resources are authorized before accessing the data. There are two ways to deal with this:

   1. Use the same approach as #1 above. Poll until grant is fully authorized or it expires (assuming that client can see that there are some resources not fully authorized).
   2. Use approach as described by @Yaron Zehavi return “CIBA handle” to the client and tell client to use CIBA to retrieve access tokens when authorization is done (e.g.: poll mode)

Should a Client be able to tell AS that they happy to receive what they can immediately or wait till everything is ready to be authorized?

Can we demand that CIBA is supported by every AS that supports Grant Management?

Anything else can be added to the use cases above?

We have discussed 2b as an option a while ago but decided to proceed with implementation draft 1 without it. Is there immediate use case in any jurisdiction where this is required?

‌

[Yaron Zehavi]

@Dima Postnikov Thank you for your comments.

Indeed I was referring to redirect based flows, and saw CIBA as a way to elegantly solve multi party consents.

Regarding #1, coming from the banking industry, we view it to be a breach of privacy to provide client with ANY information dependent on a multi-party consent, before full consent has been granted. Look at it that way - if one of the parties that has not yet granted consent intends to refuse, the information provided breaches their privacy before they had a chance to respond. If said party sues the bank, there is no defense and full liability because it had no grounds to provide private information.

‌

Therefore it should not be up to the client to decide whether to opt for partial or full information, but up to the OP and resource server to decide when any information should be made available.

‌

I don’t think we should demand every AS to support CIBA at all, or to support the “conversion“ path from redirect-based to CIBA in case of partial multi-party consents.

But we’d like to see it integrated into the openid connect standards and we have a use case for it. This is how we’d like to implement operation approvals (payments etc) across our group and we’ve asked our vendor (Ping Identity) for such a solution and they suggested we join FAPI WG to incorporate it into the standards.

[Dima Postnikov]

It’s a good idea and we have discussed it few times already. We need to look at multi party consent more holistically, potentially outside of Grant Management specification. We would like to have a look at it after Implementers Draft 1.

[Dima Postnikov]

Will defer till the next version

[Nat Sakimura]

Waiting for specific use-cases to drive the requirements.