<div dir="ltr">OK - the zero trust stuff is over the top for that conversation - It happened to be top of mind for me because of this 170 page doc from the DoD <a href="https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf">https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf</a><div>I will target that more specifically.</div><div><br></div><div>I view trust somewhat differently than you. But I understand you are focused on the protocol part of trust. 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.</div><div><br></div><div>My definition of trust is that it is the projection of past behaviour into the future. But before that can happen, zero trust insists that the current message be bound to the past behaviour first.</div><div><br></div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 17, 2021 at 1:29 AM David Chadwick <<a href="mailto:d.w.chadwick@verifiablecredentials.info">d.w.chadwick@verifiablecredentials.info</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">
<div>
<p>I am happy with 0-3 but zero trust is questionnable.<br>
</p>
<div>On 16/05/2021 17:50, Tom Jones wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">we need to pry apart some terms here. Before we can
discuss, let alone choose a path, we must be clear on the terms
that we use. I will go back to the levels of assurance that I
continue to believe are required together with a clear idea for
the conditions at each level.
<div><br>
</div>
<div>0 self-assertion - this is typically sufficient to
establish a binding between two parties. The trust comes (as
it always does) from a history of good behavior. And, as with
other trust metrics, trust takes a long time to build and one
bad action to destroy.</div>
<div><br>
</div>
<div>1 self-test - this is what is used in openID and now in did
method registration. The governance body creates the test and
the developer runs the test and provides evidence of
compliance to a semi-automatic evaluation process.</div>
<div><br>
</div>
<div>2 one-time audit - this is used by the CA|B forum to test
review the policies, procedures and actual operations of the
entity. It does not test the specific instance at the specific
time of operations.</div>
<div><br>
</div>
<div>3 continuous audit - this is used by trusted hardware (such
as TPM 2 code running in a secure enclave) to assure that
current operation continues to meet the certification
criteria. This test is re-evaluated at every session
initiation or at specific high-value transactions.</div>
<div><br>
</div>
<div>Zero trust - means that every session, (and possibly every
interaction) re-evaluates the trust measures for the subject
and the resource requirements.</div>
</div>
</blockquote>
<p>On what basis is re-evaluation done, and how does it relate to
0-3 above? What is the difference between someone assertion 0 or
zero trust each time?<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Also note that certification is a necessary condition for
trust, but not sufficient. </div>
</div>
</blockquote>
<p>Certification is actually the opposite of trust. If I trust you I
don't need anything else. Trust is unmitigated risk for the
trustor. Certification is to reduce risk so that less trust is
needed. If I have 100% risk-free certification with guaranteed
payments for mistakes then I need to have no trust at all as I can
never suffer a loss.</p>
<p>Kind regards</p>
<p>David<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div>There still needs to be a root of trust. In the CA|B case
the root of trust is established by the browser, which can
withdraw trust from specific bad actions as they become
manifest.<br>
<div><br clear="all">
<div>
<div dir="ltr">
<div dir="ltr">
<div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">Be the change you want to see in the world </span>..tom</div>
</div>
</div>
</div>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, May 16, 2021 at 7:36
AM David Chadwick via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</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">
<div>
<p>Speaking as a VC software provider I obviously prefer
self-certification as this makes it much cheaper for me to
provide software to customers. But this path is fraught
with difficulties because some suppliers will
automatically cut corners in order to undercut the market.
We experienced this in the 1990 when PKI was just
starting. I acted as a consultant to the UK PO who
provided a first class CA service with warranties and
obligations to its customers, including guaranteed
payments to RPs if they screwed up on authenticating a
user. A PKC from the UK PO provided high assurance and a
high level of trust. But the service cost money. Shortly
afterwards Verisign appeared offering free PKCs to people.
And within a few years the UK PO shut down its CA service
as it was not profitable. But Verisign grew and grew and
eventually started charging for its PKCs. But the original
Verisign PKCs were valueless. I applied for a Bill Gates
PKC in the late 1990s and got one. I used this in my
security lectures at Kent for many years, until Verisign
eventually sold their service to the current owners, who
stopped issuing "persona non-validated PKCs". After
several years the CAB forum started, and produced rules
for issuing PKCs (DV, OV and EV ones). Under their rules a
PKC now became something you could trust, which was the
original intention of the X.509 model.</p>
<p>So to conclude, I don't believe self-certification will
work. Operators will hit the market to grab market share
offering cheap and shoddy products with all sorts of
privacy and security loopholes that customers will not be
aware of, until they are hit by them. I think trust
frameworks (or certification schemes) are going to be
essential in order to not tarnish the image of VCs (I
prefer the term VCs to SSI, because SSI is a myth, a dream
that can never truly happen. "No man is an island" even
though SSI likes to believe that everyone can be.)</p>
<p>Kind regards</p>
<p>David</p>
<p><br>
</p>
<div>On 13/05/2021 16:55, David Waite via Openid-specs-ab
wrote:<br>
</div>
<blockquote type="cite">
<pre>Adrian brought two good points on the SIOP Atlantic call today, but we unfortunately ran out of time.
First, the most easily discussed - trust frameworks are perhaps not the clearest term for the concept. In this context, the reference is to a body that makes a set of technical and non-technical requirements necessary for interoperability within a group, where that group is commonly referred to as a federation.
If another existing term is usable, I’d be all for considering it.
His second point, if I understood correctly, comes to whether a trust framework which attempts to audit/certify participants is compatible with various community goals, such as user choice in wallet software and general self-soverignity. This is most likely the longer conversation.
We’ve learned from experiences with Web Authentication, Web Payments and financial-grade API efforts that parties will have minimal requirements around things like user experience and security to adopt a system. Such federations may require a closed system, where only certified issuers, holders and verifiers are allowed to participate. In the worst case, a party may be blocked from participation by biased governance.
In the healthcare space (which I’m NOT an expert in by any means) the verifier may need to know whether or not a holder’s informed user consent process meets regulatory requirements before accepting a presented credential.
The goal would be to support both a model where participation is gated by the governance, auditing and certification processes of a federation, and a model where participation is via self-certification. This would be for all roles - issuers, verifiers and holders.
I lean toward more open participation where possible, and the hope would be that the simplicity of self-certification vs the maintenance of auditing/certification processes would be sufficient motivation to create open systems by default.
-DW
_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>