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

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 | +-----------------------+

Actions/Transformations +-----------------------+ | X Y Z | +-----------------------+ | TRUE 12 - | +-----------------------+

CombiningPermissionsAlgorithm

Firing rules

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

Conditions Actions/TransformsId WR-ID D-Flag Civil-Location1 ted FALSE city2 * TRUE country

D-Flag Civil-LocationTRUE cityFigure 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

Conditions Actions/TransformsId LR-ID DD-Flag Civil-Location1 ted TRUE city2 * FALSE country

DD-Flag Civil-LocationTRUE city

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!

Questions?