Movatterモバイル変換

                       M. Loffredo                                 M. Martinelli Standards Track                            IIT-CNR/Registro.it                                               March 2024        Registration Data Access Protocol (RDAP) Reverse SearchAbstract   The Registration Data Access Protocol (RDAP) does not include query   capabilities for finding the list of domains related to a set of   entities matching a given search pattern.  Considering that an RDAP   entity can be associated with any defined object class and other   relationships between RDAP object classes exist, a reverse search can   be applied to other use cases besides the classic domain-entity   scenario.  This document describes an RDAP extension that allows   servers to provide a reverse search feature based on the relationship   defined in RDAP between an object class for search and any related   object class.  The reverse search based on the domain-entity   relationship is treated as a particular case.Status of This Memo   This is of the Internet Engineering Task Force   (IETF). of for of   and may be atCopyright Notice   Copyright (c) IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject to BCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect   to this document.  Code Components extracted from this document must   include Revised BSD License text as described in Section 4.e of the   Trust Legal Provisions and are provided without warranty as described   in the Revised BSD License.Table of Contents   1.  Introduction     1.1.  Background     1.2.  Conventions Used in This Document   2.  Reverse Search Path Segment Specification   3.  Reverse Search Definition   4.  Reverse Search Properties Discovery   5.  Reverse Search Properties Mapping   6.  Reverse Search Response Specification   7.  Reverse Search Query Processing   8.  Reverse Searches Based on Entity Details   9.  RDAP Conformance   10. Implementation Considerations   11. IANA Considerations  RDAP Extensions Registry  RDAP Reverse Search Registries  Creation of the RDAP Reverse Search Registries  Submit to IANA  RDAP Reverse Search Registry  Template  Initial Content  RDAP Reverse Search Mapping Registry  Template  Initial Content Privacy Considerations Security Considerations References  Normative References  Informative References   Appendix A.  Paradigms to Enforce Access Control on Reverse Search           in RDAP   Authors' Addresses1.  Introduction   The protocol described in this specification aims to extend the RDAP   query capabilities and response to enable reverse search based on the   relationships defined in RDAP between an object class for search and   a related object class.  The reverse search based on the domain-   entity relationship is treated as a particular case of such a generic   model.   RDAP providers willing to implement this specification should   carefully consider its implications on the efficiency (see   Section 10), the security (see Section and the compliance with   privacy regulations (see Section of their RDAP service.1.1.  Background   Reverse is a service provided by many web applications that   allows users to find domain names owned by an individual or a company   starting from the owner's details, such as name and email.  Even if   it has been considered useful for some legal purposes   uncovering trademark detecting cybercrimes), its   availability as a standardized [RFC3912] capability has been   objected to for two main reasons, which now don't seem to conflict   with an RDAP implementation.   The first objection concerns the potential risks of privacy   violation.  However, the domain name community is considering a new   generation of Registration Directory Services provide access to sensitive data under some permissible purposes   and in accordance with appropriate policies for requestor   accreditation, and authorization.  RDAP's reliance on   HTTP means that it can make use of common approaches to   authentication and authorization, making it more useful than in   the context of such directory services.  Since RDAP consequently   permits a reverse search implementation complying with privacy   protection principles, this first objection is not   The second objection to the implementation of a reverse search   capability has been connected with its impact on server processing.   However, the core RDAP specifications already define search queries,   with similar processing requirements, so the basis of this objection   is not clear.   Reverse searches, such as finding the list of domain names associated   with contacts or nameservers, may be useful to registrars as well.   Usually, registries adopt out-of-band solutions to provide results to   registrars asking for reverse searches on their domains.  Possible   reasons for such requests are:   *  the loss of synchronization between the registrar database and the      registry   *  the need for such data to perform bulk Extensible Provisioning      Protocol (EPP) [RFC5730] updates changing the contacts of a      set of domains, etc.).   Currently, RDAP does not provide any means for a client to search for   the collection of domains associated with an entity [RFC9082].  A   query (lookup or search) on domains can return the array of entities   related to a domain with different roles (registrant, registrar,   administrative, technical, reseller, etc.), but the reverse operation   is not allowed.  Only reverse searches to find the collection of   domains related to a nameserver (ldhName or ip) can be requested.   Since an entity can be in relationship with any RDAP object   [RFC9083], the availability of a reverse search as largely intended   can be common to all the object classes allowed for search.  Through   a further step of generalization, the meaning of reverse search in   the RDAP context can be extended to include any query for retrieving   all the objects another matching a given search   pattern.1.2.  Conventions Used in This Document   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and   "OPTIONAL" in this document are to be interpreted as described in   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all   capitals, as shown here.2.  Reverse Search Path Segment Specification   A generic reverse search path is described by the syntax:   {searchable-resource-type}/reverse_search/{related-resource-   type}?<search-condition>   The path segments are defined as   "searchable-resource-type": MUST be one of the resource types for      search defined in Section 3.2 of [RFC9082] "domains", and "entities") or a resource type   "related-resource-type": MUST be one of the resource types for      lookup defined in Section 3.1 of [RFC9082] "domain",      "nameserver", "entity", and "autnum") or a resource type   "search-condition": sequence of "property=search pattern"      predicates separated by the ampersand character ('&', US-ASCII      value 0x0026).   While related-resource-type is defined as having one of a number of   different values, the only reverse searches defined in this document   are for a related-resource-type of "entity".  Reverse searches for   the other resource types specified in [RFC9082] and resource type   extensions may be defined by future documents.3.  Reverse Search Definition   Based on the content of Section 2, defining a reverse search means to   define the triple <searchable resource type, related resource type,   property> and the mapping with the corresponding RDAP object member.   The mapping is done through the use of a JSONPath expression  Reverse searches are registered in the Reverse registry (see Section whereas reverse search   mappings are registered in the Reverse Search registry   (see Section  The reason for having two registries is that   it may be possible for a single type of reverse search to rely on   different members, depending on the server's configuration (see   Section 5).   All of the reverse searches defined by this document (see Section 8)   have property names that are the same as the name of the RDAP object   member that is the subject of the search.  For example, the reverse   search with the property name "fn" relies on the value of the "fn"   member inside the jCard of an entity object.  However, it is not   necessary that these two names be the same.  In particular, remapping   of searches as part of the deprecation of an existing member (see   Section 5) will typically lead to a member with a different name   being used for the search.   Servers MUST NOT provide or implement reverse searches or reverse   search mappings that are not registered with IANA.4.  Reverse Search Properties Discovery   Servers complying with this specification MUST extend the help   response [RFC9083] with the "reverse_search_properties" member   contains an array of objects with the following mandatory child   members:   "searchableResourceType":  the searchable resource type of the      reverse search as defined in Section   "relatedResourceType":  the related resource type of the reverse      search as defined in Section   "property":  the reverse search property used in the predicate of the      reverse search as defined in Section   An example of the help response including the   "reverse_search_properties" member is shown in Figure5.  Reverse Search Properties Mapping   To permit clients to determine the member used by the server for a   reverse search, servers MUST detail the mapping that is occurring by   adding the "reverse_search_properties_mapping" member to the topmost   object of a reverse search response.  This data is included   in the search response, rather than in the help response, because it   may differ depending on the query that is sent to the server.   Documents that deprecate or restructure RDAP responses such that a   registered reverse search is no longer able to be used MUST either   note that the relevant reverse search is no longer available (in the   case of deprecation) or describe how to continue supporting the   relevant search by adding another mapping for the reverse search   property (in the case of restructuring).   The "reverse_search_properties_mapping" member contains an array of   objects with the following mandatory child members:   "property":  the reverse search property used in the predicate of the      current as defined in Section   "propertyPath":  the JSONPath expression of the object member (or      members) corresponding to the reverse search   The searchable and the related resource types are derived from the   query, so there is no need to include them in addition to the   property in this member.   This member MUST be included for all properties used in the search,   regardless of whether that property has multiple registered mappings   as at the time of the search, because new mappings may be registered   at any time.   When applied to an object, the JSONPath expression MUST produce a   list of values, each of which is a JSON number or string.   An example of a reverse search response including the   "reverse_search_properties_mapping" member is shown in Figure 3.6.  Reverse Search Response Specification   Reverse search responses use the formats defined in 8 of   [RFC9083], which correspond to the searchable resource types defined   in Section 2.7.  Reverse Search Query Processing   To process a reverse search, the server returns the objects from its   data store that are of type searchable-resource-type and that match   each of the predicates from the search conditions.  To determine   whether an object matches a predicate, the server:   *  applies the mapping it uses for the reverse search property to the      object in order to generate a list of values, each of which MUST      be a JSON number or and   *  checks whether the search pattern matches one or more of those      values.   A search pattern matches a value where it equals the string   representation of the or where it is a match for the value in   accordance with the partial string matching defined in 4.1 of [RFC9082].   Objects are only included in the search results if they satisfy all   included predicates.  This includes predicates that are for the same in such a for the related object to   match against each of those predicates.   Servers MUST return an HTTP 501 (Not Implemented) [RFC9110] response   to inform clients of unsupported reverse searches.   Based on their policy, servers MAY restrict how predicates are used   to make a valid search by returning a 400 (Bad Request)   response when a problematic request is received.   A given reverse search or reverse search mapping MAY define   additional or alternative search past that set out in this   section.8.  Reverse Searches Based on Entity Details   Since an entity can be associated with any other object the most common kind of reverse search is one based on an   entity's details.  Such reverse searches arise from the query model   by setting the related resource type to "entity".   By selecting a specific searchable resource type, the resulting   reverse search aims at retrieving all the objects all the   domains) that are related to any entity object matching the search   conditions.   This section defines the reverse search properties servers SHOULD   support for the domain, nameserver, resource   and resource type:   Reverse search property:  role   RDAP member path:  $.entities[*].roles   Reference:  Section 10.2.4 of [RFC9083]   Reverse search property:  handle   RDAP member path:  $.entities[*].handle   Reference:  Section 5.1 of [RFC9083]   Reverse search property:  fn   RDAP member path:  $.entities[*].vcardArray[1][?(@[0]=='fn')][3]   Reference:  Section 6.2.1 of [RFC6350]   Reverse search property:  email   RDAP member path:  $.entities[*].vcardArray[1][?(@[0]=='email')][3]   Reference:  Section 6.4.2 of [RFC6350]   The presence of a predicate on the reverse search property "role"   means that the RDAP response property "roles" MUST contain at least   the specified role.   The last two properties are related to jCard elements [RFC7095], but   the field references are to vCard [RFC6350], since jCard is the JSON   format for vCard.   Examples of reverse search paths based on the domain-entity   relationship are presented in Figure 1.    /domains/reverse_search/entity?handle=CID-40*&role=technical    /domains/reverse_search/entity?fn=Bobby*&role=registrant    /domains/reverse_search/entity?handle=RegistrarX&role=registrar                Figure 1: Examples of   An example of the help response including the reverse   search properties is shown      {        "rdapConformance": [          "rdap_level_0",          "reverse_search"        ],        ...        "reverse_search_properties": [          {            "searchableResourceType": "domains",            "relatedResourceType": "entity",            "property": "fn"          },          {            "searchableResourceType": "domains",            "relatedResourceType": "entity",            "property": "handle"          },          {            "searchableResourceType": "domains",            "relatedResourceType": "entity",            "property": "email"          },          {            "searchableResourceType": "domains",            "relatedResourceType": "entity",            "property": "role"          }        ],        ...      }          Figure 2: An of including the   An example of a response including the mapping that is occurring for   the first reverse search in Figure 1 is shown below.      {        "rdapConformance": [          "rdap_level_0",          "reverse_search"        ],        ...        "reverse_search_properties_mapping": [          {            "property": "handle",            "propertyPath": "$.entities[*].handle"          },          {            "property": "role",            "propertyPath": "$.entities[*].roles"          }        ],        ...      }           Figure 3: An of an RDAP including the9.  RDAP Conformance   Servers complying with this specification MUST include the value   "reverse_search" in the rdapConformance property of the help response   [RFC9083] and any other response including the   "reverse_search_properties_mapping" member.  The information needed   to register this value in the "RDAP Extensions" registry is described   in Section10.  Implementation Considerations   To limit the impact of processing the search predicates, servers are   RECOMMENDED to make use of techniques to speed up the data retrieval   in their underlying data such as indexes or similar.  In   addition, risks with respect to performance degradation or result set   generation can be mitigated by adopting practices used for standard   searches, restricting the search functionality, limiting the   rate of search requests according to the user's authorization,   truncating and paging the results [RFC8977], and returning partial   responses [RFC8982].11.  IANA Considerations  RDAP Extensions Registry   IANA the following value in the "RDAP Extensions"   registry:   Extension  reverse_search   Registry  Any   Contact:  IETF <iesg@ietf.org>   Intended  This extension identifier is used for both URI path      segments and response extensions related to the reverse search in      RDAP.  RDAP Reverse Search Registries  Creation of the RDAP Reverse Search Registries   IANA the "RDAP Reverse Search" and "RDAP Reverse Search   Mapping" registries within the "Registration Data Access Protocol   These registries follow the Specification Required as defined in Section of [RFC8126].   The designated expert should prevent collisions and confirm that   suitable documentation, as described in Section of [RFC8126], is   available to ensure interoperability.   Creators of either new RDAP reverse searches or new mappings for   registered reverse searches SHOULD NOT replicate functionality   already available by way of other documents referenced in these   registries.  Creators MAY register additional reverse search mappings   for existing properties, but they SHOULD NOT map a registered reverse   search property to a response field with a meaning other than that of   the response fields referenced by the mappings already registered for   that property.  In other words, all the mappings for a reverse search   property MUST point to response fields with the same meaning.  Submit to IANA   Registration requests can be sent to <iana@iana.org>.  RDAP Reverse Search Registry  Template Resource  The searchable resource type of the      reverse search query (Section 2) including the reverse search      property.  Multiple reverse search properties differing only by      this field can be grouped together by listing all the searchable      resource types separated by comma (see Section Resource  The related resource type of the reverse      search query (Section 2) including the reverse search property.  The name of the person registering the reverse search      property.   Contact  An email address, postal address, or some other      information to be used to contact the registrant.  Document the RFC number) and section reference      where the reverse search property is specified.   The combination of Resource Resource   and MUST be unique across the registry entries.  Initial Content   IANA the following entries in the "RDAP Reverse   Search" registry.  For all entries, the common values are shown in   Table whereas the specific values are shown in Table 2.       | Registry Property        | Value                          |       | Searchable Resource Type | domains, nameservers, entities |       | Related Resource Type    | entity                         |       | Registrant               | IETF                           |       | Contact Information      | iesg@ietf.org                  |       | Reference                |                       |             Table 1: Common for in the                          Reverse        +==========+==============================================+        | Property | Description                                  |        +==========+==============================================+        | fn       | The server supports the domain/nameserver/   |        |          | entity search based on the full name (a.k.a. |        |          | formatted name) of an associated entity      |        +----------+----------------------------------------------+        | handle   | The server supports the domain/nameserver/   |        |          | entity search based on the handle of an      |        |          | associated entity                            |        +----------+----------------------------------------------+        | email    | The server supports the domain/nameserver/   |        |          | entity search based on the email address of  |        |          | an associated entity                         |        +----------+----------------------------------------------+        | role     | The server supports the domain/nameserver/   |        |          | entity search based on the role of an        |        |          | associated entity                            |        +----------+----------------------------------------------+              Table 2: Specific for in the                          Reverse  RDAP Reverse Search Mapping Registry  Template  The same as defined in the Resource  The same as defined in the  The same as defined in the  The name of the person registering this reverse search      property mapping.   Contact  The same as defined in the  Document the RFC number) and section reference      where this reverse search property mapping is specified.   The combination of Resource Resource and MUST be unique across the registry   entries.  Initial Content   IANA the following entries in the "RDAP Reverse Search   Mapping" registry.  For all entries, the common values are the same   as defined in the "RDAP Reverse Search" registry (see Table   whereas the specific values are shown Table      +==========+==================================================+      | Property | Property Path                                    |      +==========+==================================================+      | fn       | $.entities[*].vcardArray[1][?(@[0]=='fn')][3]    |      +----------+--------------------------------------------------+      | handle   | $.entities[*].handle                             |      +----------+--------------------------------------------------+      | email    | $.entities[*].vcardArray[1][?(@[0]=='email')][3] |      +----------+--------------------------------------------------+      | role     | $.entities[*].roles                              |      +----------+--------------------------------------------------+          Table 3: Specific for in the Reverse                          Search  Privacy Considerations   The search functionality defined in this document may affect the   privacy of entities in the registry (and elsewhere) in various   see [RFC6973] for a general treatment of privacy in protocol   specifications.  Registry operators should be aware of the   that result from this functionality.   Many jurisdictions have laws or regulations that restrict the use of per the definition in [RFC6973].  Given that,   registry operators should ascertain whether the regulatory   environment in which they operate permits implementation of the   functionality defined in this document.   In those cases where this functionality makes use of sensitive   information, MUST only be accessible to authorized   users lawful basis.   Since reverse search requests and responses could contain Personally   Identifiable Information (PII), reverse search functionality MUST be   available over HTTPS only.   Providing reverse search in RDAP carries the following threats as   described in [RFC6973]:   *  Correlation   *  Disclosure   *  Misuse of   Therefore, RDAP providers need to mitigate the risk of those threats   by implementing appropriate measures supported by security services   (see Section  Security Considerations   Security services required to provide controlled access to   the operations specified in this document are described in [RFC7481].   A non-exhaustive list of access control paradigms an RDAP provider   can implement is presented in Appendix A.   As an additional measure to enforce security by preventing reverse   searches to be accessed from unauthorized users, the RDAP providers   may consider physically the reverse search endpoints from   the other ones by configuring a proxy routing the reverse searches to   a dedicated backend server and leveraging further security services   offered by other protocol such as digital certificates and IP   Finally, the specification of the relationship within the reverse   search path allows the RDAP servers to implement different   authorization policies on a per-relationship basis.  References  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <https://www.rfc-editor.org/info/rfc2119>.   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,              DOI 10.17487/RFC6350, August 2011,              <https://www.rfc-editor.org/info/rfc6350>.   [RFC7095]  Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,              DOI 10.17487/RFC7095, January 2014,              <https://www.rfc-editor.org/info/rfc7095>.   [RFC7481]  Hollenbeck, S. and N. Kong, "Security Services for the              Registration Data Access Protocol (RDAP)", STD 95,              RFC 7481, DOI 10.17487/RFC7481, March 2015,              <https://www.rfc-editor.org/info/rfc7481>.   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for              Writing an IANA Considerations Section in RFCs", BCP 26,              RFC 8126, DOI 10.17487/RFC8126, June 2017,              <https://www.rfc-editor.org/info/rfc8126>.   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,              May 2017, <https://www.rfc-editor.org/info/rfc8174>.   [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access              Protocol (RDAP) Query Format", STD 95, RFC 9082,              DOI 10.17487/RFC9082, June 2021,              <https://www.rfc-editor.org/info/rfc9082>.   [RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the              Registration Data Access Protocol (RDAP)", STD 95,              RFC 9083, DOI 10.17487/RFC9083, June 2021,              <https://www.rfc-editor.org/info/rfc9083>.   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,              Ed., "HTTP Semantics", STD 97, RFC 9110,              DOI 10.17487/RFC9110, June 2022,              <https://www.rfc-editor.org/info/rfc9110>.  Informative References   [ICANN-RA] Agreement", "Final Report from the Expert Working Group on gTLD              Directory Services: A Next-Generation Registration              Directory Service (RDS)", June 2014,              <https://www.icann.org/en/system/files/files/final-report-              06jun14-en.pdf>.   [OIDCC] "OpenID Connect Core incorporating              errata set              <http://openid.net/specs/openid-connect-core-1_0.html>.   [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,              DOI 10.17487/RFC3912, September 2004,              <https://www.rfc-editor.org/info/rfc3912>.   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,              <https://www.rfc-editor.org/info/rfc5730>.   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,              Morris, J., Hansen, M., and R. Smith, "Privacy              Considerations for Internet Protocols", RFC 6973,              DOI 10.17487/RFC6973, July 2013,              <https://www.rfc-editor.org/info/rfc6973>.   [RFC8977]  Loffredo, M., Martinelli, M., and S. Hollenbeck,              "Registration Data Access Protocol (RDAP) Query Parameters              for Result Sorting and Paging", RFC 8977,              DOI 10.17487/RFC8977, January 2021,              <https://www.rfc-editor.org/info/rfc8977>.   [RFC8982]  Loffredo, M. and M. Martinelli, "Registration Data Access              Protocol (RDAP) Partial Response", RFC 8982,              DOI 10.17487/RFC8982, February 2021,              <https://www.rfc-editor.org/info/rfc8982>.Appendix A.  Paradigms to Enforce Access Control on Reverse Search in             RDAP   Access control can be implemented according to different paradigms   introducing increasingly stringent rules.  The paradigms   leverage the capabilities either or provided as   extensions by the OpenID Connect [OIDCC]:   Role-Based Access Control (RBAC): rights are granted      depending on roles.  Generally, this is done by grouping users      into fixed categories and assigning static grants to each      category.  A more dynamic approach can be implemented by using the      OpenID Connect "scope"   Purpose-Based Access Control (PBAC): rules are based on the      notion of purpose, being the intended use of some data by a user.      It can be implemented by tagging a request with the usage purpose      and making the RDAP server check the compliance between the given      purpose and the control rules applied to the data to be   Attribute-Based Access Control (ABAC): to manage access rights      are evaluated and applied according to specific attributes      describing the context within which data are requested.  It can be      implemented within an out-of-band process additional      OpenID Connect claims the request context and      the RDAP server check compliance between the given context and      the control rules applied to the data to be   Time-Based Access Control (TBAC): access is allowed for a      limited time only.  It can be implemented by assigning users      temporary credentials linked to access grants   With regard to the privacy threats reported in Section   correlation and disclosure can be mitigated by minimizing both the   request features and the response data based on user roles   RBAC).  Misuse can be mitigated by checking for the purpose of the   request PBAC).  It can be accomplished according to the   following approaches:   Full Trust: registry trusts the fairness of an accredited user.      The requestor is always legitimized to submit requests under      a lawful basis.  Additionally, can be required to specify the      purpose as either a claim of account or a query parameter.      In the former case, the purpose is assumed to be the same for      every request.  In the latter case, the purpose must be one of      those associated to the   Zero Trust: registry requires documents that the      requestor is legitimized to submit a given request.  It can be      implemented by assigning the requestor temporary OpenID account      linked to the given request TBAC) and describing the      request through a set of claims ABAC).  The association      between the temporary account and the claims about the request is      made by an out-of-band application.  In so doing, the RDAP server      is able to check that the incoming request is consistent with the      request claims linked to the temporary account.   The two approaches can be used together:   *  The former is suitable for users carrying out a task in the public or exercising their official authority an officer      of a cybercrime agency).  Similarly, registrars can submit reverse      searches on their domains and contacts based on their contractual      relationship with the domain holders.  In this case, the query      results can be restricted to those pertaining a registrar by      adding an implicit predicate to the search condition.   *  The latter can be taken to allow domain name dispute resolution      service providers to request information in defense of the      legitimate interests of complainants.Acknowledgements   The authors would like to acknowledge the following individuals for   their contributions to this document: Francesco Donini, Scott   Hollenbeck, Francisco Arias, Gustavo Lozano, Eduardo Alvarez, Ulrich   Wisser, James and Pawel Kowalik.   Tom Harrison and Jasdip Singh provided relevant feedback and constant   support to the implementation of this proposal.  Their contributions   have been greatly appreciated.Authors' Addresses   Mario Loffredo   IIT-CNR/Registro.it   Via Moruzzi,1   56124 Pisa   Italy   Email: mario.loffredo@iit.cnr.it   URI:   http://www.iit.cnr.it   Maurizio Martinelli   IIT-CNR/Registro.it   Via Moruzzi,1   56124 Pisa   Italy   Email: maurizio.martinelli@iit.cnr.it   URI:   http://www.iit.cnr.it