190 likes | 306 Views
< 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:
E N D
<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: http://www.tschofenig.com/drafts/draft-ietf-geopriv-common-policy-01-from-0.diff.html
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>
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>
Actions • The <confirmation> action was moved to the presence specific authorization document. • The common-policy document does not define any actions.
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).
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 - | +-----------------------+
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)
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
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.
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
Example II Figure 1: Authorization Policy Figure 2: Result of a query by LR "Ted" for target "Allison"
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 ..."
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)
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>
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)?
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?
Next Steps • Update Common-Policy document based on decisions made in this meeting • Please send review comments!