Changes between Version 7 and Version 8 of TIEDABACDemo

Timestamp:

07/10/09 16:38:03 (15 years ago)

Author:

faber@isi.edu

Comment:

--

TIEDABACDemo

@@ -58 +58 @@
 
 In the examples above, creating the paths from principal to attribute that constitute a proof are all done assuming total information in the hands of the prover.  ABAC does not require a prover to hold all such information initally and provides a negotiation protocol to gather it.  We sketch that protocol here.
+
+Getting access from an ABAC controller consists of constructing a proof that the requesting principal has a given attribute.  The two endpoints provide parts of the graph to one another until they have constructed a graph using the rules above that contains such a path.  Because edges define node-edge-node sequences in graphs, the building of graphs is an exchange of credentials.
+
+As a simple case, consider creating a graph for the linked role example above.  Initially TED has two credentials one signed by ISI indicating that TED has the ISI.GENI attribute and one signed by NSF indicating that ISI has the NSF.funded attribute.  The GPO has a single credential signed by itself stating that principals who have the NSF.funded attribute are delegated the power to assign the GPO.demo attribute by assigning their local GENI attribute.
+
+Ted asks for a resource from the GPO.  The GPO's ABAC controller responds telling Ted that it is trying to prove that Ted has the GPO.demo attribute, and giving the relevant credential.  Ted checks the credential and finds that it forms the following graph:
+
+[[Image(Proto1.png)]]
+
+Ted now assesses its credentials and sees what edges it can add to the graph.  In this specific case, its two credentials create an implied link that completes a path to Ted.  Ted responds by sending those credentials to the GPO which checks the signatures and agrees that the valid graph allows access.
+
+[[Image(Proto2.png)]]