|
|
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 [detail] 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. [Start this demo]
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 [detail] 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. [Start this demo]
Next 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 [detail] 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. [Start this demo]
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 [detail] 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. [Start this demo]
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. [Start this demo]
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. [Start this demo]
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:
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! [Start this demo] |
Coordinator unit: Sezione di Informatica - Dip. Di Scienze Fisiche - Universita' di Napoli Federico II