Internet DRAFT - draft-young-esds-concepts
draft-young-esds-concepts
Network Working Group M. Young
Internet-Draft Afilias Canada
Intended status: Informational August 29, 2008
Expires: February 29, 2008
Extensible Supply-chain Discovery Service Concepts
draft-young-esds-concepts-04
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 February 29, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Young Expires February 29, 2008 [Page 1]
Internet-Draft ESDS Concepts October 2008
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-03".
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 February 29, 2008 [Page 2]
Internet-Draft ESDS Concepts October 2008
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 February 29, 2008 [Page 3]
Internet-Draft ESDS Concepts October 2008
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 February 29, 2008 [Page 4]
Internet-Draft ESDS Concepts October 2008
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 February 29, 2008 [Page 5]
Internet-Draft ESDS Concepts October 2008
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 February 29, 2008 [Page 6]
Internet-Draft ESDS Concepts October 2008
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 February 29, 2008 [Page 7]
Internet-Draft ESDS Concepts October 2008
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)", August 2008.
[draft-thompson-esds-schema]
Thompson, F., "Extensible Supply-chain Discovery Service
Schema (work in progress)", August 2008.
Young Expires February 29, 2008 [Page 08]
Internet-Draft ESDS Concepts October 2008
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)", August 2008.
[draft-thompson-esds-schema]
Thompson, F., "Extensible Supply-chain Discovery Service
Schema (work in progress)", August 2008.
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 February 29, 2008 [Page 09]
Internet-Draft ESDS Concepts October 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).
Young Expires February 29, 2008 [Page 10]
