Network Working Group M. Young Internet-Draft Afilias Canada Intended status: Informational October 30, 2007 Expires: April 30, 2008 Extensible Supply-chain Discovery Service Concepts draft-young-esds-concepts-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 April 30, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Young Expires April 30, 2008 [Page 1] Internet-Draft ESDS Concepts October 2007 Abstract This document is intended to seed discussion about the Extensible Supply-chain Discovery Service (ESDS), an application layer protocol for the distributed sharing and discovery of notification events between associated partners within a supply chain. Specified initially as a web service interface, the protocol defines event tracking and tracing operations as well as core object management operations. This document obsoletes "Extensible Supply-chain Discovery Service Concepts draft-young-esds-concepts-02". 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Public Networks and Tree-Walking Concerns . . . . . . . . 4 1.2.1. Security and Privacy Concepts . . . . . . . . . . . . . . 5 1.3. Conventions Used In This Document . . . . . . . . . . . . 5 2. Protocol Objects . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. SupplyChain . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Partner . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. User . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Role . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Young Expires April 30, 2008 [Page 2] Internet-Draft ESDS Concepts October 2007 1. Introduction This document describes the concepts related to the application layer protocol called the Extensible Supply-chain Discovery Service (ESDS). The ESDS captures and queries historical events related to specific objects with attached object identifiers, such as those programmed into RFID (radio frequency identifier) tags. The interface enables disparate applications to track and trace shared life cycle views of object identifiers across a supply chain. Additionally, the ESDS provides referral services in a loosely coupled mechanism with granular security that enables selective visibility. An object identifier represents an object (or a group of objects) that exists or has previously existed within a supply chain. Each object identifier has a life cycle defined by a set of events and associated services for those events. Each event includes a timestamp that enables a historical view of events over time. These events are posted by supply chain partners to the ESDS with set security policies, enabling other selected partners to view the posted events. There are two event storage types, persistent and transient. Transient event storage implies publish and subscribe or "push" mechanisms to deliver events to supply chain partners. Persistent event storage allows both publish and subscribe or "push" mechanisms as well as request/response lookup queries either standing or on demand. Each event contains a minimal amount of related business information and an optional set of service endpoints reference pointers. The service endpoint reference pointers contain uniform resource locators. In the case that a posting supply chain partner has additional detail data available about the associated event, these URLs resolve to the supply chain partner's detail provisioning system. The ESDS is agnostic to both the object identifier type and string syntax, thus supporting a wide base of identifier representations. An example of an object identifier could be an RFID EPC (Electronic Product Code) in EPCglobal TDS (Tag Data Standard) URI notation TDS 1.3 [TDS 1.3]. For details and examples of the operation interface of the ESDS protocol, see Extensible Supply-chain Discovery Service Schema [draft-thompson-esds-commands]. Extensible Supply-chain Discovery Service Schema [draft-thompson-esds-schema] details the schema for the ESDS, which is specified in Web Service Description Language (WSDL) and XML Schema (XSD). Young Expires April 30, 2008 [Page 3] Internet-Draft ESDS Concepts October 2007 1.1. Background Supply chain communication traffic over the Internet is in common use for B2B (business to business). Data exchange has traditionally 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 exchange within the supply chain. While this one way method is effective in very static supply chain relationships, its main drawback lies in dynamic routing 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. With the advent of RFID tags as a catalyst, a desire to reverse- lookup the object information is evolving. 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 gates in the supply chain, a referral service must be available to match the object's identifier to either a relevant supply chain partner or a list of relevant supply chain partners and the available data services these partners may offer to a requestor. This enables supply chains to route flexibly and handle exceptions. 1.2. Public Networks and Tree-Walking Concerns Currently another standards body, EPCglobal, has issued a related standard referred to as ONS (Object Naming Service, 1.0). ONS is effectively an extended version of DNS that does not benefit from the IETF review process and, by design, necessitates increased tree- walking. ONS specifies a reverse mapping of the EPCglobal "SGTIN" as a domain 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 a 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 Young Expires April 30, 2008 [Page 4] Internet-Draft ESDS Concepts October 2007 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. One common suggestion to manage this problem is that multiple alternate ONS roots 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. Already there has been a pilot ONS implementation under the .aero zone (sgtin.id.ons.autoid.aero) where this can be observed. ESDS seeks to prevent this problem by keeping most of the network traffic off the Internet root hierarchy. It provides a relatively flat, authenticated lookup system that is incrementally updatable by its known participants. Unlike ONS, the ESDS has the ability to store and answer queries about incremental events and their referrals, providing a view to the entire supply chain, not just a stateful referral. ONS still comes into play, but only as an exception process. In the rare event where no relevant event records about an object have been posted through the ESDS, an interested supply chain partner can then do a subsequent ONS lookup for a referral to the start of a given supply chain. In conjunction with the use of the ESDS,the ONS becomes a secondary, not a primary use lookup resolving the traffic concerns against the root hierarchy. 1.2.1. Security and Privacy Concepts. ONS raises 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 leak information about products such as type and manufacturer and as a result could compromise the privacy of an individual transporting them. Additionally, ONS has no authentication or access control. ESDS is designed for serial level lookups and supports unstructured opaque identifiers which can be used as lookup keys within an ESDS service. It fully supports authentication and object level access controls and therefore can address privacy concerns. 1.3. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Young Expires April 30, 2008 [Page 5] Internet-Draft ESDS Concepts October 2007 2. Protocol Objects The ESDS defines the following protocol objects in order to provide the granular permission system that grants access to business event data generated in the process of tracking objects and services in a supply chain. A supply chain represents a group of partners that will be sharing event information generated within that group. Partners grant or deny access to event data by assigning roles to particular users associated with partners in the supply chain. The following protocol objects are described in more detail below: SupplyChain, Partner, User, Role, and Event. 2.1. SupplyChain A supply chain is a logical group of partners that can share business event data generated within the group. A partner's data can be made visible to other partners in the supply chain based on the access rules defined in the Security Considerations section of this document. An ESDS interface can provide access to multiple supply chains. 2.2. Partner A partner is a business entity whose computer systems or employees may post events associated with a supply chain via an authenticated user. Partners may inquire about events posted to any one of the supply chains they are members of, but will only receive results for events they are authorized to access. A partner may belong to more than one supply chain and can create and set policies for a given supply chain they have initiated. Policy can be set at multiple levels of the ESDS, for example server policy can set membership limitations in any defined supply chain, or the events posted in a defined supply chain, policy can also be set by the initiator of the supply chain on membership and event posting, and individual policy can be set by a partner against a particular event they post within a supply chain. Policy is server enforced, not ESDS protocol enforced. 2.3. User Each agent associated with a partner is called a user, which may represent either a computer system or a person that acts on behalf of the partner. A user is assigned a role that dictates what operations the user may invoke. The ESDS may require partners to provide different access credentials for each user that connects to the discovery service. When a partner's computer system initiates a connection to the ESDS on behalf of a person, that system must solicit the person's access credentials and provide them to the ESDS. A user can belong to only one partner. Young Expires April 30, 2008 [Page 6] Internet-Draft ESDS Concepts October 2007 2.4. Role A role is an object used to define the permissions that are to be assigned to a user for the duration of an authenticated session. A user MUST have exactly one role assigned to it. 2.5. Event An event represents a new step in the life cycle of a tracked object or service. It carries two time stamps, one which indicates the instant at which the event was generated by the client system and one that indicates when the event was injected into the ESDS. There are two types of events: o An object event is captured when the system records a new life cycle step for an object bearing a given object identifier. The event consists of a supply chain specific life cycle step identifier. o A void event amends a specific event to indicate that the event was posted in error. 3. IANA Considerations This document has no actions for IANA. 4. Security Considerations This RFC raises no security issues because of its conceptual nature. Security considerations related to the ESDS interface operations can be found in Extensible Supply-chain Discovery Service Commands[draft-thompson-esds-commands]. Young Expires April 30, 2008 [Page 7] Internet-Draft ESDS Concepts October 2007 5. Glossary EPC - Electronic Product Code - A globally unique, standardized identifier designed to enable automatic identification of objects. EPCglobal - A standards body for the EPC that supports the use of RFID. RFID - Radio Frequency Identification - A method of automatic identification that includes storing data on devices called RFID tags or transponders, and remotely retrieving that data with specialized readers. TDS - Tag Data Standards - defines the different EPC identifier formats, together with their binary and URI representations and encoding/decoding rules. Pure-identity URI notation for an EPC - the standard or canonical representation of an EPC that should be used especially for inter-organizational information exchanges. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [TDS1.3] EPCglobal Tag Data Standards v1.3, 8 March 2006. http://www.epcglobalinc.org/standards/tds [draft-thompson-esds-commands] Thompson, F., "Extensible Supply-chain Discovery Service Commands (work in progress)", April 2007. [draft-thompson-esds-schema] Thompson, F., "Extensible Supply-chain Discovery Service Schema (work in progress)", April 2007. Young Expires April 30, 2008 [Page 08] Internet-Draft ESDS Concepts October 2007 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [TDS1.3] EPCglobal Tag Data Standards v1.3, 8 March 2006. http://www.epcglobalinc.org/standards/tds [draft-thompson-esds-commands] Thompson, F., "Extensible Supply-chain Discovery Service Commands (work in progress)", April 3007. [draft-thompson-esds-schema] Thompson, F., "Extensible Supply-chain Discovery Service Schema (work in progress)", April 3007. Author's Address Michael Young Afilias Canada 204-4141 Yonge Street Toronto, ON M2P 2A8 CA Phone: +1.416.646.3304 Email: myoung@ca.afilias.info Young Expires April 30, 2008 [Page 09] Internet-Draft ESDS Concepts October 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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). Young Expires April 30, 2008 [Page 10]