Network Working Group M. Young Internet-Draft Afilias Canada Intended status: Informational April 11, 2007 Expires: October 13, 2007 Extensible Supply-chain Discovery Service Concepts draft-young-esds-concepts-00 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 October 13, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Young Expires October 13, 2007 [Page 1] Internet-Draft ESDS Concepts April 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 as a web service interface, the protocol defines event tracking and tracing operations as well as core object management operations. Comments are solicited and should be addressed to the mailing list at esds-protocol@afilias.info and/or the author(s). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Public Networks and Tree-Walking Concerns . . . . . . . . 4 1.3. Conventions Used In This Document . . . . . . . . . . . . 4 2. Protocol Objects . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. SupplyChain . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Partner . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. User . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Role . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Young Expires October 13, 2007 [Page 2] Internet-Draft ESDS Concepts April 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. 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 TDT (Tag Data Translation) URI notation TDT1.0 [TDT1.0]. 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). 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. Young Expires October 13, 2007 [Page 3] Internet-Draft ESDS Concepts April 2007 With the advent of RFID tags as a catalyst, a desire to reverse- lookup the object information is evolving. Products are being tagged with RFIDs, 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 draft standard referred to as ONS (Object Naming Service). ONS is effectively an extended version of DNS that does not benefit from the IETF process and, by design, necessitates increased tree-walking. As a stateful and unauthenticated service, the hierarchal ONS would need to be constantly updated to indicate incremental supply chain partner referrals, reducing the effectiveness of caching. Even a relatively static entry, which could only refer to the point of origin within the supply chain, would drive the number of public zone entries to extremely large numbers. Although EPCglobal has offered an alternate root system to assist with this problem, cost incentives are such that implementers will almost certainly use the Internet. 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. ONS still comes into play, but only as an exception process. Should no relevant event records to an object be posted through the ESDS, then a subsequent lookup to ONS could provide a referral to the start of a given supply chain. However, now the ONS becomes a secondary, not a primary use lookup resolving the traffic concerns on the root hierarchy. Additionally, since ESDS is a single point of authority, it provides the ability to reference multiple past events for a given object (in a single query) and does not necessitate iterative queries for past service referrals. 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 October 13, 2007 [Page 4] Internet-Draft ESDS Concepts April 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. 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. 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. 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. Young Expires October 13, 2007 [Page 5] Internet-Draft ESDS Concepts April 2007 2.5. Event An event represents a new step in the life cycle of a tracked object or service. It carries a time stamp indicating the instant () at which the event was generated by the client system and injected into ESDS. There are two types of events: o An is captured when the system records a new life cycle step for an object bearing a given identifier (). The event consists of a supply chain specific life cycle step (). o A amends a specific event to indicate that the event was posted in error. The voided event will no longer appear in event queries. Every specifies an and a for the void, which is a freeform text string. Young Expires October 13, 2007 [Page 6] Internet-Draft ESDS Concepts April 2007 3. IANA Considerations This document has no actions for IANA. Young Expires October 13, 2007 [Page 7] Internet-Draft ESDS Concepts April 2007 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 October 13, 2007 [Page 8] Internet-Draft ESDS Concepts April 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. TDT - Tag Data Translation - Deals with the conversions between representations of the EPC. TDT URI Notation - An example of an EPCglobal standardized representation of an EPC. Young Expires October 13, 2007 [Page 9] Internet-Draft ESDS Concepts April 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 [TDT1.0] EPCglobal Software Action Tag Data Translation Working Group, "EPC Tag Data Translation Standard", January 2006. [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 October 13, 2007 [Page 10] Internet-Draft ESDS Concepts April 2007 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 October 13, 2007 [Page 11] Internet-Draft ESDS Concepts April 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 October 13, 2007 [Page 12]