[Openid-specs-fapi] Issue #419: Grant Management feedback and questions (openid/fapi)

Dima Postnikov issues-reply at bitbucket.org
Wed Jun 2 14:42:14 UTC 2021

New issue 419: Grant Management feedback and questions

Dima Postnikov:

**Yaron Zehavi in #407**

* Regarding multi-party consents:

    * 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
    * WDYT?
* My understanding is that a grant is created **only** if and when a refresh token is issued. Would you agree that NO grant is created if no refresh token is issued?
* Regarding Grant Management for OAuth 2.0 spec:

    * Authorization Request - What is the need to support grant\_management\_action=create? Aren't approved authorization requests already creating grants implicitly without this new parameter?
    * Token Response - If you agree there’s a strong link between grant and refresh token, I suggest considering that grant\_id shall only be returned if refresh token is also returned
    * Grant Management API -> API authorization - I suggest to consider securing the Grant Management API with the refresh token used as bearer token. This achieves several benefits:
        * Removes burden from client to request a separate access token
        * Simplifies AS implementation as it removes the need to look up the grant, instead relying on extracting grant id from the refresh token
        * Provides stronger API security in case an attacker has succeeded to impersonate the client. Attacker would not be able to manipulate or query grants without also obtaining the individual refresh tokens
    * Query Status of a Grant - Keep in mind that the proposed API probably cannot fully replace open banking GET /consents/\{ConsentID\} because consent details may differ from grant details


More information about the Openid-specs-fapi mailing list