<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <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">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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </blockquote>
  </body>
</html>