<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><br></div><div>Also note that certification is a necessary condition for trust, but not sufficient. 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" 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></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">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>