[Openid-specs-fapi] Fwd: [ConsumerDataStandardsAustralia/standards] Decision Proposal 099 - Concurrent Consent Target State (#99)

Ralph Bragg ralph.bragg at raidiam.com
Thu Mar 26 06:07:33 UTC 2020


Thanks for the proposal – great to see new standards being considered to address some of the challenges that the community has raised. A lot of inspiration appears to have come from the FAPI 2.0 draft https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md which is available for review and all comments welcome. It would be great for global interoperability if Data61 / CSIRO could cross reference the proposal here against the FAPI 2.0 spec and provide a profile that clearly calls out the differences. This would simplify implementation challenges for vendors, banks and the security community alike.

General Comments:


  *   Introducing a consent management API, ala Open Banking UK
     *   This is a proven well adopted pattern, as it’s essentially lodging request and an ID is returned.  Is the intention or direction of travel to extend this API to incorporate fine grained consent and if so, has RAR (Rich Authorization Request) been considered?


  *   Adding a new claim introduced into AS request.
     *   This is then posted using PAR with justifications for PAR adopted given around security and payload size.
        *   Security Comment 1; the enumeration attack to swap or change a sharing_id with another valid one is minimal in my opinion vs the overhead of requiring PAR in the timescales suggested.
        *   Security Comment 2; If this really is deemed to be a significant security issue then JAR and encrypted JAR would mitigate this issue alone which is far more likely to be supportable by vendors as they have similar capability from the OIDC Request Object by Reference and the requirement for its use in FAPI 1.0 today.
        *   Size; the inclusion of a sharing ID will not materially increase the payload size. PAR is really only required if a RAR is also going to be used.
        *   If PAR is adopted why is OIDC hybrid still being used instead of PKCE RFC7636? If the ecosystem is considering such a fundamental change then aligning to FAPI 2.0 or baselining the profile requirements against this specification might be useful.
     *   Given that this proposal is mostly the  “lodging intent pattern” there are standards adopted in market that could achieve the objective that are already vendor supported have data holders expressed any concerns about adoption of PAR in the timescales?



     *   As I understood it the security challenge around issue 74 previously was about the passing of an expired credential via an untrusted network segment but this appears to being used to justify not putting anything through the front channel. Fine principle but I’m concerned about ecosystem implementation timelines for vendors and data holders.

Generally, I’m all for using RAR,PAR,JAR etc if fine grained sharing is in scope, which it isn’t with this proposal. Given that it is a very similar model to what is currently used by the OBIE I wonder what the impact will be by requiring the ecosystem and their vendors to uplift to PAR for this requirement alone? If Data61 / CSIRO would signal that they then would look to moving to RAR instead of a sharing API post November then requiring banks now to make this uplift to support RAR in the future would be much easier to justify.


From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of Nat Sakimura via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
Reply to: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
Date: Thursday, 26 March 2020 at 03:07
To: Financial API Working Group List <openid-specs-fapi at lists.openid.net>
Cc: Nat Sakimura <sakimura at gmail.com>
Subject: [Openid-specs-fapi] Fwd: [ConsumerDataStandardsAustralia/standards] Decision Proposal 099 - Concurrent Consent Target State (#99)


FYI
---------- Forwarded message ---------
From: CDR API Stream <notifications at github.com<mailto:notifications at github.com>>
Date: Thu, Mar 26, 2020 at 11:47 AM
Subject: Re: [ConsumerDataStandardsAustralia/standards] Decision Proposal 099 - Concurrent Consent Target State (#99)
To: ConsumerDataStandardsAustralia/standards <standards at noreply.github.com<mailto:standards at noreply.github.com>>
Cc: Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>>, Comment <comment at noreply.github.com<mailto:comment at noreply.github.com>>


Hi everyone, thanks for your feedback. Based on the feedback raised by the community, changes have been incorporated into an updated decision proposal for concurrent consent.

This decision proposal outlines a recommendation for enabling concurrent, or overlapping, consents under the CDR regime.

The consultation draft for this decision proposal is attached below:
Decision Proposal 099 - Concurrent Consent.pdf<https://github.com/ConsumerDataStandardsAustralia/standards/files/4384356/Decision.Proposal.99.-.Concurrent.Consent.pdf>

Feedback is now open for this proposal. Feedback is planned to be closed on the 9th of April 2020.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/ConsumerDataStandardsAustralia/standards/issues/99#issuecomment-604196943>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AABFEN7IDGFXRI566J52FE3RJK62XANCNFSM4KPNBKCA>.


--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200326/2a06d833/attachment-0001.html>


More information about the Openid-specs-fapi mailing list