Résumé

  • RFC 3693 nomme le Target, le Rule Maker, le Rule Holder, le générateur, le serveur, le destinataire et le Viewer au lieu de réduire le partage à un échange entre deux acteurs.
  • L’objet de localisation pouvait transporter des règles de confidentialité, mais chaque objet n’était pas tenu de les inclure et la gestion complète de ces règles restait hors champ.

Une coordonnée répond à « où ? ». Elle ne dit pas qui l’a fournie, qui est localisé, qui peut la voir, avec quel degré de précision, ni si le destinataire peut la conserver ou la retransmettre. C’est cette grammaire manquante que GEOPRIV a voulu rendre visible.

Publiée en février 2004 avec le statut Informational, RFC 3693 organise le problème autour de rôles distincts. Le Target est la personne ou l’entité localisée. Le Rule Maker crée les règles d’accès — souvent le Target, mais pas toujours : le texte donne aussi l’exemple d’un parent ou d’un employeur. Le Rule Holder conserve et fournit ces règles. Le Location Generator obtient la position et crée un objet ; le Location Server le reçoit, applique les règles et transmet les résultats autorisés ; le Location Recipient reçoit la donnée ; le Viewer la consulte sans la retransmettre. Un Data Transporter peut la faire passer sans la traiter. Plusieurs rôles peuvent être réunis dans un même appareil.

Cette distinction compte car la confidentialité dépend des relations, pas seulement du chiffrement. Une règle peut autoriser un détenteur de justificatif à connaître une ville tout en lui refusant une position plus précise. La RFC traite séparément collecte, usage, divulgation et conservation ; elle demande aussi la prise en charge de pseudonymes non liés et de justificatifs respectueux de la vie privée. L’identité des destinataires peut elle-même révéler les habitudes ou les relations du Target.

L’objet de localisation devait donc pouvoir contenir davantage qu’une coordonnée, sans devenir pour autant un jeton qui s’impose de lui-même. RFC 3693 exige qu’il permette l’application des règles par un tiers ; elle ne dit pas que chaque objet doit les embarquer. La décision du serveur de divulguer une position doit reposer sur les règles du Rule Maker. Un générateur qui n’a pas accès à l’ensemble des règles doit tout de même respecter les instructions du Rule Maker ; un Viewer ne devrait recevoir que le sous-ensemble utile à son traitement.

Les limites sont explicites. La RFC ne définit ni la gestion des règles ni la manière dont un serveur y accède. Elle laisse ouverte leur expressivité. Une limite de conservation peut avoir des conséquences techniques ambiguës et dépendre du droit ou des usages locaux. Le document exige l’authentification et la protection des règles, mais pas la distribution des clés. Il reconnaît enfin que protéger l’objet ne suffit pas à empêcher l’analyse du trafic ou des autres en-têtes.

Les documents ultérieurs marquent des étapes de spécification, pas une preuve d’usage universel. RFC 4119 définit un format d’objet fondé sur PIDF ; RFC 4079 décrit une architecture de présence. En 2011, RFC 6280, publiée comme BCP 160, met à jour RFC 3693 et RFC 3694 et développe une architecture plus large. HELD, la transmission par SIP et la résolution d’URI de localisation précisent ensuite des façons d’obtenir ou de transporter une position.

L’apport historique est plus limité que « l’Internet a résolu la confidentialité de la localisation ». RFC 3693 rend le plan de contrôle lisible : qui est localisé, qui écrit les règles, où elles sont conservées, qui les applique, quelle précision est transmise et ce que le destinataire peut faire ensuite. Un document d’exigences peut nommer ces frontières ; il ne prouve ni l’implémentation d’un service, ni le respect des règles, ni l’anonymat d’une personne.

Sources