1 / 19

A Document Format for Expressing Privacy Preferences

< draft-ietf-geopriv-common-policy-01.txt> H. Schulzrinne, J. Morris, H. Tschofenig, J. Cuellar, J. Polk, J. Rosenberg. A Document Format for Expressing Privacy Preferences. Status Update. A number of editorial issues fixed with the document:

Download Presentation

A Document Format for Expressing Privacy Preferences

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. <draft-ietf-geopriv-common-policy-01.txt> H. Schulzrinne, J. Morris, H. Tschofenig, J. Cuellar, J. Polk, J. Rosenberg A Document Format for Expressing Privacy Preferences

  2. Status Update • A number of editorial issues fixed with the document: http://www.tschofenig.com/drafts/draft-ietf-geopriv-common-policy-01-from-0.diff.html

  3. Multiple <id> elements in the <identity> element • It is allowed to list more than one identity within a single rule. • Based on mailing list discussions • Example: <identity> <id>alice@example.com</id> <id>bob@example.com</id> </identity>

  4. Except handling • No domain part in the <except> element. • Changed from: <identity> <domain>example.com</domain> <except>joe@example.com</except> <except>tony@example.com</except> <except>mike@example.com</except> </identity> • To: <identity> <domain>example.com</domain> <except>joe</except> <except>joe</except> <except>tony</except> <except>mike</except> </identity>

  5. Actions • The <confirmation> action was moved to the presence specific authorization document. • The common-policy document does not define any actions.

  6. Combining Permissions How it works today! (1/2) • Allison provided a few policy rules for access to her location information: Conditions Actions/Transformations +--------------------------------+---------------------+ | Id WR-ID sphere from to | X Y Z | +--------------------------------+---------------------+ | 1 bob home A1 A2 | TRUE 10 o | | 2 alice work A1 A2 | FALSE 5 + | | 3 bob work A1 A2 | TRUE 3 - | | 4 tom work A1 A2 | TRUE 5 + | | 5 bob work A1 A3 | undef 12 o | | 6 bob work B1 B2 | FALSE 10 - | +--------------------------------+---------------------+ • Bob asks for location information (between A1 and A2).

  7. Combining Permissions How it works today! (2/2) Conditions Actions/Transformations +--------------------------------+---------------------+ | Id WR-ID sphere from to | X Y Z | +--------------------------------+---------------------+ | 1 bob home A1 A2 | TRUE 10 o | | 2 alice work A1 A2 | FALSE 5 + | | 3 bob work A1 A2 | TRUE 3 - | | 4 tom work A1 A2 | TRUE 5 + | | 5 bob work A1 A3 | undef 12 o | | 6 bob work B1 B2 | FALSE 10 - | +--------------------------------+---------------------+ Actions/Transformations +-----------------------+ | X Y Z | +-----------------------+ | TRUE 3 - | | undef 12 o | +-----------------------+ Firing rules Combining Permissions Algorithm Actions/Transformations +-----------------------+ | X Y Z | +-----------------------+ | TRUE 12 - | +-----------------------+

  8. Combining Rules (CR) • CRs as defined in common-policy-01: • data types of permissions to be combined = Boolean or Undef: • if there is one value = true: CV = true • otherwise: CV = false • data types of permissions to be combined = Integer or Undef: • if all permission values = undef: CV not specified (bad!) • otherwise: CV = max {single values} • data types of permissions to be combined = Set or Undef: • CV = intersection of all single values not equal undef (CR = Combining Rule, CV = Combined Value)

  9. Combining Permissions EnhancementMotivation • Rule maker writes authorization policies. He needs to be aware of a few things to understand what he outcome of the rules are: • the combining permissions algorithms and • other authorization rules (such as default rule) • Output might not be desired or expected. • Legend • D-Flag: Distribute Flag • FALSE: Further distribution of the LO is not allowed • TRUE: Further distribution of the LO is permitted

  10. Example Figure 1: Authorization Policy Figure 2: Result of a query by WR "Ted" for target "Allison" The result allows "Ted" to distribute fine grained location information.

  11. First Solution Approach • It is possible to change the semantics of the D-Flag to something which is more "privacy-preserving". Distribution is disallowed if a single rule fires where the DD-Flag is set to TRUE (i.e., where further distribution is not allowed). • Legend • DD-Flag: Don't Distribute Flag • FALSE: Further distribution of the LO is allowed • TRUE: Further distribution of the LO is disallowed

  12. Example II Figure 1: Authorization Policy Figure 2: Result of a query by LR "Ted" for target "Allison"

  13. First Solution ApproachEvaluation • Result: Rules are harder to read but lead to a result which might be more intuitive. • strange permissions: • <do-not-provide-timezone>false</do-not-provide-timezone> • Passage from the next version of the Geopriv-Policy document: "Latitude resolution permission values are of type Integer. These values MUST be negative, in order to comply with the Integer CR of the common policy spec, see [..]. The resolution is the number of bits as given by the absolute value of the negative integer value of latitude resolution transformation element ..."

  14. Proposal • Six CRs: • Boolean-True: if there is a single value = true, then CV = true • Boolean-False: if there is a single value = false, then CV = false • Integer-Maximum: CV = maximum of single permission values • Integer-Minimum: CV = minimum of single permission values • Set-Intersection: CV = intersection of single permission values • Set-Union: CV = union of single permission values • Each permission definition MUST specify the CR that should be used in order to protect privacy. (CR = Combining Rule, CV = Combined Value)

  15. ProposalXML Schema Enhancement • Example: <xs:element name="latitude-resolution" type="xs:integer" substitutionGroup="cp:transformation"/> <xs:annotation> <xs:appinfo> Integer-Minimum </xs:appinfo> </xs:annotation> </xs:element>

  16. Non-Identity based Authorization • Goal: • Allow authorization decisions based on some knowledge (token, passcode) rather than only on the authenticated identity. • Issue also described in the Geopriv requirements document • Different approaches: • XCON approach • Authorization policies with tokens/passcodes • Name of the resource itself serves this purpose • Are some actions necessary in Geopriv (with respect with the requirements)?

  17. Identities • The content of the <id> element is assumed to be the authenticated identity of the user. • A using protocol describes which entities from the using protocol are matched with the • If the <identity> element is omitted then it means: • Match for authenticated as well as unauthenticated WRs • XCON raised the issue of having support for: • <any> • Any authenticated user • <unauthenticated> • Non-authenticated user - but still an identity matching is done • Is this something useful for us?

  18. Next Steps • Update Common-Policy document based on decisions made in this meeting • Please send review comments!

  19. Questions?

More Related