<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Stuart,</p>
<p>You raise a valid and interesting point.</p>
<p>OBIE / Open Banking's current take at "federation" could put the
scheme at some point in future in a situation where it's cut off
from possibilities to evolve its institution trust model, grow
into new unforeseen areas, allow the implementation of new
financial services, etc.</p>
<p>If federation is a first-class concept in Open Banking,
orthogonal and permitting the full set of possible trust
relationships (m:n as Roland explained), Open Banking will then be
better prepared to meet unexpected future developments.<br>
</p>
<p>I wonder what can be reasonably done at this point.<br>
</p>
<p>Vladimir<br>
</p>
<pre class="moz-signature" cols="72">--
Vladimir Dzhuvinov</pre>
<p><br>
</p>
<div class="moz-cite-prefix">On 02/11/2019 06:07, Stuart Low via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:624d0baf-00ba-10db-d32d-9119f390f3bd@biza.io">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<p>I've been following this interest the OIDC Federation draft and
found myself asking how this specification relates to the work
OBIE and "open banking" communities have done with SSA's?
Personally I like where Federation is headed but OBIE (and soon
Australia) have gone down the SSA path. <br>
</p>
<p>Firstly, I might be way off the mark on the below so apologies
in advance. <br>
</p>
<p>There seems to be two patterns for similar outcomes (verifying
and maintaining an RPs trust using a third party).<br>
</p>
<p>As I understand it, Fed is a continually revalidated X509 trust
chain (with mutually designated parties) with client_id key's
being kept alive via OP's established X509 trust lines which are
used to revalidate RPs. These RPs may also be OPs in the other
direction. Additionally, the revalidation occurs between two
OPs, one that the RP provides a statement on that is endorsed
(A1 - "agreement 1") and one that has accepted a registration
from an RP and validated via A1 to produce A2. In essence this
allows for trust lines to be established in a M:N way. Is that
accurate?<br>
</p>
<p>On the OBIE SSA side, outside of MTLS certificates, the
registration process is verified at client_id establishment
using an SSA generated from a central registry/directory (OBIE)
with all parties trusting the directory (essentially M:1). In
the UK these SSA's are not rechecked (ie. only have an expiry
prior to client_id registration) with status being presented via
a private API (I think?!). In Australia the proposal is to have
similar SSA's with RP (called "Recipients") retrieve an SSA via
a service operated by a government authority which is then
presented to the OP for validation. For ongoing key management
there is a mandated DCR API: <a
href="https://cdr-register.github.io/register/#register-a-client-using-a-cdr-register-issued-software-statement-assertion"
moz-do-not-send="true">https://cdr-register.github.io/register/#register-a-client-using-a-cdr-register-issued-software-statement-assertion</a>
.<br>
</p>
<p>I guess where I'm headed with all this is that OIDC Federation
seems to be being developed/deployed within one environment
(academic) while the OB method is a few years down
implementation, has "corporate" adoption but isn't currently
part of an OpenID standard (I think?).<br>
</p>
<p>In many respects the trust establishment for Federation seems
like SSA's by a different name but the consideration for chains
of trusted parties seems particularly useful when looking at
diversifying the central authority. An example of this might be
if the Australian government was to decide a different sector
(ie. energy & telco versus banking) will be handled by a
different government department.<br>
</p>
<p>Considering the name of the spec is OIDC Federation I wonder if
there should be consideration to consider coverage in both
environments?<br>
</p>
<p>Personal opinion, I like SSA's from an "existing software
availability" perspective but architecturally I prefer
Federation because it looks like a crossover to a distributed
trust chain (eg. a "blockchain") in the, perhaps distant future,
could be quite elegant.<br>
</p>
<p>Thanks for your time,<br>
</p>
<p>Stuart<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 22/10/19 3:19 am, Mike Jones via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM6PR00MB0572F06920819AFE634BA97FF5690@DM6PR00MB0572.namprd00.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<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:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1960604163;
mso-list-type:hybrid;
mso-list-template-ids:2077406730 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
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:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
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:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
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:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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]-->
<div class="WordSection1">
<p class="MsoNormal">Draft 09 of the OpenID Connect Federation
specification has been published at <a
href="https://openid.net/specs/openid-connect-federation-1_0-09.html"
moz-do-not-send="true">https://openid.net/specs/openid-connect-federation-1_0-09.html</a>.
Major changes were:<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Separated
entity configuration discovery from operations provided by
the federation API.<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">Defined
new authentication error codes.<o:p></o:p></li>
</ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The authors believe that this version
should become an Implementer’s Draft, in preparation for
interop testing in the coming year. Please review!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">
Thanks,<o:p></o:p></p>
<p class="MsoNormal">
-- Mike<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
</blockquote>
<br>
</body>
</html>