<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Roland</p>
    <p>once SIOP is in use with user wallets, why is client registration
      needed? I ask this, because when I am using my browser I go to
      multiple web sites without knowing anything about them first. I
      might buy something from a RP that I have never visited before. No
      prior registration of either myself nor the RP is needed.</p>
    <p>So why cannot it work in the same way with SIOP and VCs? The only
      meta data that is needed prior to any user involvement is that the
      RP has to know the meta data of the VC Issuers that it trusts. The
      RP has to know the the VC issuer's X.509 PKC and understand the
      schema of the VCs it will issue, and then we are good to go. The
      user visits the RP's web site, it sends its claim requirements to
      the user's SIOP wallet, the user chooses VCs that match this and
      returns a VP to the RP. The RP then validates PoP and that the VCs
      were issued by the trusted Issuers. Can you critically appraise
      this model please.<br>
    </p>
    <p>Kind regards</p>
    <p>David<br>
    </p>
    <div class="moz-cite-prefix">On 28/06/2021 08:49, Roland Hedberg via
      Openid-specs-ab wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:98C09897-CB8E-4179-A213-6556BEAA430D@catalogix.se">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Hi !
      <div class=""><br class="">
      </div>
      <div class="">Thanks Torsten for your comments. I’ll start the
        answer with the design criteria we had:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">- So far we’ve seen a small number of
          federation models. One-to-many (Google's 1 OP, many RPs or
          Amazon's 1 RP and many OPs) and small to fairly large multi
          lateral federations like EduGAIN (~4400 OPs and 3300 RPs). All
          of them based on centralised static registration. In order to
          allow multi lateral federations to grow in size we think that
          it’s necessary to move to decentralised dynamic registration
          (imaging if SIOP takes off). </div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal; min-height: 14px;" class=""><br class="">
        </div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">- One-to-many OIDC federations normally uses
          dynamic provider info discovery but not dynamic client
          registration. </div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">Which is not that surprising since classic
          OIDC client registration in essence is a leap of faith. There
          is no way you as an OP can </div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">verify that the client metadata is correct.
          We would like to make client registration more robust and
          allow OPs to verify</div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">the correctness of the client metadata.</div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal; min-height: 14px;" class=""><br class="">
        </div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">- Federation policies will change over time
          (like moving from SHA1 to SHA256) we would like to support
          that and to have built-in</div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">support for policies to change
          dynamically. Also, having decentralised entity registration we
          need a way to enforce federation policies.</div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal; min-height: 14px;" class=""><br class="">
        </div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">- OIDC and OAuth2 both have defined APIs for
          provider info discovery and client registration the federation
          specification should </div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">work equally well for both.</div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal; min-height: 14px;" class=""><br class="">
        </div>
        <div style="margin: 0px; font-stretch: normal; line-height:
          normal;" class="">- The messages pushed around in this
          specification should not depend on TLS for their protection. </div>
        <div class=""><br class="">
        </div>
        <div class="">- We should when possible use functionally already
          present in OIDC libraries (like key handling, signed JWT
          verifications, JWKS, ..)</div>
        <div class=""><br class="">
        </div>
        <div class="">- We should only touch the initial OIDC
          RP<->OP communication phases (provider info discovery
          and client registration).</div>
        <div class="">Now, this changed during the work of the
          specification so there now is one use case where we touch the
          authorization request.</div>
        <div class=""><br class="">
        </div>
        <div class="">- An entity (OP or RP) should be able to belong to
          more the one federation.</div>
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">On 30 May 2021, at 18:38, Torsten Lodderstedt
              <<a href="mailto:torsten@lodderstedt.net" class=""
                moz-do-not-send="true">torsten@lodderstedt.net</a>>
              wrote:</div>
            <div class="">
              <div class=""><br class="">
                I think an overview describing and motivating the design
                concepts and principles would be helpful to readers. <br
                  class="">
                <br class="">
                I would also appreciate an explanation why the
                federation draft design is better suited for the
                envisioned use cases than X.509 certificates.
                Deployments need to be convinced to invest into a pretty
                new solution with a lot of runtime overhead (latency and
                availability implications!) while X.509 is used for the
                same/similar (?) applications in the wild. I’m pretty
                sure there a good arguments ;-). <br class="">
              </div>
            </div>
          </blockquote>
        </div>
        <br class="">
        <div class="">
          <div dir="auto" style="word-wrap: break-word;
            -webkit-nbsp-mode: space; line-break: after-white-space;"
            class="">
            <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);
              font-family: Helvetica; font-size: 12px; font-style:
              normal; font-variant-caps: normal; font-weight: normal;
              letter-spacing: normal; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              text-decoration: none;">— Roland</div>
            <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);
              font-family: Helvetica; font-size: 12px; font-style:
              normal; font-variant-caps: normal; font-weight: normal;
              letter-spacing: normal; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              text-decoration: none;"><br class="">
            </div>
            <div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);
              font-family: Helvetica; font-size: 12px; font-style:
              normal; font-variant-caps: normal; font-weight: normal;
              letter-spacing: normal; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              text-decoration: none;">Were it left to me to decide
              whether we should have a government without newspapers, or
              newspapers without a government, I should not hesitate
              a moment to prefer the latter. -Thomas Jefferson, third US
              president, architect, and author (1743-1826) </div>
          </div>
        </div>
        <br class="">
      </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>