Skip to main content

Considerations Encountered in Design of Trust Policy Engine

The Trust Policy Engine's job is to take all the of the information (in the form of verifiable credentials) which has been claimed to us (for which the issuers have been verified at a previous step) and determine which information is trusted, at the present time, to be instantiated into the current worldview of believed facts.

In order to do this we need:

  • To be able to define a policy describing which agents are allowed to make which types of claim. This is analogous to a XACML policy engine. e.g. only users with appropriate permissions may trust a manufacturer.
  • For the policy to be updatable / alterable by many different users, the implemented policy of the policy engine should be collaborativly written by many different users. The policy engine must therefore be able to determine which users are able to define new policy rules, and then update it's policy to include those rules, and must be able to handle conflicting rules in some way, as users may enter rules which conflict.
  • To be able to define a trust level associated with the agents which occur in the provenance of the information, e.g. If Tom stated a fact, which was used to infer another fact by Bot123, and that fact was used to infer another fact by Bill. We need to be able to give a trust level to all these agents, and if one of the agents becomes untrusted for some reason, e.g. we discover thier private key was leaked or email address compromised, remove from the system both the facts they directly claimed and the inferences based on those facts (which have those facts in thier provenance tree).
  • We may also want the inferences generated from query submitted to the system to have a trust level and / or confidence level associated with them. Alternatively we could use the trust level in the policy as an attribute to decide if facts may enter the system, for example we only allow agents with high trust to add one kind of fact, but agents with low trust may enter another kind of fact.
  • It must be able to respond in real-time to "Binary" changes in trust, e.g. if a user is transitions to not being trusted, thier VCs should be removed from the trusted VCs immeditaly, this should chain so that if another user received trust from that original user their trust (and therefore their claims) should be revoked, and so on down the trust chain.

Concise Summary of Policy Engine Functionality​

Concisely, using the policy engine you should be able to:

  • Implement a policy for which agents may performs actions (read, write, revoke) on which resources
  • Allow the policy to be updated with new rules by users, and dis-allow or resolve rule conflicts
  • Allow agents to have a trust level associated with them
    • These need to be instantiated differently in different contexts, in a networking context in CAHN new users should have trust imparted by an already trusted agent, in MAXAD for vessels, we may want to automatically instantiate them with a low level of trust, maybe after some initial checks to detect suspiciousness, as all vessels shouldn't be expected to be trusted by a human user.
  • Have knowledge of the provenance tree of a fact, all facts or agents which were involved in the provenance of that claim and decide if a claim should be instantiated into the worldview as a fact based on the agents which took part in the provenance of that claim

Problem: Conflict Resolution​

  • What about conflict resolution? If 2 rules conflict, what do we do? XACML uses rule combining algorithms to handle combining multiple rules (which may conflict):
    • Deny overrides - deny has priority over permit
    • Permit overrides - permit has priority over deny
    • First applicable - Evaluate each rule in the order in which is listed in the policy. The algorithm runs through all the rules until in one the target matches and the condition to be evaluated is true. If no further rule in the order exists, then the policy shall evaluate to "NotApplicable".
    • Only one applicable - If only 1 policy is applicable, the result of that policy will be used, otherwise (if no or multiple policies are applicable) result denied
    • Ordered deny overrides - same as Deny overrides, but evaluates policies in order listed in policy set
    • Ordered permit overrides - same as Permit overrides, but evaluates policies in order listed in policy set

This also needs to be considered in the general claim reasoning system, how to resolve conflicting claims? Handle result of conflicting inference results using these same algorithms?

This paper discusses a more sophisticated expert system which defines a XACML-like policy implementation in Prolog, and does a more clever conflict discovery method for static conflicts in rules (these 2 rules as written conflict, e.g. my XAMCL policy has a value of the inputs which both results in permit and deny). However, we could just use the same resolution algorithms XACML uses, paper just says "Such algorithms are primitive and potentially a risk for corporate computer security. While they can be useful for resolving dynamic conflicts, they are not justified for conflicts that can be easily detected statically.", which is not a particularly strong argument against using the same methods as XACML uses.

Solution? Use XACML's rule combining algorithms.​

Problem: Variable Trust in Entities​

How do we represent variable trust in entities which claim information? We want to represent the fact that some sources of information are less trustworthy than others. We talked about representing this as a decimal number between 0 and 1. Prolog cannot handle variable trust in facts, neither can any other inferencing system, this is an active research area: see this litarture review.

The reason we want to do this is to determine our trust / confidence in our inferences produced by the system, e.g. if a user asks the system a question like: "What suspicious vessels are in the 30km area around my vessel?" we want to provide the user an answer with the trust level in the answer, based on the trust used to construct the answer, so if we used some data which we have a low trust in to generate this insight, that is represented in the result.

Solution? Discrete trust levels and mutliple world views at those trust levels​

We discretise our trust into discrete levels, for example 3 discrete levels: low, medium, high. The policy engine has a discrete trust level in all of the sources of data, which is entered by sufficiently permissioned users or is generated by a sufficiently permissioned automated process through some algorithm, or preconfigured initial trust levels for different entity classes (e.g. all ships are initialised with low trust).

Problem: Capturing & Representing Provenance of Claims & Facts​

Where agents are directly adding information to the system (users through a UI, or scripts processing data) the information is signed in a VC by the agent's private key and can be directly attributed to the VC issuer as the data originator. If we transmit a VC claim between different routers running the claim system, we can sign the VC inside another VC in a nested structure to cryptographically attest to the provenance of that VC claim. However for databots (automated agents ingesting dat from the claim system and producing analytics) which generate analytics based on querying the claim system through a prolog query they do not have knowledge of the provenance of the information that has been used to generate the results of thier query.

In the MAXAD use case, AIS data is broadcast (originated) from vessels from thier radios, collected by a radio receiver and added to the AIS data hosting system (for example the SAMPSON radar system owned by SAMPSON radar system, and maintained by RN personnel), we then ingest data from the system via a script, at this point in the data chain we can sign the information in a VC which is claimed to the Claim Cascade system with the private key of the agent which is running the script to ingest the data, however we need a way to represent the various agents in the chain and represent our trust in those agents (the particular vessel & the SAMPSON radar system & data importing process) in such a way that if we no longer trust any of the links in the chain we can distrust the facts those agents had a hand in adding to the system.

For both the databot producing analytics facts from other facts and the importer claiming facts which have been got from another source through a pipeline they need to append a provenance to the information they are claiming. We need some way for a VC claim to include it's provenance chain in such a way that the agents are uniquely identifiable and may be known to the system.

Solution??? Provenance field on all VC claims?​

Eg.

type: fact
id: 64102c1f-b9e7-45a9-bcc6-94bc47c18ee4
timestamp: 1716378452343
schemaName: user
fact: 
  id: 3839a2c6-7d0b-4aea-82b5-f55b1609b822
  username: ash
  created_at: 1716378452343
  can_issue_purchase_rights: false
  can_issue_connection_rights: true
  can_issue_trust: true

now becomes:

type: fact
id: 64102c1f-b9e7-45a9-bcc6-94bc47c18ee4
timestamp: 1716378452343
schemaName: user
provenance:
  source: Importer
  timestamp: 2024-07-30
  provenance:
    source: SAMPSON radar system
    timestamp: 2024-07-29
    provenance:
      source: MMSI number 235 762000.
      timestamp: 2024-07-28
fact: 
  id: 3839a2c6-7d0b-4aea-82b5-f55b1609b822
  username: ash
  created_at: 1716378452343
  can_issue_purchase_rights: false
  can_issue_connection_rights: true
  can_issue_trust: true

Problem: Provenance of Query Results​

If we make a query of the prolog world-view generated from the currently trusted VCs, how do we know what facts were used to generate this query result? How do we know the provenance of the infered query result? I.e. which agent's facts contributed to the query result. If we enter this query result into the system as a claim in-and-of-itself then it should have a provenance assocaited with it, so that we know to retract that fact if one of the fact it relied on in coming to it's results is revoked. Alternatively we could generate these analytical artifacts at query-time, and they are only considered to be valid a query time, they are thrown away afterwords (or cached for some period of time, with the cache being invalided entirely when any claim is retracted).

If we can extract all of the facts we used to make the infered query result then we could check that those facts are still present, or we may be able to reconcile this against the VCs used to build the prolog code, or we could store the fact provenance IN the prolog environment.