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

Tom Jones thomasclinganjones at gmail.com
Mon May 17 16:18:21 UTC 2021

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
I will target that more specifically.

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.

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.

Be the change you want to see in the world ..tom

On Mon, May 17, 2021 at 1:29 AM David Chadwick <
d.w.chadwick at verifiablecredentials.info> wrote:

> I am happy with 0-3 but zero trust is questionnable.
> On 16/05/2021 17:50, Tom Jones wrote:
> 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.
> 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.
> 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.
> 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.
> 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.
> Zero trust - means that every session, (and possibly every interaction)
> re-evaluates the trust measures for the subject and the
> resource requirements.
> 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?
> Also note that certification is a necessary condition for trust, but not
> sufficient.
> 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.
> Kind regards
> David
> 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.
> Be the change you want to see in the world ..tom
> On Sun, May 16, 2021 at 7:36 AM David Chadwick via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>> 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.
>> 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.)
>> Kind regards
>> David
>> On 13/05/2021 16:55, David Waite via Openid-specs-ab 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 listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>> _______________________________________________
>> 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/20210517/b989c91c/attachment.html>

More information about the Openid-specs-ab mailing list