<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">Also having other sectors beyond R&E care about this will make it a lot more likely that diverse implementations will be created and maintained.</p>
<p dir="auto">Nick</p>
<p dir="auto">On 4 Nov 2019, at 14:04, Vladimir Dzhuvinov via Openid-specs-ab wrote:</p>
</div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="FC264F70-267A-45B7-B69E-2889186A7A98">
  <div 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>
  </div></div></blockquote>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">
</blockquote><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">_______________________________________________<br>
Openid-specs-ab mailing list<br>
Openid-specs-ab@lists.openid.net<br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color:#777">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></p>
</blockquote></div>
</div>
</body>
</html>