<div dir="auto">Amen bro, howsoever, I am ready to pick one method and try to get it adopted by one trust authority.<br><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, 1:48 PM David Waite <<a href="mailto:david@alkaline-solutions.com">david@alkaline-solutions.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">On May 17, 2021, at 10:55 AM, David Chadwick via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-ab@lists.openid.net</a>> wrote:<br><div><blockquote type="cite"><div><div><div>On 17/05/2021 17:49, Tom Jones wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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">
      <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></div></div></blockquote><div>Personally, I find it very challenging to find a definitive use case for DIDs.</div><br>The a wide range of method specifications and optional features, along with the lack of a baseline set of capabilities from a DID document, make generalized DID acceptance very difficult. Between the correlation concerns and the need to negotiate acceptable DID methods, I suspect that public DIDs will be finer-grained than personas to account for the differing requirements for interoperability with other parties. In other words, I have doubts that a single public-facing identifier will have enough baseline functionality and acceptance to really work across use cases/federations without being specifically chosen with that interoperability in mind.</div><div><br></div><div>On the other hand, you can have pairwise DIDs within pairwise relationships - but that might not have as much value as public scenarios. In pairwise scenarios, the metadata of what a subject identifier means does not need to be globally resolved/persisted - it is part of the context of that pairwise relationship. The did:peer method exists specifically around the idea that it may be a pointer to a non-externally-resolvable representation of current metadata.</div><div><br></div><div>The gaps where they appear to be most useful is in non-hosted issuers, web of trust scenarios and for supporting n-wise relationships. However, the DID method resolution process may be substantial and a universal DID resolver must be engineered as a trusted system, perhaps pushing these scenarios down even harder to supporting a limited set of DID methods.</div><div><br></div><div>-DW</div><div><blockquote type="cite"><div><div><p>Kind regards</p><p>David<br>
    </p>
    <blockquote type="cite">
      <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" target="_blank" rel="noreferrer">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>
  </div>

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