Re: Are we doing enough to align our work with Zero Trust Architecture?

Here's a bit of explanation around the slides I just shared:

Considering risk mitigation, based on SSI principles, there are four
separate actors:

   1.

   Resource Owner (RO) their user agent (mobile wallet), and cloud agent
   (AS)
   2.

   Service Provider (SP), by definition has data in the clear
   3.

   Requesting Party (RQ) and their user agent (mobile wallet)
   4.

   Requesting Client (RC), by definition has data in the clear

Note that the EDV does not show up on this list because they never have the
data in the clear or the ability to direct access to data in the clear.

Note also that there are no independent auditors role yet in the SSI model.

Consider compromised actors, based on SSI principles:

   1.

   Resource Owner (RO) compromise has minimal risk to the extent that one
   RO cannot compromise another RO in the rest of the system. That minimal
   risk applies also to the mobile wallet (rubber hose cryptography) and to
   the cloud agent (AS) of the RO if the AS is also self-sovereign to the RO.
   If the AS is a fiduciary to many RO’s then there needs to be a mechanism to
   audit AS behavior.
   2.

   Service Provider (SP) compromise is a huge risk. The risk is minimized
   by having as many substitutable SPs as practical for ROs to choose from and
   each SP serving as few ROs as possible. This decentralization of SPs is the
   main reason policy-driven semi-autonomous AS’s are useful since they can
   act without bothering the RO in cases where the risk is acceptable relative
   to RO policy. Even so, when SPs serve more than one RO an independent audit
   mechanism is needed.
   3.

   Requesting Party (RQ) compromise is guaranteed. The risk is minimized by
   holding individuals accountable for their actions and by having multiple
   individuals collude in a transparent way to act as a RQ. A notary is an
   example of RQ risk mitigation. The notary is somewhat independent as an
   auditor (somewhat because they are chosen by the RQ) and they are
   individually accountable (because they bring their own user agent and keep
   their own transaction logs). Other RQ compromise mitigations focus on their
   user agent to reduce the risk of rubber hose cryptography and to secure
   wallet recovery procedures.
   4.

   Requesting Client (RC) compromise is also guaranteed. The RC typically
   has access to many ROs’ data and acts an agent to many RQs. Some of these
   RQs will be compromised. RCs and RQs have different privacy and
   accountability expectations. RCs for example can be bonded whereas RQs can
   be jailed. To protect the RQs and SPs and hold them accountable for
   choosing to interact with the RC, SSI must provide some guidance on how to
   independently audit RCs.


The introduction of auditors for the various roles above, by definition,
adds friction to the system. This friction is essential to the success of
SSI and it is up to us to design this friction deliberately according to
SSI principles. EDVs are part of the solution. Standardized authorization
protocols like GNAP, are a key part of the solution because they enable
policy-driven semi-autonomous agents and because they can help hold RCs
separately accountable from the user agents of requesting parties and
requesting party delegates.


Adrian

On Sun, Jan 3, 2021 at 6:19 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> Thanks @Manu on multiple counts. You noticed that my question was to the
> broader group and you're willing to see my question as a standards issue.
> I, however, think our responsibility as the standards devs is much more
> than 30%.
>
> Looking at the ZTA imperative through the lens of Confidential Storage or
> EDVs is a missed opportunity. I'm a huge fan of standardizing EDVs, but
> EDVs actually obscure the ZTA protocol issues.
>
> Encryption at rest is a given. The issue is authentication, authorization,
> and audit.
>
> The most important message from the SolarWinds hack and much of the
> ransomware havoc is that our systems are not set up for individual
> accountability or independent audit.
>
> The VC and ZCAPs perspective is inadequate. As an SSI community we need to
> address the separation of concerns between authentication, authorization,
> and audit as equally important and needing a harmonized best-practice
> perspective. Standardized EDVs are table stakes but not terribly relevant
> to the protocols that link authentication, authorization, and audit.
> Confidential Storage should be adopting the protocols that connect
> authentication, authorization, and audit rather than introducing protocols
> narrowly scoped to the narrow and obvious role of encryption at rest.
>
> I've put together a few slides in an attempt to clarify the relationship
> between non-repudiable accountability and audits (and EDVs).
> https://docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_l2Ho64_ePKU/edit#slide=id.p
> I'd love to find a time to explain.
>
> Adrian
>
>
>
> On Sun, Jan 3, 2021 at 5:45 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> On 1/2/21 6:34 PM, Adrian Gropper wrote:
>> > Please read
>> >
>> https://www.nytimes.com/2021/01/02/us/politics/russian-hacking-government.html
>> >
>> >
>> > What would be a good way for our SSI communities to advance zero
>> > trust architecture through more effective accountability and audit?
>>
>> Hmm, I think Dmitri and Daniel thought you were addressing the DIF
>> Confidential Storage WG when you were, instead, addressing the DID WG?
>>
>> Let me start by pointing out that the SolarWinds attack was a supply
>> chain attack and it is highly unlikely that what I'm going to say below
>> would have prevented that. Sure, if everything was perfectly executed
>> then maybe... but we shouldn't be so naive to think that reality comes
>> close to good security practices (SolarWinds) or that breaches of
>> security lead to lasting bad outcomes for the negligent (Equifax).
>>
>> The core of the question is probably, could Zero Trust Architecture have
>> helped prevent the SolarWinds attack? The answer is probably no, because
>> it happened due to negligence around security rather than a failure of
>> good security practices.
>>
>> Could DIDs and VCs help with systems architected with Zero Trust in
>> mind? Yeah, probably:
>>
>> 1) You could use VCs to prove that you should have certain levels of
>>    access to certain systems. Checking this could happen automatically,
>>    but while ensuring that you're "live" and not some bot.
>>
>> 2) Logs could be kept of which VCs were used when to receive the
>>    authority to do something.
>>
>> 3) ZCAPs could be used to provide fine-grained access to very specific
>>    resources, even behind the firewall, within an organizations systems.
>>
>> DIDs could power much of this... but shouldn't promise any of it. The
>> closest we could probably get to what you're asking, Adrian, is to align
>> the Zero Trust Architecture principles to how DIDs and VCs can help --
>> primarily around: identity verification (VCs), login authentication
>> (DIDs), least-privilege access (ZCAPs, Confidential Storage), and HTTP
>> API access authorization (ZCAPs).
>>
>> You'll note that the above will only help you with about 30% of what
>> ZTEs are about... the rest will cost you and arm and a leg (consultants
>> or hiring qualified security people to implement real security
>> processes, audits, and procedures). Don't know if we can help much
>> there. That said, it wouldn't hurt to take a stab at how we might help
>> with the items above.
>>
>> -- manu
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: Veres One Decentralized Identifier Blockchain Launches
>> https://tinyurl.com/veres-one-launches
>>
>>