<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">Am 25.10.2019 um 03:15 schrieb Tatsuo Kudo via Openid-specs-fapi <openid-specs-fapi@lists.openid.net>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  
  
    <p>I tend to explain the part 1 and 2 like:</p>
    <ul>
      <li>Part 1: OAuth 2.0 deployment practice + OAuth 2.0 extension
        specs</li>
      <li>Part 2: Part 1 + OIDC deployment practice + OIDC extension
        specs</li>
    </ul>
    <p>So how about:</p>
    <ul>
      <li>Part 1: FAPI OAuth 2.0 Profile (FAPI-OAuth)</li>
      <li>Part 2: FAPI OpenID Connect Profile (FAPI-OIDC)</li></ul></div></blockquote><div>As Nat described, the idea is to have security profiles on certain levels, both for OAuth. OpenID can be done with either profiles.</div><div><br></div><div>Right now read and read/write do not have a clear definition in terms of security protection goals and attacker model. The first idea is to make “substantial” (medium) the profile ensuring authenticity of all parties (e.g. client authentication) and preventing any sort of replay (PKCE & sender constrained tokens). “High” should go further and add application level non-repudiation.</div><div><br></div><div>best regards,</div><div>Torsten.</div><blockquote type="cite"><div dir="ltr"><p>Just my 2c.</p>
    <p>Tatsuo.<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2019/10/25 0:34, Nat Sakimura via
      Openid-specs-fapi wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:94105ddc1684f915f2190006fed403c5@sakimura.org">Hi
      <br>
      <br>
      Back in the IIW, I discussed with Torsten about the potential
      title change of Part 1 and Part 2. Currently, they are Read Only
      and Read&Write respectively but there are cases where the read
      only data is very sensitive while write operation is not of high
      value.
      <br>
      <br>
      Thus, we agreed that the current name may not be representing the
      real intention: Medium and High security profile respectively.
      <br>
      <br>
      During the discussion, we came up with the name:
      <br>
      <br>
      - Substantial (for Part 1)
      <br>
      - High (for Part 2)
      <br>
      <br>
      It follows eIDAS marking.
      <br>
      <br>
      More details are recorded in the ticket #271.
      <br>
      <br>
<a class="moz-txt-link-freetext" href="https://bitbucket.org/openid/fapi/issues/271/rename-and-adjust-fapi-profiles">https://bitbucket.org/openid/fapi/issues/271/rename-and-adjust-fapi-profiles</a>
      <br>
      <br>
      The participants in the Oct. 9 call all agreed to it.
      <br>
      This mail is to solicit wider opinions on it.
      <br>
      <br>
      Please let us know of your opinions.
      <br>
      <br>
      Best,
      <br>
      <br>
      Nat Sakimura
      <br>
      Chair, FAPI WG.
      <br>
      _______________________________________________
      <br>
      Openid-specs-fapi mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.openid.net</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a>
      <br>
    </blockquote>
  

<span>_______________________________________________</span><br><span>Openid-specs-fapi mailing list</span><br><span>Openid-specs-fapi@lists.openid.net</span><br><span>http://lists.openid.net/mailman/listinfo/openid-specs-fapi</span><br></div></blockquote></body></html>