Extensible Supply-chain Discovery Service Problem Statement
draft-rezafard-esds-problem-statement-01

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 August 28, 2008.

Abstract

This document discusses the requirements of an application layer protocol which can meet the needs of today's complex and dynamic supply chains. Currently, supply chain communication traffic travels over the Internet using existing Internet protocols, such as FTP, SMTP, and DNS. This is a temporary solution for a growing niche. This document elaborates on issues that would arise if this trend continues. Also, this document outlines a set of design concerns that an application layer protocol needs to address in order to be deployable in a real-world supply chain.

This document obsoletes "Extensible Supply-chain Discovery Service Problem Statement draft-rezafard-esds-problem-statement-00".

Comments are solicited and should be addressed to the mailing list at esds@ietf.org and/or the author(s).

Table of Contents

1.  Introduction
    1.1.  Background
    1.2.  Terminology
    1.3.  Problem Statement
    1.4.  Description
2.  Internet Concerns
    2.1.  Public Networks and Tree-Walking Concerns
    2.2.  Bootstrapping Concerns
3.  Other Standards
    3.1.  Object Naming Service (ONS)
    3.2.  EPC Information Services (EPCIS)
    3.3.  Universal Description Discovery and Integration (UDDI)
4.  Related Standards Development Organizations
5.  Objectives
    5.1.  Security
        5.1.1.  Access Control
    5.2.  Independence
    5.3.  Publish
    5.4.  Query
    5.5.  Relabel/Aggregation/Disaggregation
    5.6.  Lifecycle
    5.7.  Multiple Organizations
    5.8.  Identifier Agnostic
        5.8.1.  Reusing Identifiers
    5.9.  Extensible
    5.10.  Retention Policy
    5.11.  Stale Links
    5.12.  Peer-to-Peer Communications
6.  Technical Challenges
    6.1.  Auditability
    6.2.  Responsiveness
    6.3.  Availability
7.  Related Activities
8.  Acknowledgements
9.  Contributors
10.  IANA Considerations
11.  Security Considerations
12.  References
    12.1.  Normative References
    12.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

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, 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. exchanging 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. 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.

At a conceptual level, Discovery Services can be superficially regarded as being somewhat analogous to a '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 partners, 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 an event or record for a particular unique ID, 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 which 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 authentication, although citizens may be provided access to traceability information via an authorized authenticated actor, such as the retailer or manufacturer.

This approach enables distributed management of lifecycle data 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 service that holds the more detailed event data.

1.1.  Background

Traditionally supply chain communication has been routed over private network infrastructures. However in recent years this practice is abandoned in favour of communication over public networks. The communication and data exchange has taken the form of flat file data exchange, XML, and other proprietary forms across existing mechanisms, such as SFTP and SMTP. This method of exchange requires bilateral agreements and networking arrangements amongst all partners of a given supply chain. In this model, information sharing begins with the supply chain partner who provides lists of the objects (shipping manifest) that the other partners can expect to receive and exchange within the supply chain. While this one way method is effective in very static supply chain relationships, its main drawback lies in its inability to support dynamic routing of physical objects and, therefore, exception handling. For example, if an object arrived at supply chain partner C without prior notification from supply chain partner B or A, the product remains unidentified and not routable.

The advent of Radio Frequency Identification (RFID) tags has been a catalyst for the desire to reverse-lookup object information. Products are being tagged with RFID tags, traditional barcodes, and other types of proprietary object identifiers. The exchange of information now begins with the object and leads back to the supply chain partner. As the object is scanned at various key locations in the supply chain, a referral service must be available to match the object's identifier either to a relevant supply chain partner or to a list of relevant supply chain partners and the data services that these partners offer to a requestor. This enables supply chains to route flexibly and handle exceptions.

1.2.  Terminology

There are three actors in this problem:

Client:

refers to an actor that seeks (sources of) information about an individual object.

Resource:

refers to an actor that holds information about an individual object and may provide it to authenticated clients who satisfy some authorization criteria (access control policies and rules).

ESDS:

refers to an intermediary lookup service that enables a client to locate one or more resources.

What emerges from combinations of these actors and their relationships are:

Partner:

refers to a business entity which is comprised of Client and Resource actors belonging to an organization.

Supply chain:

refers to a group of partners that have the desire to share information among themselves.

1.3.  Problem Statement

Information sharing between partners is essential for all modern supply chain networks. There is a strict set of business and technical requirements that must be observed in order to enable open sharing of information in a supply chain.

There are resources and clients in each supply chain. Each resource wants to advertise its knowledge (data) to interested and authorized clients. Only deploying private networks to connect whole supply chains is no longer feasible, as the more efficient and economical means of connecting resources and clients is to use public network infrastructure. Currently, many supply chain 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 in the supply chain is that data ownership must be respected. This means that each partner can collect information within their organization and is not required to route that information to any other partner. However, they can choose to share selected information with other trusted partners. This in turn means that the complete lifecycle information about any individual object may be held by multiple resources throughout the supply chain or the product lifecycle. 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 supply chain. In order to establish trust and reputation with the participating resources, unauthorized clients need to be barred from viewing, eavesdropping, or deducing information.

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 extensible beyond the common data set to facilitate the needs of supply chains that discover additional uses.

Defining a bootstrapping procedure is a necessity when designing a global and autonomous network of systems. 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] (EPCglobal, “Object Naming Service 1.0,” October 2005.) (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 formulated under the IETF approval process.

1.4.  Description

An Extensible Supply-chain Discovery Service (ESDS) provides a mechanism to locate one or more sources of information about an individual physical object. This 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 track-and-trace shared lifecycle views of object identifiers across a supply chain. Primarily, ESDS provides referral services in a loosely coupled mechanism with granular security that enables selective visibility.

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] (EPCglobal, “Object Naming Service 1.0,” October 2005.). 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 partner referrals, reducing the effectiveness of caching. Alternatively the ONS could provide a single, static point of referral to the first or initiating supply chain partner. 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 record 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] (EPCglobal, “Object Naming Service 1.0,” October 2005.) 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 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 variances to the ONS specifications that can be observed in current deployments. The first variance is an extension to the ONS structure 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

Currently there are discussions on how to best facilitate a bootstrapping processes for objects in the supply chain. 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 supply chains operating globally. This, in turn, complicates the bootstrapping process.

A common bootstrapping scenario is exception handling. For example, if an object is mis-delivered, a recipient who has no pre-existing relationship to the 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's hierarchical identifiers have raised privacy and security concerns by multiple participants in the supply chain. 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 products such as type and manufacturer and as a result could compromise the privacy of an individual carrying them, as well as the security of transportation within supply chains. 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] (Duigou, M., “JXTA v2.0 Protocols Specification,” June 2004.)) 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 all participants in the global supply chain.

3.  Other Standards

Discovery Services addresses a problem domain that is not covered by any existing protocols. Discovery Services enables authorized and authenticated users, to gather and retrieve links to all providers of lifecycle information about an object, this information is typically fragmented across the whole supply chain. 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] (EPCglobal, “Object Naming Service 1.0,” October 2005.)

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 partners 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] (EPCglobal Information Services Work Group, “EPCglobal Information Services,” September 2007.)

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 ESDS may be much more commercially sensitive because it could reveal volumes and flows of goods in supply chains; from a security and scalability perspective, ESDS therefore attempts to solve a more challenging problem than the problem that UDDI already solves.

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.

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.  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 supply chain 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.1.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 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 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 created.

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 wait for the BRIDGE project work package 4 (Security) on recommendations for access control interface and protocols.

5.2.  Independence

In today's morphing supply chains there will always be resources that cannot or will not participate in track-and-trace efforts. If a resource in a supply chain chooses not to participate, the protocol architecture needs to be tolerant of this missing link in the supply chain. The only acceptable consequence of a non-participating resource would be to miss the information that would have been supplied had it participated.

One of the problems with relying on 'following the chain' from the manufacturer to the current downstream custodian of the object is that there could be a broken link in the chain if one of the organizations does not provide an onward link - or if their information service is temporarily (or permanently) unavailable. A Discovery Service should provide some resilience to ensure that, it is always possible to 'navigate beyond a broken link' to find who currently has the object.

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. 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 a product, it is required that events involving object identifier changes can be held in the Discovery Service layer.

One 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 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.  Lifecycle

As an object moves through the supply chain, it produces events of interest. The same event on the same object may take on a different meaning depending on the lifecycle step of the object. These events would be more useful to the interested partners if they conveyed some information about the lifecycle step of the object being tracked. Lifecycle step definitions and transitions can be different across various industry sectors. The lifecycle step could convey information about the state of an object in the supply chain. The lifecycle defined by a supply chain could enable intelligent interpretation and validation of events by a partner's Business Application.

It is strongly suggested that detection of exception scenarios does not belong within the scope of ESDS. This intelligence should reside outside of the Discovery Service layer and in the supply chain's Business Applications.

5.7.  Multiple Organizations

It is ESDS's intention to provide authorized clients with the link referral information necessary to enable client applications to gather information covering the entire life of a product. This would 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 while there may exist lifecycle steps within a particular supply chain, a higher perspective or meta view could show that entire supply chain as a single step in the life of the product. For example, an object 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 together to enable the capture of the entire lifecycle of the object.

5.8.  Identifier Agnostic

To enable the grouping of information belonging to the same object, each object needs to be uniquely identifiable as it moves through the supply chain and its lifecycle steps. The protocol cannot safely rely on unique object identifiers alone, because an identifier may enter the supply chain multiple times. A sample use case for this is returnable bins, where the same bin will go through the supply chain many times. Another use case is airline baggage, where the same baggage identifier could appear the following year, due to the fact that the identifier is only required to include a Julian date (the day of the year) but is not required to include the year.

To define a protocol which is adoptable by the various supply chains, it is essential that the protocol support various identifier schemes. The ESDS protocol should have a broad scope and support multiple identifier schemes including schemas with non-unique identifiers. It must also be identifier agnostic in order for Discovery Services to be embraced by global supply chains.

5.8.1.  Reusing Identifiers

Reusable assets and other returnable transport items 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 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.9.  Extensible

The event data needs to accommodate various supply chains and their business requirements. Therefore it must be an extensible protocol which enables the partners to communicate messages specific to their group and supply chain.

An ESDS protocol should enable the sharing of information without involving the business rules of supply chains. This will keep the interface clean and uniform across all supply chains 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.10.  Retention Policy

The retention time for data records in ESDS would vary based on the supply chain's business and regulatory requirements.

• For tracking of shipments, the records might only need to be stored while the shipment is in transit and has not yet reached its final customer (e.g. a few days to a few weeks)
• For some objects (e.g. consumer goods/retail sector), the primary interest may be tracking from manufacturer to point of sale (e.g. a few days to a few months)
• In some sectors (e.g. pharmaceuticals), regulatory guidelines may require records to be retained for several years beyond the point of dispensing.
• In other sectors (e.g. aerospace parts), the lifecycle up to the point of delivery is only the initial phase of the lifecycle of the part - and there may be significant interest in tracking the part (and its sequence of custodians and information providers) throughout its active service life, which can be up to 30 years for some parts.

Some other policies with similar parameters but different interpretation are the archiving policies, purging policies, and audit policies.

The ESDS protocol needs to facilitate the definition and customization of such policies within the supply chains.

5.11.  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 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 an ESDS can 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 or event with the current link address, to ease migration of multiple records to a new link 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.12.  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] (Duigou, M., “JXTA v2.0 Protocols Specification,” June 2004.) be utilized. Another candidate architecture is ECRIT's approach to locating authoritative sources of information in a peer-topeer network [ecrit‑mapping‑arc] (Schulzrinne, H., “Location-to-URL Mapping Architecture and Framework,” September 2007.).

One point to keep in mind with DSs is that finding one target DS does not mean that the search is over. One product 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 PTP 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 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] (BRIDGE, “BRIDGE WP02 High-level design for Discovery Services,” August 2007.). Considerations must be given to protection against data mining to discovery whether a serial number exists.

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 supply chain 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 supply chain to prove who was responsible for which data records [bridge‑security‑analysis] (BRIDGE, “BRIDGE WP04 Security Analysis Report,” July 2007.).

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 supply chain or lifecycle of an object. 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 supply chain to supply chain. Research by BRIDGE shows that the uptime requirements for some supply chains 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 or ONS is service availability. In particular if you consider services that are vital for supply chain processes (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] (BRIDGE, “BRIDGE WP04 Security Analysis Report,” July 2007.).

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 global supply chain 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. Unlike an EPCglobal work group, there would be no economic barriers to participation in the development of the technical standard. 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.

8.  Acknowledgements

This document and the process of authoring was made possible by the excellent xml2rfc tool [RFC2629] (Rose, M., “Writing I-Ds and RFCs using XML,” June 1999.). Credit must also be given to Scott Hollenbeck author of [RFC4930] (Hollenbeck, S., “Extensible Provisioning Protocol (EPP),” May 2007.) for the organization and grouping of RFC sections.

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

10.  IANA Considerations

This document has no actions for IANA.

11.  Security Considerations

This document is a problem statement that does not by itself introduce any security issues.

12.  References

12.1. Normative References

12.2. Informative References

Author's Address

Full Copyright Statement

Copyright © 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.