2.1.4 Geographic Location/Privacy (geopriv)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional GEOPRIV Web Page

Last Modified: 2005-11-08


Allison Mankin <mankin@psg.com>
Randall Gellens <rg+ietf@qualcomm.com>
Andrew Newton <andy@hxr.us>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <shollenbeck@verisign.com>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion: geopriv@ietf.org
To Subscribe: geopriv-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/geopriv/index.html

Description of Working Group:

As more and more resources become available on the Internet, some
applications need to acquire geographic location information about
certain resources or entities. These applications include navigation,
emergency services, management of equipment in the field, and other
location-based services.

But while the formatting and transfer of such information is in some
sense a straightforward process, the implications of doing it,
especially in regards to privacy and security, are anything but.

The primary task of this working group will be to assess the the
authorization, integrity and privacy requirements that must be met in
order to transfer such information, or authorize the release or
representation of such information through an agent.

In addition, the working group will 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.  Approaches to be
considered will include (among others) data formats incorporating
fields directing the privacy handling of the location information and
possible methods of specifying variable precision of location.

Also to be considered will be:  authorization of requestors and
responders; authorization of proxies (for instance, the ability to
authorize a carrier to reveal what timezone one is in, but not what
city.  An approach to the taxonomy of requestors, as well as to the
resolution or precision of information given them, will be part of this

The combination of these elements should provide a service capable of
transferring geographic location information in a private and secure
fashion (including the option of denying transfer).

For reasons of both future interoperability and assurance of the
security and privacy goals, it is a goal of the working group to
deliver a specification that has broad applicablity and will become
mandatory to implement for IETF protocols that are location-aware.

Two further deliverables of the WG will be:

o An example API for application-level access to/management
  of link-based location information.  That is, for instance, the WG
  may describe an API for secure, privacy-enabling user/ application
  handling of location information specific to a 3G wireless link

o Development of i-ds that make security and privacy integral to
  location information in HTTP and HTML, based on the work in
  draft-daviel-html-geo-tag-05.txt and

Out of Scope:

This WG won't develop location-determining technology.  It will work
from existing technologies and where the technology is undeveloped,
will state that applicability may await others' developments.

This WG won't develop technology to support any particular regulatory
requirement [e.g. E.911] but will provide a framework that might be
used for private/secure definition of such technologies by other


The WG will coordinate with other WGs developing general privacy and
location-aware functions, e.g. the SIP WG, so that the WG deliverables
can be used by them.  Other coordination should include the NymIP
research community, WC3, and the Location Information Forum.

Goals and Milestones:

Done  Discuss initial geopriv scenarios and application requirements i-d's
Done  Discuss initial geographic location privacy and security requirements i-d.
Done  Initial i-d on geographic information protocol design, including privacy and security techniques.
Done  Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary.
Done  Submit geopriv scenarios and application requirements to IESG for publicaiton as Informational RFCs
Done  Submit security/privacy requirements I-D to IESG for publication as Informational RFC.
Done  Submit PIDF-LO basic geopriv object draft as a PS
Done  Initial Common Rules base object draft
Done  Initial Common Ruels GEOPRIV object draft
Done  Submit DHCP Civil draft as a PS
Feb 2005  Initial bis-requirements document
Feb 2005  Confer with SIP WG on SIP using protocol draft as PS
Feb 2005  Submit draft-ietf-geopriv-policy as PS
Feb 2005  Submit draft-ietf-geopriv-common-policy as PS
Mar 2005  Close or re-charter for GEOPRIV-MAINT
Mar 2005  Submit draft-ietf-geopriv-radius as PS


  • draft-ietf-geopriv-dhcp-civil-07.txt
  • draft-ietf-geopriv-policy-07.txt
  • draft-ietf-geopriv-pidf-lo-03.txt
  • draft-ietf-geopriv-common-policy-06.txt
  • draft-ietf-geopriv-radius-lo-04.txt
  • draft-ietf-geopriv-location-types-registry-03.txt
  • draft-ietf-geopriv-pdif-lo-profile-01.txt

    Request For Comments:

    RFC3693 I Geopriv requirements
    RFC3694 I Threat Analysis of the geopriv Protocol
    RFC3825 Standard Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information
    RFC4079 I A Presence Architecture for the Distribution of GEOPRIV Location Objects

    Current Meeting Report

    Minutes of the GEOPRIV Working Group from IETF 64
    1 Session I
          Co-chairs: Andrew Newton, Allison Mankin
          Scribe: Brian Rosen
        1.1 Agenda Basing
            1.1.1 Andrew Newton presented the agenda for both sessions of
              GEOPRIV and asked if the group if any modifications needed to
              be made.  James Polk noted that the second session of GEOPRIV
              conflicted with SIPPING and therefore many people who whould
              like to be part of the HELD discussion would not be present
              during the second session.  With the permission of James
              Winterbottom, Andrew noted that the HELD discussion could
              start once all the items scheduled for this session were
            1.1.2 Rohan Mahy reported that his filter draft was updated and
              would be resubmitted as a working group draft.
            1.1.3 Jonathan Rosenberg asked that the discussion on
              draft-ietf-geopriv-common-policy be conducted first because
              he had a schedule conflict in the latter part of the session.
               The chairs accepted this change to the agenda.
        1.2 Common Policy
              Presented by Hannes Tschofenig
            1.2.1 Hannes noted that the  condition as discussed in
              the last meeting had been changed.
            1.2.2 Hannes noted open issues with the draft:
       multiple scheme/sphere attribute
       questions regarding the degree of extensibility allowed
                  by the schema.
            1.2.3 Henning Schulzrinne noted that multiple "OR" conditions could
              be expressed with multiple rules, and suggested not using
              multiple values in scheme/sphere.  Jonathan Rosenberg agreed.
            1.2.4 Andrew, Henning, and Jonathan discussed collapsing the id
              component parts into a single URI.  The co-chairs asked for a
              hum of the room in support of using a single URI for the id,
              and the co-chairs found that the room consented to this
            1.2.5 Andrew noted that the draft has not Internationalization
              Considerations section and that internationalization issues
              may exist with the URI and specifically the domain when being
              used as an identifier.  There followed a discussion about the
              domain being a pure ASCII domain name or an IDN.  It was
              concluded that more needed to be known about IDNs before this
              decision could be made.
            1.2.6 Andrew asked the authors of the draft if the domain attribute
              was semantically only a domain name or more like an authority
              in a URI, such as with a port number.  Jonathan noted that
              the comparison would match if the ports differ, so it is only
              suppose to be a domain name.  Andrew noted that this needed
              to be clearly stated in the draft.
            1.2.7 Andrew asked if the sphere values required registration. 
              Henning and Jonathan stated that the values only had to be
              consitent within a document or using community but not
            1.2.8 The chairs asked if any other issues existed with the draft. 
              None were raised.
            1.2.9 The chairs asked if any issues existed with the related
              document, draft-ietf-geopriv-policy-07. None were raised.
        1.3 Provided-By
              Presented by James Polk
            1.3.1 James asserted that the current provided-by in PIDF-LO was
              not well defined and a more usable schema is presented in the
            1.3.2 Allison Mankin stated that it duplicates what is currently in
              PIDF-LO and is in conflict with the basic extensibility
              mechanism PIDF-LO uses to define multiple provided-by
              namespaces.  James said he did not know how to address this
            1.3.3 The chairs asked the room if the presentation needed to
              continue, and the consensus of the room is that it did not.
        1.4 NENA Provided-By
            1.4.1 While on the subject of provided-by, the chairs noted that
              they needed a response from NENA regarding the schema
              question raised by the RFC Editor.  Nadine Abbott, speaking
              as a participant of NENA, had been told that the truncation
              for historical reasons and was unnecessary.  The chairs noted
              that they would instruct the RFC Editor to remove the
              truncation and the length limitation from the schema.
        1.5 Carrying Location Objects in RADIUS
              Presented by Allison Mankin
            1.5.1 Allison presented the status of this proposal in context of
              the work being done in both GEOPRIV and RADEXT.  She stated
              that most of the issues are being cleared up with the RADEXT
              working group, and the current proposal going forward is to
              not use a generalized capabilities function but persue a
              "supported-loc" method.  Issues with this approach regarding
              an Access-Challenge remain.
            1.5.2 Some participants discussed dropping the use of LO with
              RADIUS and using DIAMETER for security reasons.  The chairs
              noted that the working group had covered that territory when
              this work was adopted by the working group, and that the
              working group would not go back to revisit this decision.  It
              was suggested that the draft contain text describing the
              privacy considerations that must be made.
            1.5.3 The chairs noted they did not intend to let a GEOPRIV last
              call on this document block on RADEXT, but would not send the
              document to the IESG until RADEXT had cleared all its issues
              with this document.
        1.6 HELD
              Presented by James Winterbottom
            1.6.1 James presented the changes made between the current version
              and the previous version of the draft.
            1.6.2 There was some discussion about the described feature of
              "talked to an LG".  It was noted that an LG just generates an
              LO, but anything that passes an LO is an LS.  So talking to
              an LG makes a network element an LS.  Since HELD already was
              an LS, this didn't make sense.  James agreed.
            1.6.3 Andrew questioned the appropriateness of using an IP address
              as a security credential.  James replied that "return
              routability" gauranteed that the IP address was not spoofed
              and that the access network was secure enough for such a
            1.6.4 It was suggested by Henning Schulzrine that the document be
              split into multiple documents, each targetting a specific
            1.6.5 Henning also suggested using an RPC mechanism like SOAP
              instead of multiple HTTP protocols.
            1.6.6 John Schnizlein noted that the function of passing around a
              location URI does not qualify as a Location Server.  James
              Winterbottom noted that he didn't understand the basis for
              this objection.
            1.6.7 Many participants discussed the discovery of HELD server when
              no layer to mechanism was available.  They noted concern that
              HELD has being described a service for use with DHCP was not
              available, but that it requried DHCP for discovery and
              therefore a dependecy on a protocol it is described to not
              need.  James noted that there were other mechanisms, such as
              DNS, for situations when DHCP was not available.  Marc Lisner
              noted that DNS may not be within the sphere of control of the
              access network operator.
            1.6.8 The chairs noted that the HELD discussion would be continued
              in the next session.
    2 Session 2
          Co-chairs: Andrew Newton, Randall Gellens
          Scribe: Nadine Abbot
        2.1 Agenda Bashing
            2.1.1 The chairs presented the agenda and asked if there were any
              requests to modify it.  None were raised.
        2.2 PIDF-LO Profile
              Presented by James Winterbottom
            2.2.1 James presented the changes between the current version of
              the draft and the previous version of the draft.
            2.2.2 James noted that Martin Thompson was working on a schema that
              would supplement this document, but that Martin's work would
              not be completed until the next IETF meeting.
            2.2.3 The room then discussed how to move forward.  Henning
              suggested that perhaps the working group out to consider an
              RFC 4119bis.  James suggested that the group get this
              document completed, and once there was enough implementation
              experience that an RFC 4119bis would make sense.  The chairs
              put the question to the paritipants of the room, and the
              consensus was to proceed according to the proposal described
              by James.
            2.2.4 Andrew Daviel inquired about the inclusion of conves holes. 
              James asked for an example to be provided, but noted that
              routing and location determination would likely not need this
        2.3 Revised Civic LO
              Presented by James Winterbottom
            2.3.1 James presented this draft, noting that it was intended to
              replace the current fields defined by Henning in the DHCP
              civic draft.
            2.3.2 There was a discussion regarding the use of placetype values.
               It was the agreement of the participants that place type
              values should not be freeform but should aligned with the
              IANA place types registry.
            2.3.3 Andrew Daviel suggested the inclusion of a URI pointing to a
              validation service.  Henning noted that such a service would
              be highly application dependent and should be outside the
              PIDF-LO document.  Ted Hardie noted that such a service would
              require protocol definition and not just a URI inserted into
              the civic fields.
            2.3.4 A discussion followed regarding new fields.  Andrew Newton
              noted that the current schemas do not account for road
              section numbers found in Tiawan.  Henning believed a field
              could be added to the A hierarchy.  James suggested
              overloading the Ad code field.  Henning objected to this.  It
              was noted that more information was needed regarding
              Tiawanese road section numbers before a determination
              regarding its place in a schema could be determined.
            2.3.5 The chairs asked the room if this document should be accepted
              as a working group item, and the consensus of the room held
              that it should be adopted and moved along as fast as possible.
        2.4 Facilitated HELD Discussion
              Presented by Andrew Newton in the capacity as co-chair
            2.4.1 Andrew presented is observations on the discussion on HELD
              from Session 1.
            2.4.2 James Winterbottom offered to have a conference call to
              discuss the different functions described by HELD.  Andrew
              requested that use cases for the various functions be sent to
              the mailing list so that GEOPRIV might get a better
            2.4.3 There was a discussion regarding the use of terminology in
              the HELD draft with regard to the terms as they are defined
              in RFC 3693.  It was noted that some of the terms are
              mismatched with the functions being applied.
            2.4.4 There was a discussion about sighting protocols and the
              applicability of this function with regard to RFC 3693.  Ted
              Hardie noted that sighting procotols and location object
              using protocols have different requirements.
            2.4.5 John Schnizlein  criticized the use case of being able to
              associate location with IP addresses.  James Winterbottom
              noted that the IP address is not the only key to determining
            2.4.6 James Winterbottom agreed to examine BCP 56 to see how it
              applies to HELD.
            2.4.7 Security issues were raised with regard to using an IP
              address as a credential.  James noted that return
              routability, or the handshake of TCP, offered a good enough
              gaurantee against spoofing.  It was noted that the use of IP
              addresses as a credential might open the service up to DoS
              attack as IP addresses are well known values within an
              operating environment.
            2.4.8 John Schnizlein requested that James provide answers to many
              of the issues on the mailing list so that they may be
              discussed in more detail.
            2.4.9 Brian Rosen asked the chairs if they would consider a hum
              with regard to accepting HELD and expressed concern that the
              working group was spending too much time discussing this item
              considering it was not a working group document.  James
              Winterbottom objected to this and asked for any hum to be
              conducted on the mailing list.  The chairs noted that all
              IETF consensus decisions had to be sent to the mailing list. 
              The chairs also noted that while many issues exist with HELD
              that there was a considerable constituency interested in the
              work and therefore the working group would continue
              evalutaing the proposal until all aspects were well
            2.4.10 James Winterbottom noted that he would discuss breaking HELD
              up into multiple documents with the co-authors of the
        2.5 Any Other Business
            2.5.1 Particpants of the ENUM working group asked that GEOPRIV
              participants review the ENUM validation work and offer
              suggestions or improvements on the civic schema.


    Direction of PIDF-LO
    Revised Civic Format
    Carrying Location Objects in RADIUS - GEOPRIV
    PIDF-LO Provided By
    Common-Policy Discussion
    Chair Facilliatated Discussion of HELD