Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Why geographic location specifications matter to identity (20070712)
As IM, Voice over IP (VoIP) and mobile telecommunications/data protocols converge, there is a desire to augment the real-time data tracked about a user with their geographic location, in order to support commercial location-based-services (your nearest Starbucks is 100 meters north) and location reporting to the emergency services for mobile users (mobile E911 in the US).
The IETF working group GEOPRIV (Geographic location/privacy) was chartered to
"...assess the authorization, integrity and privacy requirements that must be met in order to transfer [geographic location] information, or authorize the release or representation of such information through an agent."
and
"...select an already standardized format to recommend for use in representing location per se. A key task will be to enhance this format and protocol approaches using the enhanced format, to ensure that the security and privacy methods are available to diverse location-aware applications."
The results of this working group activity are of interest to identity protocol development, as
1. Maintaining knowledge of the location of an individual person (based on the location of one or more computing devices that person has been using) is one of the most difficult use case for traditional identity management systems, as the location data is sensitive, highly dynamic, sourced from multiple (potentially thousands) providers, and represented in several incompatible formats (e.g., location as lat+long vs. location as street address).
2. The working group requirements document (RFC 3693, February 2004) discusses, amongst other topics, the need for privacy rules that controlling the flow of individual's location information across organizational boundaries. Two of their requirements are:
- "The Location Object MUST support use of Unlinked Pseudonyms in the corresponding identification fields of Rule Maker, Target, Device, and Location Recipient. Since Unlinked Pseudonyms are simply bit strings that are not linked initially to a well-known identity, this requirement boils down to saying that the name space for Identifiers used in the LO has to be large enough to contain many unused strings." (#12)
- "The protocol SHOULD allow a bypass if authentication fails in an emergency call." (#15.3)
3. The GEOPRIV working group defines its own identity data models for the underpinning of location data access control policy. It is expected that agents holding or transferring location information about a user would implement an access control policy for controlling read access to the user's location information by other parties: who can be told, and what level of specificity should be revealed? The Common Policy document format for expressing privacy preferences (RFC 4745, February 2007) defines
"a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented."
An example from that specification, a rule that matches a user who has multiple possible URIs that identify them:
<conditions>
<identity>
<one id="sip:alice@example.com"/>
<one id="tel:+1-212-555-1234" />
<one id="mailto:bob@example.net" />
</identity>
</conditions>
or a rule that excludes certain users from matching:
<conditions>
<sphere value="work"/>
<identity>
<many>
<except domain="example.com"/>
<except domain="example.org"/>
<except id="sip:alice@bad.example.net"/>
<except id="sip:bob@good.example.net"/>
<except id="tel:+1-212-555-1234" />
<except id="sip:alice@example.com"/>
</many>
</identity>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
The Internet Draft Geolocation policy for privacy preferences (May 2007) describes how policy can encode selective disclosure of location. In a civic context:
full
{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>, <POD>,
<STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>, <NAM>, <FLR>,
<BLD>,<UNIT>,<ROOM>,<PLC>, <PCN>, <POBOX>, <ADDCODE>, <SEAT>
<RD>, <RDSEC>, <RDBR>, <RDSUBBR> <PRM>, <POM>}
|
|
building
{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>
<POD>, <STS>, <HNO>, <HNS>, <LMK>, <PC>,
<RD>, <RDSEC>, <RDBR>, <RDSUBBR> <PRM>, <POM>}
|
|
city
{<country>, <A1>, <A2>, <A3>}
|
|
region
{<country>, <A1>}
|
|
country
{<country>}
|
|
none
4. The GEOPRIV recommended data models for describing a location should be an influence upon the evolution of directory data models. Currently the LDAP schema derived from X.500 (RFC 4519, June 2006) includes a few postal service-derived attributes such as houseIdentifier and street, but does not allow more fine-grained specification of location, or correlation of attributes in multiple locations (e.g., grouping of attributes into home vs. work vs. school). GEOPRIV suggests two models: the Geography Markup Language (GML) 3.0 feature.xsd schema for describing points and spaces in 3D, and a Civic location format for describing a location based on streets and addresses. An example of the GML data model is
<gml:location>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
</gml:Point>
</gml:location>
The Internet-Draft Revised Civic Location Format (February 2007) includes a list of attributes for describing a location: country, A1, A2, A3, A4, A5, A6, PRM, PRD, RD, STS, POD, POM, RDSEC, RDBR, RDSUBBR, HNO, HNS, LMK, LOC, FLR, NAM, PC, BLD, UNIT, ROOM, SEAT, PLC, PCN, POBOX, ADDCODE. The civic format can be used independently from the GML
<civicAddress xml:lang="en-AU"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AU</country>
<A1>NSW</A1><A3>Wollongong</A3><A4>North Wollongong</A4>
<RD>Flinders</RD><STS>Street</STS>
<RDBR>Campbell Street</RDBR>
<LMK>Gilligan's Island</LMK> <LOC>Corner</LOC>
<NAM>Video Rental Store</NAM>
<PC>2500</PC>
<ROOM>Westerns and Classics</ROOM>
<PLC>store</PLC>
<POBOX>Private Box 15</POBOX>
</civicAddress>
or can be combined in a single location report, as described in the Internet Draft GEOPRIV PIDF-LO usage clarification (April 2007):
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
<gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point>
<cl:civicAddress>
<cl:FLR>2</cl:FLR>
</cl:civicAddress>
</gp:location-info>
There is already a DHCP option for civic address (RFC 4776, November 2006) and an Internet Draft for carrying location objects in RADIUS (July 2007).
5. The Presence-based location object format (RFC 4119, December 2005) PIDF-LO may be suitable as an attribute or claim in an identity metasystem, to transfer the current location of a user.
One of the outcomes of Instant Messaging (IM) interoperability was standards to specify and transfer a 'presence' status of a user - whether a user is currently online or not. The Common Profile for Presence (RFC 3859, August 2004) defines a model for the transfer of presence information between software agents, and a pres: URL to indicate sending an IM to a user identified as username@domain. The Presence Information Data Format (RFC 3863, August 2004) defines an XML-encoded data type. For example, a user pres:someone@example.com who is open for communication at a telephone number 09012345678 is expressed as:
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com">
<impp:tuple id="sg89ae">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<impp:contact priority="0.8">tel:+09012345678</impp:contact>
</impp:tuple>
</impp:presence>
The PIDF-LO specification extends the presence information data format with location information.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
entity="pres:mike@seattle.example.com">
<tuple id="sg89ab">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
<gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point>
<cl:civicAddress>
<cl:FLR>2</cl:FLR>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
A user might self-assert their location (I live in San Francisco) or pass on a value received from the local network (the Wi-Fi provider says I am currently at Market and Embarcadero).
The Internet draft of a threat and vulnerability analysis (April 2007) includes discussion of time shifting, location spoofing, location swapping, eavesdropping and violation of anonymity in protocols that carry these objects.
6. The PIDF-LO specification includes encoding usage rules alongside the location data: a retransmission-allowed boolean, a retention-expired date, and a ruleset-reference HTTPS URI. These constraints are generic and should be available for other attributes/claims that are not related to location.