[Openid-specs-ab] SIOP, Trust Frameworks, and SSI/Open Source

Tom Jones thomasclinganjones at gmail.com
Thu May 13 16:02:00 UTC 2021

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.

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.

thx ..Tom (mobile)

On Thu, May 13, 2021, 8:55 AM David Waite via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210513/88c4bc9b/attachment.html>

More information about the Openid-specs-ab mailing list