Network Working Group A. Rezafard Internet-Draft Afilias Canada Intended status: Informational November 17, 2008 Expires: May 21, 2009 Extensible Supply-chain Discovery Service Problem Statement draft-rezafard-esds-problem-statement-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 21, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Rezafard Expires May 21, 2009 [Page 1] Internet-Draft ESDS Problem Statement November 2008 Abstract This document discusses the requirements of an application layer protocol for Discovery Services. Discovery Services at its core offers to authenticated and authorized users the means to discover resources of information for a particular identifier. The information resource can be any data source which provides an interface on a network that allows for retrieval of the data. An information resource could publish its network address (reference to the resource) to a Discovery Service coupled with an identifier. Then an authenticated and authorized user could query the Discovery Service with the same identifier to receive reference information to the resources. Interfacing with the resources for actually retrieving the data is out of scope of Discovery Services; the role of Discovery Services is to enable a client to find the network addresses and types (e.g. URLs) of information resources for a particular identifier of interest. This protocol is applicable to numerous scenarios such as track and trace in trade supply chains, where a number of independent resources may hold information about a particular object and may have an interest in selective sharing of that information, in order to improve the efficiency of the supply chain network. However, other applications can be envisaged, as a 'bottom-up' or 'grassroots' way for generators of information content to: 1) declare that they have information or commentary on a particular topic or subject (which might be a physical object, geographic location or even an abstract concept) 2) specify a network address through which that content can be retrieved, 3) specify restrictions about the community of clients that are entitled to receive knowledge about the existence of their content or see the link. This approach can be contrasted with the top-down approach of existing web search engines that rely on crawling/spidering of content that must be already posted in the public domain before it can be indexed - and where the link information is generally made publicly available in a manner that does not discriminate between clients on an individual basis. This document outlines a set of design concerns that an application layer protocol needs to address in order to be widely adopted and deployable on public networks This document obsoletes "Extensible Supply-chain Discovery Service Problem Statement draft-rezafard-esds-problem-statement-02". Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s). Rezafard Expires May 21, 2009 [Page 2] Internet-Draft ESDS Problem Statement November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Introduction: Supply chain applications as one driver . . 5 1.2. What is ESDS? . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Problem Statement . . . . . . . . . . . . . . . . . . . . 7 1.5. Description . . . . . . . . . . . . . . . . . . . . . . . 9 2. Internet Concerns . . . . . . . . . . . . . . . . . . . . . . 10 2.1. Public Networks and Tree-Walking Concerns . . . . . . . . 10 2.2. Bootstrapping Concerns . . . . . . . . . . . . . . . . . . 11 3. Other Standards . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Object Naming Service (ONS) . . . . . . . . . . . . . . . 13 3.2. EPC Information Services (EPCIS) . . . . . . . . . . . . . 13 3.3. Universal Description Discovery and Integration (UDDI) . . 13 3.4. Interface for Metadata Access Point (IF-MAP) . . . . . . . 14 4. Related Standards Development Organizations . . . . . . . . . 16 5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Flow Diagrams . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.1. Access Control . . . . . . . . . . . . . . . . . . . . 18 5.3. Publish . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.5. Relabel/Aggregation/Disaggregation . . . . . . . . . . . . 20 5.6. Multiple Organizations . . . . . . . . . . . . . . . . . . 21 5.7. Identifier Agnostic . . . . . . . . . . . . . . . . . . . 21 5.7.1. Reusing Identifiers . . . . . . . . . . . . . . . . . 22 5.8. Extensible . . . . . . . . . . . . . . . . . . . . . . . . 23 5.9. Policies . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.10. Stale Links . . . . . . . . . . . . . . . . . . . . . . . 23 5.11. Peer-to-Peer Communications . . . . . . . . . . . . . . . 24 6. Technical Challenges . . . . . . . . . . . . . . . . . . . . . 26 6.1. Auditability . . . . . . . . . . . . . . . . . . . . . . . 26 6.2. Responsiveness . . . . . . . . . . . . . . . . . . . . . . 26 6.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 26 7. Related Activities . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35 Rezafard Expires May 21, 2009 [Page 3] Internet-Draft ESDS Problem Statement November 2008 1. Introduction As the Internet applications become more and more service oriented and specialized, the demand for collaboration among these applications increases. These applications can collaborate on services or on topics. Open collaboration on services is already taking place via Universal Description Discovery and Integration (UDDI). Selective collaboration on specific topics is the problem domain that Discovery Services aims to address. A first step towards collaboration among applications on topics would be to use a common identifier for each topic. For example a topic can be something conceptual like the name of a book, or a topic can be a particular physical object with a serialized identifier. The use of common identifiers will enable dispersed applications to inter-communicate with each other. Note that it is not the role of Discovery Services to develop such common identifiers - this is left to existing standards such as URIs and semantic web initiatives such as the Dublin Core vocabulary. The second step for the applications would be to find other resources of information on a common topic. This is made possible when an application advertizes that it holds information on a topic. This is made possible by Discovery Services since an application can advertize to a Discovery Service that it holds information on a specific topic, by publishing a reference to resources that hold relative information on the topic of interest. At a conceptual level, Discovery Services can be superficially regarded as being somewhat analogous to a bottom-up 'search engine' for an 'Internet of things'. However, there are some fundamental differences from the paradigm of public web search engines. The serial-level information will usually be protected and will only be made available to authorized organizations, with whom the information provider has an established trust relationship. For this reason, we cannot assume that Discovery Services will be able to automatically 'spider' or 'crawl' the network to compile an index of links, since the underlying information may not be generally available. Instead, we assume that each information provider will be able to voluntarily publish a record or registration for a particular common identifier, in order that a link can be established back to them as a potential provider of information. At the same time, also the 'link' information will be protected by access control policies defined by each information provider, as well as any policies that are imposed by the operator of a Discovery Service. Unlike most public search engines, there may be little or no 'link' information provided to non-authenticated users or directly to the general public without Rezafard Expires May 21, 2009 [Page 4] Internet-Draft ESDS Problem Statement November 2008 authentication, although in some specific applications, citizens may be provided with indirect access to traceability information that was gathered via an authorized authenticated actor, such as the retailer or manufacturer. This approach enables distributed management of collected information and allows each organization to restrict who can access the data; they can specify an access control policy (which is enforced by a Discovery Service) to limit visibility of the 'link' information - and additionally, they can specify and enforce an access control policy within their own information resource that holds the more detailed information. 1.1. Introduction: Supply chain applications as one driver Currently, a number of industry sectors are moving towards improved track and trace systems by the use of Auto-ID technologies (such as Radio-Frequency Identification (RFID)) that improve the ability to automate collection of observations, as well as the use of unique identifiers for each individual object, to improve the granularity of information, so that it is possible to track not only at the granularity of batches or lots - but actually trace the entire life history of an individual object. This is particularly important in the fight against counterfeiting and for assuring the traceability and authenticity of foods, pharmaceuticals and other safety-critical objects, such as aircraft and automotive parts. As well as automating the collection of such data, companies are also moving towards sharing and exchange of serial-level data (i.e. data about individually identifiable objects), in order to improve the efficiency of supply chains. This involves greater use of machine- to-machine information exchange, using standard interfaces for queries and output formats and requiring less intervention by human operators (e.g. less exchanging of spreadsheets via e-mail or FTP). However, serial-level data is commercially sensitive, since it can reveal information about stock levels and volumes and flows of goods. For this reason, most companies insist on maintaining strict control over who is granted access to their data, including the links to their data repositories or information services. The entire lifecycle information for an individual object therefore remains decentralized and fragmented across multiple actors in the supply chain or extended product lifecycle. Discovery Services will provide secure referral services that can be queried with a unique ID and return to authenticated authorized clients a list of links to multiple information providers, who can then be queried for more detailed information about the individual object. Rezafard Expires May 21, 2009 [Page 5] Internet-Draft ESDS Problem Statement November 2008 1.2. What is ESDS? ESDS is a protocol for infrastructure that enables track and trace applications as well as product lifecycle information systems to find multiple sources of information. Using the links provided by Discovery Services, they can then attempt to gather complete information about an individual physical object. Several organizations may handle an individual object at different stages of its life - and each of these organizations may collect and store some information about each object. This may include observations of where the object was seen, details of operations performed on the object, as well as measurements (e.g. temperature) of the object or its environment. Even two objects that are of the same product type and which were created in the same batch or lot may ultimately follow different paths throughout their lives and each might be handled by a completely different set of organizations. We DO believe that each organization should be able to keep control of the data that they collect and store - and should have the ability to determine how much of this information is made available to others - and with whom. This can be achieved by requiring authentication of clients specifying fine-grained access control policies associated with the roles assigned to those authenticated clients. We DO NOT propose that ESDS should act as an aggregator of detailed information. Instead, ESDS is intended as a lightweight referral service, whose sole purpose is to help a client to find one or more sources of detailed information. In practice, a query to an ESDS about an object ID should return to an authenticated client a list of URLs of information resources that hold the detailed information about that particular object. The client will only receive the URLs to information resources that have authorized (e.g. via access control policies) the client to see their URL address for that specific object ID. The client can then contact each of those information resources in order to request more detailed information. This process is OUTSIDE the scope of ESDS and may be subject to further authentication and authorization checks bilaterally between the client and each individual information resource. 1.3. Terminology There are three actors in this problem: Rezafard Expires May 21, 2009 [Page 6] Internet-Draft ESDS Problem Statement November 2008 Client: refers to an actor that seeks (sources of) information about an individual object (or topic). Resource: refers to an actor that holds information about an individual object (or topic) and may choose to share (some of) that information with a client (under certain conditions). ESDS: refers to an intermediary lookup service protocol that enables a client to obtain referral information to one or more resources. Publish: refers to the act of writing to a intermediary lookup service, Resource reference (address) information coupled with an object (or topic) identifier. The publishing actor, as the information owner, could define access control rules to restrict which clients (or client roles) are allowed to view the Resource reference (address) for a particular object (or topic). What emerges from combinations of these actors and their relationships are: Organization (Partner): refers to a business entity, which can be comprised of client actors or Resource actors. Community (Supply chain): refers to a group of member organizations (partners) that may be willing to share some information among themselves. Note that not all members of the community will share exactly the same access privileges; there can be different bilateral access privileges within a community. Each organization can define rules that restrict which clients shall be allowed to see the address of its resource as a potentially relevant resource for a particular object identifier (or topic). Note that in some situations, the overall access control policy may be the result of a combination of rules defined by one or more organizations, as well as rules defined at a community level. Access privileges as defined by a community and its member organizations are only applicable to the information published by ESDS. Each Resource must take its own security measures to protect its data (hosted at the published network address) from unprivileged clients. 1.4. Problem Statement Information sharing between organizations is essential for all modern networked communities. There is a strict set of business and technical requirements that must be observed in order to enable open sharing of information between organizations. There are resources and clients in each community. Each resource wants to advertise its knowledge (data) to interested and authorized Rezafard Expires May 21, 2009 [Page 7] Internet-Draft ESDS Problem Statement November 2008 clients. Only deploying private networks to connect whole communities is no longer feasible, as the more efficient and economical means of connecting resources and clients is to use public network infrastructure. Currently, many industrial inter- organizational track-and-trace initiatives are deployed on public networks and the information is routed through the Internet. Because of this trend, it is highly desirable that a draft protocol should be developed. An IETF process consensus would ensure that the adopted protocol conforms to the Internet's operational needs. A key principle of information sharing within a community is that data ownership must be respected. This means that each organization can collect information within their own systems and is not required to route that information to any other organizations. However, they can choose to share selected information with other trusted organizations. This in turn means that the information about any individual object may be held by multiple resources in a community. Therefore a mechanism is needed in order to facilitate the gathering of this information. A key requirement is that information accessibility is fully controllable. The confidential information must be secure and hidden from unauthorized clients and only visible to the intended clients in a community. In order to establish trust and reputation with the participating resources, unauthorized clients need to be barred from viewing, eavesdropping, or deducing information or even being aware of the existence of another organization's involvement with a specific identifier, if the client is not authorized to be aware of this involvement. There must be a common set of data that all resources will offer (only to authorized clients). This set must be defined and agreed upon in the final protocol. This set may include answers to who, what, when, where, and why as well as links to back-end systems. An essential feature is for the protocol to be general-purpose and extensible to support multiple applications and uses beyond the needs of trade supply chains that motivated its initial development. Defining a bootstrapping procedure is a necessity when designing a global and autonomous network of systems. Bootstrapping procedure would be the process of locating on the network, the appropriate Discovery Service(s) for a specific identifier. Currently there are deployed supply chain systems that bootstrap via Internet's DNS roots. One example of this is the EPCglobal Object Name Service [epc-object-naming-services] (ONS). While ONS enables an economical means of bootstrapping, improper implementations may increase the traffic on DNS roots exponentially. Since data will be routed through the Internet, the bootstrapping procedure needs to be Rezafard Expires May 21, 2009 [Page 8] Internet-Draft ESDS Problem Statement November 2008 formulated under the IETF approval process. 1.5. Description An Extensible Supply-chain Discovery Service (ESDS) provides a mechanism to locate one or more resources of information about a specific topic such as an individual physical object. In a trade supply chain resources of information may include the original manufacturer or supplier of the object, as well as other organizations who have handled the object at some point during its lifecycle (including repair and maintenance organizations) and even organizations (such as customs or insurance agencies) who might hold information records related to the object, even though they may have never had physical custody of the object. This document defines the Problem Statement, Objectives and Technical Challenges related to the application layer protocol currently proposed as Extensible Supply-chain Discovery Services (ESDS). ESDS enables the publishing and querying of referral links to information services that historical events related to specific objects with attached object identifiers. The interface enables disparate applications to discovery resources of information and compile a consolidated view for an identifier. Primarily, ESDS provides referral services in a loosely coupled mechanism with granular security that enables selective visibility. Rezafard Expires May 21, 2009 [Page 9] Internet-Draft ESDS Problem Statement November 2008 2. Internet Concerns 2.1. Public Networks and Tree-Walking Concerns Currently, another standards body, EPCglobal, has issued a related standard referred to as ONS [epc-object-naming-services]. ONS is effectively an extended version of DNS that does not benefit from the IETF review process and, in its design, necessitates increased tree- walking. ONS specifies a reverse mapping of the EPCglobal "SGTIN" (one type of supply chain object identifier) as a hostname and allows for a reference (i.e. URL) to a manufacturer's relevant back-end system (using a NAPTR record). The SGTIN identifier is comprised of an EPC Manager Number, an Object Class, and a Serial Number. The ONS lookup excludes the Serial Number portion of the SGTIN. However, the ONS specification has already been extended in industry pilot projects to include the Serial Number, as this enables item level lookups for tagged objects in the supply chain. Using serial level lookups, ONS could be used to indicate point to point referrals through the passage of a relevant identifier throughout the supply chain. This would require successive updates to the hierarchal ONS to indicate incremental supply chain member referrals, reducing the effectiveness of caching. Alternatively the ONS could provide a single, static point of referral to the first or initiating supply chain member. However, even a relatively static entry, which only refers to the point of origin within the supply chain, would drive the number of public zone entries to extremely large numbers if an individual records were created for each serial number. The number of records could exceed the current IPv4 address space by several orders of magnitude. Also since many of the tagged physical objects would neither require nor provide network connectivity, utilizing IPv6 for such objects would waste this finite address space resource unnecessarily. One common suggestion to manage this problem is to have multiple alternate ONS roots which can be managed for separate and unrelated supply chains and/or regions. However, since there is nothing to prevent ONS from operating in the existing Internet root hierarchy, even alternate ONS providers can opt to drive traffic to the existing Internet root servers, rather than operate their own ONS roots. There has already been a pilot ONS implementation under the .aero zone (sgtin.id.ons.autoid.aero) where this phenomenon may already be observed. It should be noted that ONS 1.0 [epc-object-naming-services] currently only specifies how to perform a lookup for a GTIN class identifier, which represents a product type. It does not currently specify that ONS should be used for lookup of fully serialized identifiers. While the number of GTIN codes may be a manageable Rezafard Expires May 21, 2009 [Page 10] Internet-Draft ESDS Problem Statement November 2008 number, the potential number of serialized SGTIN identifiers is much larger. Already in EPCglobal Tag Data Standards, the structure of SGTIN identifiers are defined such that it is theoretically possible to create in excess of 10^38 unique SGTIN identifiers for each GTIN code that is currently resolvable using ONS 1.0. Already there are some companies who create over a billion objects per year for a single GTIN class. It was therefore a very wise decision of EPCglobal not to propose that ONS 1.0 should store a DNS record for each unique EPC, since the number of resulting DNS records could clearly overwhelm the DNS infrastructure. However, there is currently a missing element in the EPCglobal Network architecture, namely a search service that provides authorized authenticated clients with links to the multiple organizations who hold information about the unique life history of an individual object. This missing element is essential for enabling robust track and trace applications. Because this element ('Discovery Services') has not yet been defined, there is a danger that some organizations may misuse the ONS design and begin creating DNS records for each fully serialized object. There is already one industry pilot where this is happening. It is therefore essential that rapid progress should be made towards a protocol for Discovery Services that avoids placing such a burden on the DNS infrastructure. To summarize, there are two variations to the ONS specifications that can be observed in current deployments. The first variation is an extension to the ONS structured hostname to include serialized level data (serialized SGTIN) instead of just the specified class data (GTIN class). The second variance involves the tendency of the implementers to utilize the existing Internet root DNS servers instead of operating alternate ONS roots. These variances could adversely affect the stability of the public network infrastructure. The IESG and IAB overview procedures at the IETF will ensure that the protocol and architecture proposed by the ESDS Work Group will be mindful of such deviations and take counter steps to prevent it. 2.2. Bootstrapping Concerns The bootstrapping process enables an interested and authorized client to locate an object's Discovery Service server using only the information provided by the object identifier. Unlike DNS, where there is a known set of root servers, ESDS will have numerous roots for various communities (supply chains) operating globally. This, in turn, complicates the bootstrapping process. A common bootstrapping scenario would be exception handling in a Rezafard Expires May 21, 2009 [Page 11] Internet-Draft ESDS Problem Statement November 2008 trade supply chain. For example, if an object is mis-delivered, a recipient who has no pre-existing relationship to the trade supply chain, needs to obtain object ownership information and its corresponding Discovery Service server. ESDS design must aim to accommodate this scenario while respecting privacy and security considerations. It has been suggested that ONS could be used for the bootstrapping process. However, ONS-URN encoding and decoding scheme is only defined for EPC identifiers and ESDS is being architected to support non-EPC identifiers as well. Also, ONS's hierarchical identifiers have raised privacy and security concerns by multiple participants in some Discovery Service scenarios. While ONS can technically support multiple identifier schemes, with multiple issuing authorities, its hierarchical operation does depend on structured identifiers (for example, ManagerNumber.ObjectType.SerialNumber). These identifiers display information about the object they are representing, such as type and manufacturer and as a result could compromise the privacy of an individual using the identifier. Additionally, ONS has no authentication nor access control restricting who can query it. ESDS must be designed for serial-level lookups and must support unstructured opaque identifiers to use as lookup keys within an ESDS service. Because serial-level lookup information could potentially be subject to data mining by competitors, to reveal information about volumes and flows of goods, ESDS should fully support authentication and serial-level access controls to address concerns about privacy and confidentiality of data. To facilitate bootstrapping and exception handling scenarios ESDS design could investigate the use of peer-to-peer lookup protocols (such as JXTA [jxta-protocols]) as an alternative to hierarchical lookup protocols such as DNS and ONS. This would keep the ESDS traffic flat and avoid walking up the Internet root hierarchy. A major concern is that the bootstrapping design must not implicitly establish monopolies in the long run. The IETF process will ensure that the resulting protocol design addresses the concerns of both the end-users and the network operators. Rezafard Expires May 21, 2009 [Page 12] Internet-Draft ESDS Problem Statement November 2008 3. Other Standards Discovery Services address a problem domain that is not fully covered by any existing protocols. Discovery Services enables authorized and authenticated users, to gather and retrieve links to resources of information about a topic or an object, this information is typically fragmented across multiple organizations and domains. While there are related standards such as ONS, EPCIS, and UDDI, each of these address different problem statements and domains as follows: 3.1. Object Naming Service (ONS) ONS is a mechanism that leverages the Domain Name System (DNS) to locate sources of authoritative information and related services about a product when queried using a hostname derived from the Electronic Product Code (EPC). Its query interface as currently defined lacks access controls, authorization and authentication and this security deficiency makes it unsuitable for a Discovery Service handling commercially sensitive serial-level information. The volumes of serial-level records generated by the supply chains would place an unreasonable burden on the DNS roots if ONS were mis-used for holding ONS records for each serial number. However, Discovery Service can be used in collaboration with ONS to meet specific business requirements. [epc-object-naming-services] 3.2. EPC Information Services (EPCIS) EPCIS targets the sharing of data within an established network of trust and relationships. Typically, a company can provide an EPCIS query interface to allow trusted organizations to retrieve some of its data. It is not the role of EPCIS to enable robust linking to information across the entire supply chain or product lifecycle, nor to perform recursive 'proxy queries' to retrieve data from other parties, nor to facilitate exception handling and object bootstrapping across the whole supply chain. [epc-information-services] 3.3. Universal Description Discovery and Integration (UDDI) UDDI is a standard for description and discovery of services and the functionality that they offer. In contrast with UDDI, ESDS is concerned with locating services that provide information about a specific physical object; the ID of a physical object is the primary lookup key for ESDS, whereas UDDI is primarily queried for a particular type of service functionality desired. Unlike UDDI registries, the data held within some Discovery Services may be much more commercially sensitive. For example a supply chain Discovery Service, could reveal volumes and flows of goods in supply chains; Rezafard Expires May 21, 2009 [Page 13] Internet-Draft ESDS Problem Statement November 2008 from a security and scalability perspective, ESDS therefore attempts to solve a more challenging problem than the problem that UDDI already solves. 3.4. Interface for Metadata Access Point (IF-MAP) The protocol, IF-MAP, defines a simple publish/search/subscribe interface to the MAP. The MAP is a common metadata database. Within the MAP, metadata automatically aggregates with respect to common unique keys (i.e. identifiers). While IF-MAP's initial use-cases are in coordinated security, it was designed to meet other coordinated computing use-cases and may be appropriate for ESDS. However, IF-MAP does not provide historical information (according to section 2.2 of the IF-MAP protocol). A major use for ESDS is to maintain historical link information between the ID of a physical object (or a discussion topic or keyword) and multiple entities who have collected/ generated some information about that individual object (or discussion topic or keyword) at previous times. IF-MAP is concerned with building a graph to build associations between different identifiers and pieces of meta-data. With ESDS, the internal data model is concerned primarily with time stamped events containing associations between: - ID of object (or keyword/topic) - URL of resource that holds more detailed information - [ timestamps to help with sorting into chronological order and completeness of result sets ] - [ serviceType indicating what kind of resource to expect at the URL ] - [ other metadata that provides additional context or is helpful for defining access control policies ] Furthermore, ESDS may also need to handle an additional data model of the access control policies it is expected to enforce by the publishers of information. Authorization model is outside the scope of IF-MAP (according to the footnote 3 on p49 of the IF-MAP protocol), "3 An IF-MAP server implementation may provide an authorization model, which protects data published by one IF-MAP client from being visible to another IF- MAP client. The specifics of such an authorization model are outside the scope of this specification." The ability to enforce an authorization model based on policies defined by individual publishers is a key functional requirement for Rezafard Expires May 21, 2009 [Page 14] Internet-Draft ESDS Problem Statement November 2008 ESDS. Without this, many end-users will not publish data to it if it cannot be protected (hidden) from other end-users with whom they do not wish to share this information. In IF-MAP, the link is an un-named bi-directional binding relationship between two identifiers. (S.2.6.2 of IF-MAP protocol). In ESDS, there will be 1-many links: One entity (or information provider) may hold information about many different individual physical objects (or many different topics / keywords). One individual physical object (or topic/keyword) may be linked [via ESDS] to multiple entities that hold more detailed information fragments about it. However, in supply chain applications, resource owners may prefer that the link cannot be discovered the other way, e.g. by querying a Discovery Service with the address of a resource in order to retrieve a list of IDs of all the objects it claims to hold information about. ESDS will need to provide for such directionality restrictions on how links can be discovered. Rezafard Expires May 21, 2009 [Page 15] Internet-Draft ESDS Problem Statement November 2008 4. Related Standards Development Organizations Discovery Services is an interesting problem with significant challenges for both end-users and service providers. To tackle these challenges, the problem must be approached from both viewpoints, to ensure that the final adopted solution meets the needs of all organizations involved. The EPCglobal Data Discovery Joint Requirements Group (JRG) is in the process of gathering use cases and user requirements in order to define a Discovery Services standard which can meet the needs of supply chain participants and end-users. In a parallel and complementary effort, ESDS is addressing the technical challenges of Discovery Services, such as its deployment on public network infrastructures. The final goal is to share the lessons learned in a co-operative effort to forge a single standard protocol. ESDS is chartered to produce draft proposals for the Discovery Service protocol. Similar to the manner in which the ONS standard adopted the approach and architecture developed by the IETF DNS Work Group, it is the intention of the ESDS activity that any draft protocols developed will be useful to EPCglobal and will help to accelerate the development of an EPCglobal standard for Discovery Services. Rezafard Expires May 21, 2009 [Page 16] Internet-Draft ESDS Problem Statement November 2008 5. Objectives This section outlines the objectives of the ESDS protocol. In an effort to convey the goal of each objective, possible solutions are provided in order to trigger discussion on the subject matter. 5.1. Flow Diagrams Draft flow diagrams for a directory based model of sharing reference information. Diagram showing the publish of reference information by multiple organizations: +-------------------------------------------------------------------- + | ESDS Server | | | | Community_1 | +---------------------------------------------------------------------+ ^ ^ ^ |ESDS Record Published |ESDS Record Published |ESDS Record Published |for an individual |for an individual |for an individual |object X |object X |object X |(containing reference |(containing reference |(containing reference | to sources | to sources | to sources | of information) | of information) | of information) |Subject to access |Subject to access |Subject to access |control privileges |control privileges |control privileges | | | +------------------+ +------------------+ +------------------+ | ESDS | | ESDS | | ESDS | | Publish | | Publish | | Publish | | Client | | Client | | Client | | | | | | | | Organization_1 | | Organization_2 | | Organization_3 | +------------------+ +------------------+ +------------------+ Figure 1 Rezafard Expires May 21, 2009 [Page 17] Internet-Draft ESDS Problem Statement November 2008 Diagram showing the query client sending a request to a virtual community to retrieve list of resources for an object or topic. +------------------------------------------------+ | ESDS | | Client | | Query | | +------------------> | Organization_4 | 3. Reference +------------------------------------------------+ information is | ^ passed to other |1. ESDS Query |2. ESDS Query response applications | for an individual | for the individual to access the | object X | object X detailed | | (contains references information | | to sources | | of information) | | Subject to access v | control privileges +--------------------------------------------------------+ | ESDS Server | | | | Community_1 | +--------------------------------------------------------+ Figure 2 5.2. Security Since ESDS needs to be deployable over a public network infrastructure, issues of security and privacy are of heightened importance. Clients must be authenticated to prevent theft of information and resources must be authenticated to ensure integrity of information. The information routed over the Internet must be encrypted. It is suggested that the security model should be based on open standards, trusted by the industry. The ESDS protocol should be decoupled from the security layer and not have embedded components specific to certain security protocol implementations. This will enable ESDS implementations to respond quickly to changes in the ever advancing security layer protocols. 5.2.1. Access Control An ESDS should provide a resource with the ability to protect its link information in order to retain control over which clients are Rezafard Expires May 21, 2009 [Page 18] Internet-Draft ESDS Problem Statement November 2008 allowed to read this information. Such rules may be expressed in the form of access control policies which are evaluated against the client's authentication and authorization credentials and its role in relation to the provider of the resource, as well as other criteria such as the time elapsed since the link was published. ESDS needs to define the granularity of information at which access control policies are specified and enforced. Whether they apply to individual events as atomic indivisible entities, or they can specify which data fields to include or omit. A situation may arise where a client and the provider of a resource have no existing trust relationship with each other. An ESDS should allow a resource to specify multiple levels of 'visibility' to such a client, so that the resource either remains completely 'silent' or 'invisible', or so that an opaque handle is visible. The opaque handle should not reveal the identity of the resource in any way, but can be used to facilitate the initial negotiation between a client and a resource, such as forwarding a number of messages from the client to the provider of the resource, provided that the client specifies the handle in their message, and provided that an ESDS or associated service incorporates such a mechanism. To protect the resource provider and ESDS from additional burden, such a facility may be limited in the number of messages which are forwarded and the time window following the client's query during which forwarding of messages is offered. It is recommended that ESDS follows existing standards for defining access control policies, such as XACML. ESDS should study for the BRIDGE project work package 4 (Security) on recommendations for access control interface and protocols [bridge-network-confidentiality]. 5.3. Publish An ESDS must provide a mechanism whereby a resource can dynamically establish a link for an individual object (or list or range or class of objects) that points from the ESDS to the resource. The link can be expressed as a string or URI and it is helpful if this is accompanied by an indication of the type of service which can be accessed via the link (in order to distinguish between web pages, web services, EPC Information Services (EPCIS) and other communication mechanisms which might even include phone or fax numbers). 5.4. Query An ESDS should provide a mechanism whereby a client can query the ESDS in order to retrieve a list of links to one or more resources. Rezafard Expires May 21, 2009 [Page 19] Internet-Draft ESDS Problem Statement November 2008 Queries may be one-time queries or standing queries, and an ESDS may support either type of query, or both. The query interface needs to define the criteria fields as well as acceptable criteria values, such as regular expressions or wildcards. The ESDS Work Group should decide on whether to support multilayer information visibility. A query with limited access can be informed of the existence of information for a particular object, but to view the actual information, full access privileges would be required. This has particular implications for peer-to-peer searching across multiple Discovery Services. Another scenario to consider is whether visibility into the information in the extended fields of a published event, should be controlled independently of event information? (i.e. should access control policies be sufficiently expressive that they can grant or deny access to individual data fields within events, rather than simply granting or denying access to events) This has particular implications for tracking aggregation and disaggregation events and visibility into the entire lifecycle of an object. 5.5. Relabel/Aggregation/Disaggregation To provide complete and resilient visibility across the entire life of an object or a product, it is required that changes in identifiers are maintained in the Discovery Service layer. One scenario for relabeling can be a Discovery Service for maintenance of installed software packages. An organization with a multitude of machines, deployed anywhere on the Internet could use DS to notify machines about the availability and location of (secure and tested) updates to packages. Each machine can submit standing- queries to the DS, for all the packages that are installed on it locally. The organization operators would test and verify every new release of a package. Once a package is approved, it is placed on trusted file servers and the link to those files (and any mirror links) is published to DS along with the package name. This would result in all the machines with standing-queries to be notified of the new downloadable and verified package. Package name change is a common phenomena, specially when the version number is appended to the package name (e.g. wxWidgets libraries). So ESDS needs to provide relabeling facilities in order to be comprehensive enough to address a wide range of problem domains. Another scenario requiring the capture of aggregation and decomposition events is the regulation of the European parliament with respect to the cold supply chain regarding the tracking of fresh meat. For example, as a cow moves from a farm into the supply chain where it is finally sold as beef to a consumer at a retail store, it Rezafard Expires May 21, 2009 [Page 20] Internet-Draft ESDS Problem Statement November 2008 is vital that relabelling and disaggregation events can be stored within a Discovery Service in order to enable querying information about the entire lifecycle of the cow "from farm to fork" While having access control over visibility of these kind of events is desired, it is recommended that Discovery Services should not attempt to interpret or validate these events. It has been suggested that these complexities be excluded from the core of ESDS, instead facilitating them via the extensions mechanism and/or leaving such interpretation, validation and analysis to client applications that query ESDS. This approach must also give consideration to providing access control to the extension information. 5.6. Multiple Organizations It is the intention of ESDS to provide authorized clients with the link referral information necessary to enable client applications to gather information from multiple organizations covering an object's or a topic's lifespan. For a product this could include link data from the design phase, through manufacture, distribution and retail, usage period (including service, repair, maintenance, overhaul) and even end-of-life phase (including collection, sorting, remanufacturing and recycling). So it could be desirable to record the current phase. Also there may exist lifecycle steps within a particular phase, a higher perspective or meta view could show that entire phase as a single step in the life of the product. For example, a product can be in a Manufacturing supply chain, then move into a Logistics supply chain, followed by a Service supply chain. Each of these particular supply chains may have their own set of lifecycle steps, but the entire lifecycle is spread across all three supply chains. ESDS should facilitate the linking of these supply chains and phases together to enable the capture of the entire lifecycle of the object. 5.7. Identifier Agnostic To enable the grouping of information belonging to the same object, each object needs to be uniquely identifiable. Information about the object is held by a number of independent organizations that agree to use a shared identifier schema. These identifier schemas are defined and distributed by numbering authorities in each industry sector. Some numbering authorizes guarantee global uniqueness of the issued identifiers, but this is not the case all the time. Especially when there exists issued legacy numbers currently in use within the domain of a numbering authority. Also there are cases were numbering authorities for different domains have collisions in their space of issued identifiers (e.g. Animal Identification Number (AIN), National Stock Numbers (NSN), and the International Mobile Equipment Identity (IMEI) are all 15 digit identities and there are collisions Rezafard Expires May 21, 2009 [Page 21] Internet-Draft ESDS Problem Statement November 2008 in the space of issued identities.). There are procedures for converting identifiers to URIs which can also assure that the URI is globally unique. However although global uniqueness of identifiers is highly desirable for use within a co- operating federation of Discovery Services, it is not a requirement for each individual instance of a Discovery Service, and it would be out of scope for a Discovery Service to verify global uniqueness for identifiers used. To define a protocol which is applicable to all scenarios, it is essential that the protocol supports various numbering authorities. The ESDS protocol should have a broad scope and support multiple identifier schemes including schemas with non-unique identifiers. The intelligent handling of identifier associated with an object is out of scope of Discovery Services and can be handled accordingly by ESDS query applications. It must also be identifier agnostic in order for Discovery Services to be embraced by all potential adopters. 5.7.1. Reusing Identifiers There are scenarios where the same object (and its identifier) is used within a Discovery Service but in different sessions or phases. It could be the case that the authorization and access control policies differ based on attributes such as timestamps, or metadata. An identifier reuse scenario can be for reusable assets and other returnable transport items that may circulate among multiple organizations - and in many situations, it may be more economical and more feasible to tag the reusable asset than to tag its contents. This is particularly true when attaching not only a unique ID tag but also environmental sensors to the reusable asset. Company A that provides and manages reusable assets can provide an additional service to its customers, such as company B (which borrows or leases an asset from company A), by allowing company B to access data about the asset while it carries the products from company B. At the same time, there are benefits to company A in being able to track its own assets, to balance supply and demand of assets and detect when assets are not being returned correctly, e.g. for cleaning and repair. However, it is also very important to protect the confidentiality of the data for company B from its competitor, company C, who may happen to use the same asset at a later time. One possible solution to this is for company A to dynamically manage access permissions to data about the asset and its contents using Rezafard Expires May 21, 2009 [Page 22] Internet-Draft ESDS Problem Statement November 2008 time-based windows that provide its customers with visibility only to data about the asset during the time periods when it is associated with their products or their lease/use of the asset. This could be achieved by appending additional time-based constraint qualifications to access control policies. For example, company B could be granted visibility to track and trace data about the asset for events that occur after they take custody of the asset and before they relinquish custody of the asset. Company C might be granted access for a different time window. There should be no overlap between the time windows granted to competing companies, in order to protect the confidentiality of their data. 5.8. Extensible The event data needs to accommodate various scenarios and their business requirements. Therefore it must be an extensible protocol which enables the collaborating organizations to communicate messages specific to their industry and terminology. An ESDS protocol should enable the sharing of information without involving the business rules of various scenarios. This will keep the interface clean and uniform across all scenarios and ESDS services. ESDS should give consideration to approaches for dealing with access control and visibility of extended information and protocols. One approach could be to provide one level of access to all the event information, whereby if a client can access an event information, it can retrieve the extended information. Another approach could be to provide multilayer visibility, where only clients with proper privileges can retrieve the extended information. 5.9. Policies The Retention policy for data records in ESDS would vary based on the business and regulatory requirements. Some scenarios would need retention of only few days and some would require retention for 30 years. Some other policies with similar parameters but different interpretation are the archiving policies, purging policies, and audit policies. 5.10. Stale Links There are situations where the link information (such as a URL) that was originally specified is no longer effective (e.g. because the provider of the resource has not taken care to maintain redirection Rezafard Expires May 21, 2009 [Page 23] Internet-Draft ESDS Problem Statement November 2008 from the original link address to the new location of the resource when restructuring a website or moving to a different domain name). In such situations, it is desirable that a Discovery Service could provide a client with link information that is current and effective. For audit purposes, it may also be necessary for an ESDS to be able to retain and reconstruct the original (or previous) link information, even if it is no longer effective. This may also imply that an ESDS should allow a resource provider to loosely couple the link record with the current link address, to ease migration of multiple records to a new resource address, while still providing a mechanism to recover a full audit trail of such changes of link addresses. This is particularly important when the link records are digitally signed and we wish to avoid having to "void" such records merely because they embedded a URL which is no longer in service. 5.11. Peer-to-Peer Communications Architecting a bootstrapping policy will involve defining a protocol for peer-to-peer communication between Discovery Services (DS). The ultimate goal is to locate the target DS without dependence on hierarchical information and services such as ONS or the underlying DNS. To facilitate the peer-to-peer communication it is recommended that existing protocols and proven architectures such as JXTA [jxta-protocols] be utilized. Another candidate architecture is ECRIT's approach to locating authoritative sources of information in a peer-topeer network [ecrit-mapping-arc]. One point to keep in mind with DSs is that finding one target DS does not mean that the search is over. One object identifier could be acceptable to many DSs; therefore a search cannot stop once a DS is located but needs to propagate to all peers. Care and consideration must be given to privacy and the sensitivity of information at the DS nodes. It is also critical that steps are taken to protect against increased vulnerabilities that the extra exposure that P2P brings, such as denial-of-service attacks, or data mining tricks. Another challenge is when the target DS is successfully located. How much information on an object inquiry can that DS share with the peer DS, without jeopardizing security and privacy? Should the DSs facilitate the peer-to-peer access negotiation process or should it be done by the Certificate Authority? A sample scenario would be a query client negotiating for access to information from an organization where the information-providing Rezafard Expires May 21, 2009 [Page 24] Internet-Draft ESDS Problem Statement November 2008 organization does not have an established business (trust) relationship with the client and therefore chooses initially not to reveal its identity to the client. In this case, it is possbile to use the opaque 'node ref' concept and perhaps each object can have such a 'node ref' handle to deal with such scenarios [bridge-discovery-services-design]. Considerations must be given to protection against data mining to discovery whether a serial number exists or has been issued. Rezafard Expires May 21, 2009 [Page 25] Internet-Draft ESDS Problem Statement November 2008 6. Technical Challenges ESDS should be purely an application layer protocol disassociated from implementation specifics and challenges. Below are some of the technical challenges that certain business requirements demand. However ESDS is not chartered to address these implementation challenges. 6.1. Auditability Based on some business and regulatory requirements, auditing capabilities should be facilitated by ESDS to provide accountability if and when something goes wrong. With an auditing mechanism, record data can be tracked and the person responsible identified, thus a series of data records can be reconstructed at a later date, allowing the Discovery Service operators to prove who was responsible for which data records [bridge-security-analysis]. 6.2. Responsiveness ESDS implementations will need to be designed to accept updates in a close to real time basis from multiple providers of information across the globe. Because they store serial-level records, they will need to be sufficiently scalable to store large volumes of data, possibly up to trillions of records per year. 6.3. Availability ESDS availability requirements would vary from business case to business case. Research by BRIDGE shows that the uptime requirements for some supply chain business cases are 99.99% year round. It is expected that the ESDS instances will be available over a shared network that exposes them to the effects of network attacks. Furthermore, in many cases it is expected that these components should be globally reachable from the Internet and not hosted on a secure private network. Such components are also built using commonly available Operating Systems and middleware (e.g. Application Servers). Thus they are also subject to any vulnerabilities of these supporting systems. A major security issue for shared services such as the ESDS is service availability. In particular if services are considered to be vital for businesses and organizations (e.g. "pharma e-Pedigree" or "product-authentication") ESDS needs to be able to guarantee minimal amount of service downtime due to security vulnerabilities and attacks [bridge-security-analysis]. Rezafard Expires May 21, 2009 [Page 26] Internet-Draft ESDS Problem Statement November 2008 7. Related Activities Currently, the standards organization EPCglobal, and EU research projects BRIDGE, SMART, and PROMISE are looking into the global supply chain track-and-trace challenge. As part of their research, each of them has identified the need for Discovery Services to link resources and clients in the supply chains. EPCglobal is beginning to gather user requirements for Discovery Services. However, EPCglobal is a paid membership organization focused on serving their own subscriber community. Although the final ratified EPCglobal standards are open and freely available to download, the subscription fees for joining the EPCglobal community may deter a significant proportion of the end-user community from directly participating in the development of their global standards. IETF would be the ideal body to oversee the development of this protocol because of its deep knowledge of Internet infrastructure and experience with development of application layer protocols. An IETF working group would be an inviting and open community which facilitates contribution and participation of all interested parties involved in the global supply chain as well as other potential industries with organizations enthusiastic about the benefits of collaboration with each other. The output would be released as a freely available RFC in the public domain. ESDS will make best efforts to ensure good communication with complementary activities at EPCglobal, in order to ensure that the output of ESDS is as relevant and useful as possible to a future EPCglobal standard for Discovery Services. Rezafard Expires May 21, 2009 [Page 27] Internet-Draft ESDS Problem Statement November 2008 8. Acknowledgements This document and the process of authoring was made possible by the excellent xml2rfc tool [RFC2629]. Credit must also be given to Scott Hollenbeck author of [RFC4930] for the organization and grouping of RFC sections. Rezafard Expires May 21, 2009 [Page 28] Internet-Draft ESDS Problem Statement November 2008 9. Contributors Dr. Mark Harrison Senior Research Associate, Distributed Information and Automation Laboratory Director, Auto-ID Labs at Cambridge Institute for Manufacturing University of Cambridge Mill Lane Cambridge, UK CB2 1RX Phone: +44-(0)1223-338178 Email: mark.harrison@cantab.net Michael Young Senior Director, Technology Afilias Canada 204-4141 Yonge Street Toronto, ON M2P 2A8 CA Phone: +1-416-646-3304 Email: myoung@ca.afilias.info Rezafard Expires May 21, 2009 [Page 29] Internet-Draft ESDS Problem Statement November 2008 10. IANA Considerations This document has no actions for IANA. Rezafard Expires May 21, 2009 [Page 30] Internet-Draft ESDS Problem Statement November 2008 11. Security Considerations This document is a problem statement that does not by itself introduce any security issues. Rezafard Expires May 21, 2009 [Page 31] Internet-Draft ESDS Problem Statement November 2008 12. References 12.1. Normative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 4930, May 2007. 12.2. Informative References [bridge-discovery-services-design] BRIDGE, "BRIDGE WP02 High-level design for Discovery Services", August 2007. [bridge-network-confidentiality] BRIDGE, "BRIDGE WP04 Security Analysis Report: RFID Network Confidentiality (D 4.5.1)", December 2007. [bridge-security-analysis] BRIDGE, "BRIDGE WP04 Security Analysis Report", July 2007. [bridge-serial-level-lookup-requirements] BRIDGE, "BRIDGE WP02 Serial Level Lookup Requirements", August 2007. [draft-thompson-esds-commands] Thompson, F., "Extensible Supply-chain Discovery Service Commands (work in progress)", February 2008. [draft-thompson-esds-schema] Thompson, F., "Extensible Supply-chain Discovery Service Schema (work in progress)", February 2008. [ecrit-mapping-arc] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", September 2007. [epc-information-services] EPCglobal Information Services Work Group, "EPCglobal Information Services", September 2007. [epc-object-naming-services] EPCglobal, "Object Naming Service 1.0", October 2005. [epcglobal-tds] EPCglobal Tag Data Standard Work Group, "EPC Tag Data Rezafard Expires May 21, 2009 [Page 32] Internet-Draft ESDS Problem Statement November 2008 Standard Standard", March 2006. [jxta-protocols] Duigou, M., "JXTA v2.0 Protocols Specification", June 2004. Rezafard Expires May 21, 2009 [Page 33] Internet-Draft ESDS Problem Statement November 2008 Author's Address Ali Rezafard Afilias Canada 204-4141 Yonge Street Toronto, ON M2P 2A8 CA Phone: +1-416-646-3304 Email: arezafar@ca.afilias.info Rezafard Expires May 21, 2009 [Page 34] Internet-Draft ESDS Problem Statement November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Rezafard Expires May 21, 2009 [Page 35]