<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1478957817;
mso-list-type:hybrid;
mso-list-template-ids:-274553054 134807553 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;
mso-bidi-font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;
mso-bidi-font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;
mso-bidi-font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;
mso-bidi-font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;
mso-bidi-font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;
mso-bidi-font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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 </span><a href="https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md">https://bitbucket.org/openid/fapi/src/master/FAPI_2_0_Baseline_Profile.md</a><span style="mso-fareast-language:EN-US"> 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">General Comments: <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1"><span style="mso-fareast-language:EN-US">Introducing a consent management API, ala Open Banking UK<o:p></o:p></span></li><ul style="margin-top:0cm" type="circle">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level2 lfo1"><span style="mso-fareast-language:EN-US">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?<o:p></o:p></span></li></ul>
</ul>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo1"><span style="mso-fareast-language:EN-US">Adding a new claim introduced into AS request.<o:p></o:p></span></li><ul style="margin-top:0cm" type="circle">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level2 lfo1"><span style="mso-fareast-language:EN-US">This is then posted using PAR with justifications for PAR adopted given around security and payload size.<o:p></o:p></span></li><ul style="margin-top:0cm" type="square">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level3 lfo1"><span style="mso-fareast-language:EN-US">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 <b>PAR</b> in the timescales suggested.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level3 lfo1"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level3 lfo1"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level3 lfo1"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></li></ul>
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level2 lfo1"><span style="mso-fareast-language:EN-US">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?<o:p></o:p></span></li></ul>
</ul>
<p class="MsoListParagraph" style="margin-left:72.0pt"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<ul style="margin-top:0cm" type="circle">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level2 lfo1"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></li></ul>
</ul>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Openid-specs-fapi <openid-specs-fapi-bounces@lists.openid.net> on behalf of Nat Sakimura via Openid-specs-fapi <openid-specs-fapi@lists.openid.net><br>
<b>Reply to: </b>Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Date: </b>Thursday, 26 March 2020 at 03:07<br>
<b>To: </b>Financial API Working Group List <openid-specs-fapi@lists.openid.net><br>
<b>Cc: </b>Nat Sakimura <sakimura@gmail.com><br>
<b>Subject: </b>[Openid-specs-fapi] Fwd: [ConsumerDataStandardsAustralia/standards] Decision Proposal 099 - Concurrent Consent Target State (#99)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
FYI<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">---------- Forwarded message ---------<br>
From: <strong><span style="font-family:"Calibri",sans-serif">CDR API Stream</span></strong> <<a href="mailto:notifications@github.com">notifications@github.com</a>><br>
Date: Thu, Mar 26, 2020 at 11:47 AM<br>
Subject: Re: [ConsumerDataStandardsAustralia/standards] Decision Proposal 099 - Concurrent Consent Target State (#99)<br>
To: ConsumerDataStandardsAustralia/standards <<a href="mailto:standards@noreply.github.com">standards@noreply.github.com</a>><br>
Cc: Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>>, Comment <<a href="mailto:comment@noreply.github.com">comment@noreply.github.com</a>><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<p>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.<o:p></o:p></p>
<p>This decision proposal outlines a recommendation for enabling concurrent, or overlapping, consents under the CDR regime.<o:p></o:p></p>
<p>The consultation draft for this decision proposal is attached below:<br>
<a href="https://github.com/ConsumerDataStandardsAustralia/standards/files/4384356/Decision.Proposal.99.-.Concurrent.Consent.pdf" target="_blank">Decision Proposal 099 - Concurrent Consent.pdf</a><o:p></o:p></p>
<p>Feedback is now open for this proposal. Feedback is planned to be closed on the 9th of April 2020.<o:p></o:p></p>
<p><span style="font-size:12.0pt;color:#666666">—<br>
You are receiving this because you commented.<br>
Reply to this email directly, <a href="https://github.com/ConsumerDataStandardsAustralia/standards/issues/99#issuecomment-604196943" target="_blank">
view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AABFEN7IDGFXRI566J52FE3RJK62XANCNFSM4KPNBKCA" target="_blank">
unsubscribe</a>.<span style="border:solid windowtext 1.0pt;padding:0cm"><img border="0" width="1" height="1" style="width:.0104in;height:.0104in" id="_x0000_i1025" src="cid:~WRD0001.jpg" alt="Image removed by sender."></span><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Nat Sakimura (=nat) <o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>