Wirtschaftsuniversität Wien Magisterarbeit - SemanticLab

More documents

Recommendations

Info

Element Value ruling allow user category sales department action store data category customer-record purpose order-processing condition the customer is older than 13 years of age obligation delete the data 3 years from now Table 3.4.: An example EPAL privacy rule (Source: [IBM03]) Element Value user category sales department action store data category customer-record purpose order-processing Table 3.5.: An example EPAL request (Source: [IBM03]) would be translated into the formal EPAL privacy rule as shown in Table 3.4. Such rules are used to determine whether a request is allowed or not. Not surprisingly, a request contains a user category, an action, a data category, and a purpose. Assume the following informal request: A person acting as a sales agent and an employee requests to collect a customer’s email for order entry. (Source: [IBM03]) This informal request would be translated into the formal EPAL request as shown in Table 3.5, based on the elements predefined by EPAL and used by the above created privacy rule. This request matches the rule defined above and therefore it would be allowed. As EPAL was especially designed for enterprises, it offers vocabularies that enables businesses to express sector-specific privacy policies. Although usually one enterprise will create a policy, the aim is also that companies agree on a set of vocabularies, exchange these policies and hence use them in their business transactions. The following section is going to highlight these EPAL vocabularies. 3.2.4. EPAL vocabularies By using the epal-vocabulary element, industry-specific vocabularies can be defined using the following subelements: 34 • vocabulary-information: This element provides information about the vocabulary - the name (id), the issuer of the vocabulary (issuer) and the version (version-info).
• user-category: This element represent categories of users (such as a single employee, particular roles, departments etc.). User-categories are defined and then used in a rule to describe who is going to access the data. • data-category: This element classifies data in different categories - medical records for example would be in another category than an e-mail address of a customer. Similar to user-category, this element is referenced in rules. • purpose: This elements defines the purpose for what the data is used. However, this purpose may be high-level (e.g. marketing), therefore it is needed to build hierarchies to represent different kinds of purpose (e.g. telemarketing vs. thirdparty e-mail marketing). • action: The ultimate goal for collecting data is to process it somehow. This element describes the actions that are going to be applied to the collected data. A privacy policy will then define which actions are allowed or denied under specific circumstances. • container: This element contains context data in a structured form (e.g. attribute age) so that these attributes can be evaluated by conditions (e.g. if age is over 13 then...). • obligation: Obligations are actions which have to be taken after performing an action on data, for example that some data must be deleted within 30 days. The detailed (XML-) structure of EPAL and its policies and rules is not very different from the concepts already introduced and will not be covered here. Interested readers should consult the EPAL specification available at [IBM03] for more in-depth information. 3.3. The eXtensible Access Control Markup Language (XACML) The eXtensible Access Control Markup Language (XACML) is a standard published by OASIS, the Organization for the Advancement of Structured Information Standards and defines an access control language based on XML [OAS05]. “The motivation behind XACML is to express the well-established ideas in the field of access-control policies (e.g., rules, policies, policy sets, subjects, decision requests, authorization decisions) using an extension language of XML” [Cov08a]. The XACML specification states that it was developed because “there is a pressing need for a common language for expressing security policy [sic]. If implemented throughout an enterprise, a common policy language allows the enterprise to manage the enforcement of all the elements of its security policy in all the components of its information systems” [OAS05]. If not stated otherwise, the following introduction is based on the XACML 2.0 specification available at [OAS05]. 35
Page 1: Wirtschaftsuniversität Wien Magist
Page 4 and 5: Contents Abbreviations vii Listings
Page 6 and 7: II. Applied part 53 6. Development
Page 8 and 9: Listings viii 3.1. HTTP response he
Page 10 and 11: List of Tables x 3.1. PURPOSE sub-e
Page 12 and 13: 1. Introduction This thesis address
Page 14 and 15: In addition, the applied part of th
Page 16 and 17: 2. Privacy Threats Privacy is the
Page 18 and 19: term friendly fraud relates to legi
Page 20 and 21: over iGoogle, search Wikipedia via
Page 22 and 23: collect a lot of personal data abou
Page 24 and 25: 2.4. Privacy sensitive technologies
Page 26 and 27: • Data necessary to identify the
Page 28 and 29: 3. Privacy Standards The following
Page 30 and 31: The well-known location method (whi
Page 32 and 33: • User Preferences: User-agents m
Page 34 and 35: Another important issue for policy
Page 36 and 37: 1 M i c r o s o f t Way< /DATA> Red
Page 38 and 39: 28 PURPOSE Plain Language Translati
Page 40 and 41: Finally, an example should be provi
Page 42 and 43: • There is a commercial P3P polic
Page 46 and 47: 3.3.1. XACML - an introduction Simi
Page 48 and 49: 3.3.3. Summary The introduced priva
Page 50 and 51: specified conditions” [ISO01a]. T
Page 52 and 53: applied to this characteristic too,
Page 54 and 55: Figure 5.1.: Microsoft Internet Exp
Page 56 and 57: 5.1.2. Firefox The Mozilla Foundati
Page 58 and 59: shortcuts and context-menu, users s
Page 60 and 61: 5.3. Proxies In this section, proxi
Page 62 and 63: 52 Figure 5.10.: The settings dialo
Page 64 and 65: 6. Development of a Privacy Plug-In
Page 66 and 67: • components directory: this dire
Page 68 and 69: Speaking of information it has to b
Page 70 and 71: Figure 6.2.: Displaying the P3P pol
Page 72 and 73: matches the users preferences befor
Page 74 and 75: Figure 6.4.: The privacy policy of
Page 76 and 77: is different from the one available
Page 78 and 79: access elements in a policy which i
Page 80 and 81: implementation available although t
Page 82 and 83: [Dro06] Dennis Drotar, Rachel Green
Page 84 and 85: [Kob07] Alfred Kobsa. Privacy-enhan
Page 86 and 87: [Oli04] Nadia Olivero and Peter Lun
Page 88 and 89: [Woo06] Jisuk Woo. The right not to
Page 90 and 91: M i c r o s o f t i s a premier spo
Page 92 and 93: 82
Page 94 and 95:
B. E-Mail correspondence Subject :
Page 96:
the Thank you , Renukesh M i c r o
show all

Wirtschaftsuniversität Wien Magisterarbeit - SemanticLab

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?