Enabling Access to Web Resources through SecPODE-based Annotations

Editor's Notes

• #2 Credential validation transforming external attributes into things that can be internally understood.
• #4 Figure 1 shows how a service requester tries to access a resource from a service provider via a Web browser. The browser sends the request to the service provider and checks whether the information received from the service requester are sufficient to gain access to the resource. Note that we assume that both services commit to SecPODE as a upper ontology even though they may commit to different domain ontologies.
• #7 DOGMA (Developing Ontology-Grounded Methods and Applications) is a formal ontology engineering framework that is not restricted to a particular representation language. The main difference to existing ontology engineering approaches (e.g. METHONTOLOGY) is the separation between the lexical representation of concepts and their semantic constraints. This separation makes reuse of plausible facts easier since agreement on domain rules is much harder to reach than an agreement on the conceptualization. Consequently, a DOGMA inspired ontology decomposes the ontology into a lexon base and a layer of reified ontological commitments. The lexon base layer stores plausible binary fact-types, called lexons. A lexon is a natural language statement representing the relation between two concepts. Intuitively, a lexon may be read as: within the context γ, head may have a relation with tail in which it plays a role, and conversely, in which tail plays a corresponding co-role. For example, the lexon <Research, Author, writes, written by, Book> can be read as: in the context Research, Author plays the role of writes Book and Book plays the role of being written by Author. The goal of the Lexon Base is to reach a common and agreed understanding about the ontology terminology and is thus aimed at human understanding. The Commitment Layer mediates between the lexon base and its application. It consists of a finite set of axioms that specify which lexons of the Lexon Base are interpreted and how they are visible in the committing application, and (domain) rules that semantically constrain this interpretation. For example, it allows the application owner to define the properties (e.g. transitivity) of subsumption (i.e. is-a/subsumes) within his/her application. Moreover, commitments provide mappings between the lexon base layer and the data layer (in databases).
• #8 Declarative represent the core concepts rather than the rules needed to apply them (e.g. Datalog, Jess, Lisp, Prolog, etc.).
• #9 A security policy defines a set of conditions, which are evaluated to determine a set of actions may be performed on a target. For example, an access control policy could state that only placement advisors (i.e. the condition) have the right to consult (i.e. the action) the CV of a student (i.e. the target). The effect of a security policy provides a statement committing the system to enact the action articulated in the policy. For example, the effect of an access control policy would be to grant or deny access to a target. In distributed systems, every security policy is given an identifier (e.g. URN) to uniquely refer to it within an information system as well as a natural language description of what the policy actually does. A security policy is written by an agent (e.g. system admin) and is recorded to provide provenance.
• #15 Semantic Interoperability between a Service Provider (SP) and a Service Requester (SR). SP and SR may use: Same vocabulary for attributes, but different vocabulary for their values Different vocabularies for attributes and their values The browser sends the request to the service provider and checks whether the information received from the service requester are sufficient to gain access to the resource. Note that we assume that both services commit to SecPODE as a upper ontology even though they may commit to different domain ontologies.