[Openid-specs-fapi] Australian CDR Concurrent Consent

Stuart Low stuart at biza.io
Tue Apr 21 23:30:42 UTC 2020


Hi Brian,

Last time I checked Yodlee wasn’t an IdP vendor so no, I wasn’t thinking about your business.

I would highlight though that, side by side with vendors willingness to prioritise commercial benefit over international standards alignment, prospective Data Recipients have made limited contributions to the process resulting in D61 proceeding with proposals because they “didn’t receive opposition from Recipients”. When I was working within the DSB lack of recipient participation was a key issue that other members of the team actually seemed to prefer so they could make unilateral decisions on things they don’t fully understand.

Regarding ACCC contact, for over 12 months now overtures have been made by FDATA (and others) regarding this contact but at this stage very little has come out of it. Realistically ACCC is the lead regulator but D61/DSB are the technical standards body and apparently this turf has been aggressively defended.

FAPI WG members, including Nat as Chair, have repeatedly requested D61/ACCC participation but, outside of the first InfoSec lead (who left D61 in frustration in early 2019) there have never been D61/DSB members in attendance. The reasons given are various with the “goto” excuse being that D61 doesn’t want to sign an IPR. I find this ironic considering everything that’s being released is done so under an MIT license although it does highlight that certain individuals, including those who lurk on this mailing list, use false assertions with non-technical people to avoid having their solution exposed to any reasonable form of academic rigour (a cornerstone of CSIRO/D61’s values).

Personally, while Biza is focused on the Australian CDR sector, I’m of the opinion that Australia will remain an technology island and consequently growth and adoption of the local ecosystem is likely to be constrained to the same players who own the financial data space now. 

Stuart


> On 22 Apr 2020, at 5:57 am, Brian Costello via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
> 
> Hi all, I’m hoping that you all don’t think Yodlee is one of the two.  If so, I’d like to learn more about this.  I’d also like to see if we can help shine more light on this with the ACCC, perhaps via FDATA AU/NZ?
>  
> Kind Regards
> Brian
>  
> From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net <mailto:openid-specs-fapi-bounces at lists.openid.net>> On Behalf Of Nicholas Irving via Openid-specs-fapi
> Sent: Monday, April 20, 2020 7:13 PM
> To: Financial API Working Group List <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>>
> Cc: Nicholas Irving <nirving at darkedges.com <mailto:nirving at darkedges.com>>
> Subject: Re: [Openid-specs-fapi] Australian CDR Concurrent Consent
>  
> External email, verify before opening attachments or links.
> 
> 
> You have hit the nail on the head with your last comment, as that is something I have felt from the beginning. I would prefer standards over commercial but it seems they are being lead by people concerned with selling their products and it shone through in a number of meetings. 
>  
> Also the architects solve problems by making it the implementors problem, without thinking about the impact to existing systems.
>  
> Nicholas
>  
>  
> 
> On Tue, 21 Apr 2020, 11:32 Stuart Low via Openid-specs-fapi, <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>> wrote:
> Hi there,
> 
> The Australian Data Standards Body has released an updated concurrent
> consent proposal here:
> https://github.com/ConsumerDataStandardsAustralia/standards/files/4490840/Decision.99.-.Concurrent.Consent.pdf <https://github.com/ConsumerDataStandardsAustralia/standards/files/4490840/Decision.99.-.Concurrent.Consent.pdf>
> 
> Despite submissions from numerous participants including the FAPI WG the
> DSB seems to be determined to adopt their own untested approach to
> consent management while acknowledging it will be unsuitable for known
> future requirements. The proposals put forward by the FAPI WG have been
> "considered" but not adopted for either unspecified reasons or due to
> their "draft" status which is ironic since the proposal from the DSB
> appears to be not only draft in nature but by and large not yet
> implemented by participants.
> 
> The vendor landscape within Australia is quite limited but the two
> primary parties involved are both OIDF members. It remains to be seen as
> to whether they will prioritise commercial benefit over international
> standards alignment.
> 
> Stuart
> 
> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi <http://lists.openid.net/mailman/listinfo/openid-specs-fapi>
> 
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net <mailto:Openid-specs-fapi at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi <http://lists.openid.net/mailman/listinfo/openid-specs-fapi>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200422/cf5dfd81/attachment-0001.html>


More information about the Openid-specs-fapi mailing list