<div dir="ltr">US Healthcare is headed in the direction of a "Capabilities Statement" which meets AFAIK the meaning of an SSA.<div>Roland and Nick excluded the concerns of federation in this class of application at the start of the federation doc, so we look at the doc as advisory only. It is not strictly usable as written. I doubt that Nat will allow this doc to be posted to the group.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 4, 2019 at 1:12 PM Vladimir Dzhuvinov via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div 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 cols="72">-- 
Vladimir Dzhuvinov</pre>
    <p><br>
    </p>
    <div>On 02/11/2019 06:07, Stuart Low via
      Openid-specs-ab wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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" target="_blank">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>On 22/10/19 3:19 am, Mike Jones via
        Openid-specs-ab wrote:<br>
      </div>
      <blockquote type="cite">
        
        
        
        <div>
          <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" target="_blank">https://openid.net/specs/openid-connect-federation-1_0-09.html</a>. 
            Major changes were:<u></u><u></u></p>
          <ul style="margin-top:0in" type="disc">
            <li style="margin-left:0in">Separated
              entity configuration discovery from operations provided by
              the federation API.<u></u><u></u></li>
            <li style="margin-left:0in">Defined
              new authentication error codes.<u></u><u></u></li>
          </ul>
          <p class="MsoNormal"><u></u> <u></u></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!<u></u><u></u></p>
          <p class="MsoNormal"><u></u> <u></u></p>
          <p class="MsoNormal">                                                      
            Thanks,<u></u><u></u></p>
          <p class="MsoNormal">                                                      
            -- Mike<u></u><u></u></p>
          <p class="MsoNormal"><u></u> <u></u></p>
        </div>
      </blockquote>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>