1. A Document Format for Expressing Privacy Preferences H. Schulzrinne, J. Morris, H. Tschofenig, J. Cuellar, J. Polk, J. Rosenberg

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 elements in the element It is allowed to list more than one identity within a single rule. Based on mailing list discussions Example: alice@example.com bob@example.com

4. Except handling No domain part in the element. Changed from: example.com joe@example.com tony@example.com mike@example.com To: example.com joe tony mike

5. Actions The 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 | +-----------------------+ Actions/Transformations +-----------------------+ | X Y Z | +-----------------------+ | TRUE 12 - | +-----------------------+ Combining Permissions Algorithm Firing rules

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 Enhancement Motivation 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 ConditionsActions/Transforms IdWR-IDD-FlagCivil-Location 1tedFALSEcity 2*TRUEcountry D-FlagCivil-Location TRUEcity 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 ConditionsActions/Transforms IdLR-IDDD-FlagCivil-Location 1tedTRUEcity 2*FALSEcountry DD-FlagCivil-Location TRUEcity Figure 2: Result of a query by LR "Ted" for target "Allison"

13. Combining Rules Evaluation Current CRs definitions are not always privacy-protecting: — Boolean CR not appropriate for transformation — Integer CR appropriate for enumeration, if full civil info = low integer value, country only = high integer value not appropriate for,, and transformations — Set CR combined value defined to be intersection of the single values would union be more appropriate? (to be privacy preserving)

14. First Solution Approach Evaluation Result: Rules are harder to read but lead to a result which might be more intuitive. strange permissions: — false 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..."

15. 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)

16. Proposal XML Schema Enhancement Example: <xs:element name="latitude-resolution" type="xs:integer" substitutionGroup="cp:transformation"/> Integer-Minimum

17. 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)?

18. Identities The content of the 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 element is omitted then it means: — Match for authenticated as well as unauthenticated WRs XCON raised the issue of having support for: — Any authenticated user — Non-authenticated user - but still an identity matching is done Is this something useful for us?

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

20. Questions?