<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 30, 2025 at 1:03 PM Vladimir Dzhuvinov / Connect2id <<a href="mailto:vladimir@connect2id.com" target="_blank">vladimir@connect2id.com</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"><u></u>

  
    
  
  <div>
    <div>Hi Dick,<br>
    </div>
    <div>On 23/01/2025 16:52, Dick Hardt wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi Vladimir
        <div><br>
        </div>
        <div>By "enterprise app" are you referring to internal apps, or
          a B2B SaaS app? Internal apps can have direct access to the
          directory in many cases, so I'm assuming you are referring to
          B2B SaaS apps.</div>
      </div>
    </blockquote>
    <p>Both actually. In those cases when we dealt with internal apps to
      be integrated via OIDC, the aim was to regulate access to the user
      data via the OpenID provider, and close off LDAP access.</p></div></blockquote><div>Got it. It is common to use the same mechanism internally and externally to provide a clear separation of concerns.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>What I like about the "Commands" is that it may simplify the
      necessary dealings for apps to be GDPR compliant. Managing that
      via the OIDC layer looks appealing.<br></p></div></blockquote><div>Glad to hear! Would you elaborate on what aspect of GDPR compliance you are thinking OIDC can help with?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <blockquote type="cite">
      <div dir="ltr">
        <div>In my experience, an app needs to have a robust DB of user
          data. The OP knows when the data changes, so can push to the
          RP whenever there is a change, To ensure there the data is in
          sync in case a command was missed or something, the OP
          occasionally can send a tenant_audit command to ensure the RP
          has what the OP thinks it should have.</div>
      </div>
    </blockquote>
    <p>The task to supply user data in an app, in a persistent and
      well-structured fashion, looks easier when that's built on top of
      a RESTful resource. </p></div></blockquote><div>I think you just described SCIM.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>Rather than on incoming RPC. App developers
      are more comfortable with RESTful resources and there is more
      available software to deal with that.<br></p></div></blockquote><div>The RP endpoint is a webhook. A deployment model developers are familiar with. There are plenty of libraries to verify a JWT which is what is passed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <p>An OP resource for the accounts and tenants will not make the
      JWTs to notify of state changes redundant. They'd still be useful 
      to tell the RP to update its state.<br></p></div></blockquote><div>Setting up and managing the authentication between parties is one of the complexities of SCIM (which does not specify how to do it), and one of the areas OP Commands simplifies by reusing the mechanisms used for ID Tokens.</div><div><br></div><div><br></div></div></div>
</div>