<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 17/05/2021 17:49, Tom Jones wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAK2Cwb7oUhB51FTo+ivUrik-JiDjO+gABEVZtin15D2MYRXfFg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">Yes, that is my level zero. So attribute based
        access control is what you dislike.</div>
    </blockquote>
    No, how did you infer that? I quite like it.<br>
    <blockquote type="cite"
cite="mid:CAK2Cwb7oUhB51FTo+ivUrik-JiDjO+gABEVZtin15D2MYRXfFg@mail.gmail.com">
      <div dir="auto"> This is the very place where a did pseudonym can
        work if we can overcome the addressing issues. Which are
        blocking right now.<br>
      </div>
    </blockquote>
    <p>Its did pseudonyms that are more problematic for me, not least
      because large ACLs will be needed, also there are over 90
      registered methods which are growing all the time. And blockchains
      are typically needed if you want to resolve dids to did documents.<br>
    </p>
    <p>Kind regards</p>
    <p>David<br>
    </p>
    <blockquote type="cite"
cite="mid:CAK2Cwb7oUhB51FTo+ivUrik-JiDjO+gABEVZtin15D2MYRXfFg@mail.gmail.com">
      <div dir="auto"><br>
        <div data-smartmail="gmail_signature">thx ..Tom (mobile)</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Mon, May 17, 2021, 9:36 AM
          David Chadwick <<a
            href="mailto:d.w.chadwick@verifiablecredentials.info"
            moz-do-not-send="true">d.w.chadwick@verifiablecredentials.info</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div>
            <p><br>
            </p>
            <div>On 17/05/2021 17:18, Tom Jones wrote:<br>
            </div>
            <blockquote type="cite">The Zero trust part says that i do
              not trust any message that i receive until i have had the
              opportunity to vet it to the level of assurance that is
              appropriate for the transaction. That vetting may be
              included in the session ID or some other evaluation, but
              some process does occur on every message received.</blockquote>
            <p>this I do agree with. But in my mental model, a RP is
              contacted by a stranger who wants to access one of its
              protected resources. The RP returns its policy to the
              stranger (which sets out which VCs containing which
              identity attributes it wants from which issuers) and the
              stranger returns a VP. The RP verifies that the VP belongs
              to the stranger, and that issuers it trusts have certified
              the various identity attributes of the stranger. So now
              the RP can apply an ABAC policy/PDP to grant access to the
              stranger using the validated attributes of the stranger.</p>
            <p>The RP can repeat this for each resource it owns, i.e.
              zero trust for each different resource access request,  by
              assigning different policies to each resource. In this way
              least privileges can be implemented as the stranger does
              not need to provide all the attributes on the initial
              login request (which they do with SAML (and OIDC?), as
              this leads to maximal privileges).</p>
            <p>Kind regards</p>
            <p>David<br>
            </p>
            <p><br>
            </p>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>