[Openid-specs-fapi] Issue #420: Multi Party Consents (openid/fapi)

Stuart Low issues-reply at bitbucket.org
Tue Jun 8 11:04:24 UTC 2021


New issue 420: Multi Party Consents
https://bitbucket.org/openid/fapi/issues/420/multi-party-consents

Stuart Low:

**From** @{6090fabccc7830006a408a7e} [https://bitbucket.org/openid/fapi/issues/407/grant-management-lifecycle#comment-60599018](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

‌



More information about the Openid-specs-fapi mailing list