REWERSE WG I2 - Policies & Trust

Demo of the explanation facility

Introduction

PROTUNE-X - the explanation facility of PROTUNE - is meant to describe and explain PROTUNE policies and the decisions taken during negotiations. It handles three different kinds of queries: how-to, why/why-not and what-if queries. Such questions may be asked before, during, and after a negotiation to understand which pieces of information are actually used (sometimes information is unnecessarily released in negotiations), what still needs to be done to obtain the desired service, as well as to inspect and monitor access control and credential release policies.

How-to: How-to queries are designed to help users who do not know how to interact with a service or do not know which requirements they have to fullfil in order to be granted access to it.
Why/why-not: Once a negotiation took place and a decision has been communicated to the requester (either "granted" or "denied") a user may use the why/why-not facility to get an explanation of why its request was granted/denied.
What-if: In some cases a user would like to ask whether in a hypothetical situation he would get access to a service. For example, a user would like to know if in case he subscribed to an online shop he would get a discount on a book he plans to buy.

PROTUNE-X has second generation features such as

irrelevant information removal
attribute-based denotations of semi-structured objects

plus novel features such as proper failure explanations, covering also infinitely failed derivations.

The theoretical framework underlying PROTUNE-X is described in report I2-D4 and in the ECAI 2006 paper.

The demo consists of a set of web pages generated automatically by PROTUNE-X. The explanation hypertext can be generated on the clients to reduce the computational load on the server.

The digital library scenario

John Smith is a researcher at Open University and is currently working in a hot area. He is searching the internet for related work and finds a nice paper he would like to read. This paper is hosted at the website of a digital library under the file name "paper01234.pdf". However, not all the content of this digital library is accessible for free.

How-to explanation demo

Since John Smith has never used the library service before, he does not know how to access the paper he is interested in. However, he has the possibility of asking the digital library about the policy applied to the action of downloading. Once the digital library has sent back the requested policy, the John Smith's personal assistant generates an how-to explanation of this policy.

The how-to explanation facility can run two possible examples. The first example is the digital library policy. The second one is the policy which John Smith may adopt to regulate the releasing of credentials. Select one of the two choices in the select box and press the try button.

Description:

Example 1: The document downloading policy.

Three basic rules regulate document downloading:

Public resources can be freely downloaded (rule 2).
A subscribed user can download all the publications covered by her subscriptions (rule 3).
Every publication can be downloaded by paying with a credit card or a fastpay card (rule 4).

Additionally, in rule 3 and 4 the user should be authenticated to retrieve her active subscriptions. Following the [details] link in rule 3 the how-to facility explain you how to be authenticated. You have three choices: to provide an id credential with a legal public key, to fill a login form or to register to the library. Again you can follow a [details] link to see what precisely it is meant with id credential.

Example 2: The credential releasing policy.

Briefly, a credential is released if one of the following conditions is satisfied:

The credential to be released is a payment card. A trade-off between the type of the card (fast pay or credit card), the importance of the transaction and the reputation of the requester makes the risk to provide that credential acceptable.
The credential to be released is an id and the requester is an european company which handles its customers' personal details in compliance with the European Union directives.
The credential is an id and the requester is a US company which treats personal data according with the Safe Harbor framework.

As before follow the [details] link whenever you desire further information. For example, follow the [details] in rule 2, 7 and 9 and find out when the reputation of the requester is considered very good.

Why-not explanation demo

John wants do download the file "paper_0123.pdf" using his subscription for computer-related publications. Therefore, he submits his ID and expects to be authenticated. However, the digital library system rejects his request, so John opens the why-not explanation page and finds out what went wrong.

Choose one of the seven different examples of authentication failure and press the try button to start the why-not facility.

Description:

Example 1: Issuer unknown.

John's ID is issued by the Open University. Unfortunately, the server does not know the public key of the Open university, i.e. this CA is not known by the server. This can be found by following the [details] links associated to rules 3, 6, and 9, and reading the explanation associated to rule 18.

While explaning rule 3, the condition that paper_0123.pdf should be covered by some of the user's subscriptions has been automatically pruned, because trust negotiation failed for other reasons. The explanations of why rules 6, 9, and 18 failed have been pruned in a similar way. To see this, compare these explanations with those of rule 6 in Example 3, rule 9 in Example 4, and rule 18 in Example 2.

In the explanation of rule 18, note how the available attributes of a compound object (internally denoted by the "unfriendly" handler c012) are exploited to give a high-level and user-friendly description of the object.

Example 2: The ID's signature verification fails.

This time we assume that the issuer is one of the CAs known by the server. Signature verification failure may happen - say - because of data corruption or tampering. Follow the [details] links associated to rules 3, 6, and 9. You may ignore the first three steps, which are identical to those in Example 1. Note that the explanation of rule 18 includes aspects that had been pruned in Example 1 because they were irrelevant in that context.

Example 3: Missing credential fields.

We assume that John's ID is recognized as a valid ID credential. The latest version of the X.509 standard supports domain-dependent fields. In open environments it may happen that a supplied credential is missing one of such fields. In this example, a field called public_key is missing. Follow the [details] link associated to rule 2 and see the explanation associated to rule 6. Note that it includes aspects that had been pruned in Example 1 because they were irrelevant in that context.

Example 4:CA known, but not trusted for IDs.

Trust is relative to a task to be accomplished. In this example, the Open University is known by the server, but the IDs signed by the Open University are not accepted. Follow the [details] link associated to rules 3 and 6 and see the explanation associated to rule 9. Note that it includes aspects that had been pruned in Example 1 because they were irrelevant in that context.

Note: the word "obviously" in rule 9 results from a generic verbalization strategy for reflexive relations.

Example 5: Paper not covered by subscription.

Next, we assume that John was successfully authenticated. Unfortunately, paper_0123.pdf is not covered by John's subscription.

This time there is no "deterministic" way of explaining failure: John has two subscriptions, and paper_0123.pdf is covered by two subscriptions; however these subscriptions are all different, so each of the four choices eventually leads to a failure. See how this is reported in the explanation associated to rule 3.

If you want to see what happens for a particular subscription, click on the corresponding link. In this way one may focus on the scenarios that do not match one's expectations. For example, if John intended to use his basic subscription to computer-related publications, then he might click on [Subscription = basic computer pubs] and find a "deterministic" explanation of why that approach failed. This kind of explanation refinement can be very useful in more complex examples.

Example 6: Wrong password.

The server supports also a traditional authentication mechanism, based on login name and password pairs. PROTUNE supports this mechanism via unsigned declarations (a kind of web forms). In this example, John uses this method and types in a wrong password. Follow the [details] link of rule 3 and see the explanation of rule 7. Note that the details about the declaration's fields and password checking were pruned in the previous examples, where no declarations had been submitted by John.

Example 7: Infinite failed derivation.

Policies are logical axioms, not logic programs. There may be loops, that should be regarded as equivalences rather than program errors.

Of course, such equivalences may induce infinite failed derivations. In this example, John has two aliases: jsmith and J. Smith and two rules:

jsmith is authenticated if J. Smith is, and
J. Smith is authenticated if jsmith is.

Consequently, there is an infinite failed attemtp at proving that John is authenticated, cycling through the above two rules forever. The above kind of rules may easily arise when heterogeneous policies are integrated.

In the presence of inifitely failed derivations, PROTUNE-X produces a finite, cyclic hypertext. If you first follow the [details] links associated to rule 5, then the links associated to rule 1 and 2, the system informs you that you are in a loop by labeling the next link deja vu!

Why explanation demo

John meets the requirements of the digital library and has access to the file "paper_0123.pdf". However, still he is interested in receiving information about the process that led to the desired result.

Choose one of the two examples where John was granted the downloading of the paper and press the try button to start the why facility.

Description:

Example 1: Valid authentication.

The issuer of the John is authenticated, and he has a subscription of type computer(full) which enables to download the paper. Thus, rule 3 succeeds.

In rule 3 follow the [details] link to see why John has been authenticated. You find out that John has provided an id credential c012 with a legal public key. From the first [details] link of rule 6 you can see that rule 9 has been satisfied:

c012 is a valid credential of type id whose issuer is the UK Governament.
due to its type, c012 is considered a legal identification document.
the UK Governament is trusted for credentials of type id.

If you are still suspicious, you can ask the system why c012 is judged valid. Then, protune-x answers that the public key of the UK Governament has been successfuly satisfied.

Going back to rule 3 the explanation shows all the subscriptions owned by John as well as all those subscriptions which cover the file "paper_0123.pdf". Thus, we find that John has also a subscription of type law(basic) and the file "paper_0123.pdf" could be dowloaded also with a subscription of type gold. You can choose these possibilities and see what goes wrong. In particular the subscription law(basic) does not cover "paper_0123.pdf" and the subscription gold is not owned by John.

Example 2: Two aliases.

This example is similar to the previous one with the difference that, as in the why-not example 7, John has two aliases jsmith and J. Smith which are both authenticated. However, the refinement link [jsmith] in rule 5 shows that no subscription is associated with this alias. Furthermore, seeing why this alias is authenticated, you will find it is because of the authentication of the other one (rule 2). Note that if you refine the rule 5 with J.Smith and follow the [details] link the system reports a first explanation which is the same as in the previous example, and second one saying that it is authenticated beacuse jsmith is authenticated. This seems to be a vicious circle, but it is just what the library policy establishes us in rule 1 and 2: being jsmith and J.Smith two aliases of the same person the authentication of one of them entails the authentication of the other one. However, protune-x reveals the presence of such a circle by using a [deja-vu] link.

What-if explanation demo

To avoid useless disclosing of credentials, John may use the what-if facility to ask whether some credentials meet the requirements of the digital library. In this case, the evaluation of the query at the digital library receives a hypothetical credential and produces a hypothetical answer. That means that even if the answer returns that access would be granted, it is still not 100% guaranteed to succeed in a real negotiation, because the simulation is based on several assumptions (e.g., the digital library assumes that the challenge for the credential will succeed during a real negotiation).

Select the digital library example and press the try button to start the what-if facility. An interactive web page will appear where you may edit a goal and hypothetical credentials. You may also use predefined queries to get familiar with the what-if facility.