<div dir="auto">We have plenty of evidence that a fully open system cannot be known to be secure. So the choice is pretty much exclusive, meaning no overlap.<div dir="auto"><br></div><div dir="auto">I have been using the term trust authority for the end point where both documentation and trust assertions can be retrieved. While I am not found of it, it does work.<br><br><div data-smartmail="gmail_signature" dir="auto">thx ..Tom (mobile)</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 13, 2021, 8:55 AM David Waite 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Adrian brought two good points on the SIOP Atlantic call today, but we unfortunately ran out of time.<br>
<br>
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.<br>
<br>
If another existing term is usable, I’d be all for considering it.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
-DW<br>
_______________________________________________<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" rel="noreferrer noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>