Subject: [ESDS] Proposed Charter

From: Ali Rezafard <[email-masked]>
Date: Mon, 28 Jan 2008 13:52:48 -0500

Dear ESDS group,

Below is the proposed charter and work items for our work group. Please 
review and comment.

Extensible Supply-chain Discovery Service (ESDS)
=====================================

Chair(s):
    Mark Harrison <mark.harrison at cantab.net>
Applications Area Director(s):
    Lisa Dusseault <lisa at osafoundation.org>
    Chris Newman <chris.newman at sun.com>
Applications Area Advisor:
    Lisa Dusseault <lisa at osafoundation.org>
Mailing List(s):
    esds at ietf.org
General information about the mailing list is at:
    https://www1.ietf.org/mailman/listinfo/esds

Purpose of Working Group:
-----------------------------------
The use of Supply chain Tracking Systems is rising at an unprecedented 
rate, particularly as various industry sectors are increasingly adopting 
automatic identification technologies such as Radio-Frequency 
Identification (RFID) to automatically track individual physical objects 
as they move through a supply chain.  Rather than tracking at batch or 
lot level, the ultimate goal of this technology is that each individual 
physical object will have its own unique ID, which can be used to gather 
and retrieve complete lifecycle information about the object, which is 
fragmented across the supply chain. Deployment of these systems has 
grown to a point where they can no longer operate effectively in 
isolation from other systems.  There is a need to share data among these 
disparate systems, which are owned and operated by separate organizations.

ESDS has been chartered to architect and define the protocol of a 
Discovery Service for global supply chains. ESDS's goal is to enable 
searching for information on physical objects flowing in a supply chain, 
by authorized and authenticated users.  Economic and technical factors 
dictate that Discovery Services and their protocol ESDS must be designed 
for deployment on the Internet. Access control, data protection and 
security are of utmost importance, due to sensitivity and value of the 
information generated by the supply chain.

Goals and Milestones:
----------------------------
The work group will address to the following work items:

1) Define common vocabulary and terminology
2) Define core data sets for sharing on Discovery Service, including 
required data fields, optional data fields, and extensible data fields 
(e.g. who, what, when, where, why, links, identifier, lifecycle, class, 
etc.)
3) Define fault tolerance for missing required data fields
4) Define mechanism for uniquely identifying objects in a supply chain 
without requiring a global unique identifier for each and all objects 
that enter a supply chain
5) Define handling for time zones (e.g. accepting only UTC timestamps 
vs. accepting timestamps with any timezone)
6) Define a protocol for advertising/publishing data resources (Resource 
Discovery)
7) Define a protocol and policy for retracting or voiding published data
8) Define a protocol for querying published data, facilitating both 
one-time queries and standing queries (e.g. pull vs. push queries)
9) Define a common interface for access control configuration (e.g. 
supply chain, partner, user, roles)
10) Define security architecture and mechanisms for authorization, 
authentication , encryption (e.g.
integrating security certificates into the protocol vs. relying on a 
security layer such as SSL)
11) Architect a bootstrapping policy for objects while ensuring security 
and confidentiality
12) Define a common configuration interface for each category of 
policies (e.g. access policies, retention policies, archiving policies, 
purging  policies, audit policies, QoS policies, propagation policies)
13) Define policies for updating stale and broken links (e.g. for 
records with a long retention period, it is vital that links can be 
updated, when required)
14) Validate that the deployment architecture is independent, scalable 
and robust
15) Determine how aggregation and disaggregation events should be 
handled including policies for access control and visibility of these 
events (e.g. a pallet is broken down into boxes and each box has its own 
destination supply chain)
16) Determine if multilayer information visibility is required (e.g. 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)
17) Define a peer-to-peer protocol to enable linking Discovery Service 
servers together

_______________________________________________
ESDS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/esds

---

From: Mark Harrison <[email-masked]>
Date: Tue, 29 Jan 2008 12:27:02 +0000

It might be helpful to include a section that lists the current  
internet drafts for ESDS:

Current Internet-Drafts:
http://www.ietf.org/internet-drafts/draft-rezafard-esds-problem-statement-00.txt
http://www.ietf.org/internet-drafts/draft-young-esds-concepts-03.txt
http://www.ietf.org/internet-drafts/draft-thompson-esds-commands-02.txt
http://www.ietf.org/internet-drafts/draft-thompson-esds-schema-02.txt

It seems that work item 11) (bootstrapping policy) is concerned with  
the problem of how to find one or more Discovery Services for the  
object, given limited prior information.  This may be particularly  
important for objects that are mis-delivered or found unexpectedly.

Regarding work item 16) a particular challenge to consider is how a  
query client negotiates for access to information from an organization  
in the situation 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.   
There may be a role for Discovery Services to help in 'bootstrapping'  
that negotiation process, to allow a query client to negotiate for  
access with an initially unidentified organization, while preserving  
the confidentiality and identity of the information-providing  
organization.

Best regards,

- Mark Harrison

On 28 Jan 2008, at 18:52, Ali Rezafard wrote:

> Dear ESDS group,
>
> Below is the proposed charter and work items for our work group.  
> Please review and comment.
>
> The use of Supply chain Tracking Systems is rising at an  
> unprecedented rate, particularly as various industry sectors are  
> increasingly adopting automatic identification technologies such as  
> Radio-Frequency Identification (RFID) to automatically track  
> individual physical objects as they move through a supply chain.   
> Rather than tracking at batch or lot level, the ultimate goal of  
> this technology is that each individual physical object will have  
> its own unique ID, which can be used to gather and retrieve complete  
> lifecycle information about the object, which is fragmented across  
> the supply chain. Deployment of these systems has grown to a point  
> where they can no longer operate effectively in isolation from other  
> systems.  There is a need to share data among these disparate  
> systems, which are owned and operated by separate organizations.
>
> searching for information on physical objects flowing in a supply  
> chain, by authorized and authenticated users.  Economic and  
> technical factors dictate that Discovery Services and their protocol  
> ESDS must be designed for deployment on the Internet. Access  
> control, data protection and security are of utmost importance, due  
> to sensitivity and value of the information generated by the supply  
> chain.
>
> Goals and Milestones:
> required data fields, optional data fields, and extensible data  
> fields (e.g. who, what, when, where, why, links, identifier,  
> lifecycle, class, etc.)
> 4) Define mechanism for uniquely identifying objects in a supply  
> chain without requiring a global unique identifier for each and all  
> objects that enter a supply chain
> 5) Define handling for time zones (e.g. accepting only UTC  
> timestamps vs. accepting timestamps with any timezone)
> 6) Define a protocol for advertising/publishing data resources  
> (Resource Discovery)
> 11) Architect a bootstrapping policy for objects while ensuring  
> security and confidentiality
> policies (e.g. access policies, retention policies, archiving  
> policies, purging  policies, audit policies, QoS policies,  
> propagation policies)
> 14) Validate that the deployment architecture is independent,  
> scalable and robust
> handled including policies for access control and visibility of  
> these events (e.g. a pallet is broken down into boxes and each box  
> has its own destination supply chain)
> 16) Determine if multilayer information visibility is required (e.g.  
> 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)
> 17) Define a peer-to-peer protocol to enable linking Discovery  
> Service servers together
>
>
>

---

From: Kary Främling <[email-masked]>
Date: Tue, 29 Jan 2008 14:51:04 +0200

Dear group,

Just a quick comment about the charter text. It says "which can be used 
to gather and retrieve complete lifecycle information about the object" 
but apparently the definition of "object lifecycle" only covers the 
design and manufacturing phases (i.e. the supply chain) of the object.

As I have been working on the PROMISE project 
(http://www.promise-plm.com/) for the last years, my understanding of 
"object lifecycle" also includes the usage phase (including consumers, 
not only airlines or similar "commercial" or "industrial" end-user 
organisations) and the "end-of-life", i.e. recycling.

This difference is fundamental for the work group charter. The scope 
becomes much broader and the technical challenges are greater if the 
PROMISE-kind interpretation is used. But the vision also becomes more 
interesting, i.e. a "true" Internet of Things.

I personally vote for the PROMISE-kind interpretation but no matter 
which interpretation is used, it should be clearly expressed in the 
charter.

Another thing: if consumers are included in the vision, then "privacy" 
also becomes a part of security. "Privacy" might sound unattractive but 
anonymization and pseudonymization solutions are used for tackling this 
in many systems already.

Regards,

   Kary Främling
---
Mail: Helsinki University of Technology, P.O. Box 5500, FI-02015 HUT, 
Finland
Office: TUAS Building, Room 2044, Otaniementie 17, Espoo
Phone: +358 50 5980451, Telefax: +358 9 451 3293
Email: [email-masked], WWW: http://www.cs.hut.fi/~framling

> rate, particularly as various industry sectors are increasingly 
> adopting automatic identification technologies such as Radio-Frequency 
> Identification (RFID) to automatically track individual physical 
> objects as they move through a supply chain.  Rather than tracking at 
> batch or lot level, the ultimate goal of this technology is that each 
> individual physical object will have its own unique ID, which can be 
> used to gather and retrieve complete lifecycle information about the 
> object, which is fragmented across the supply chain. Deployment of 
> these systems has grown to a point where they can no longer operate 
> effectively in isolation from other systems.  There is a need to share 
> data among these disparate systems, which are owned and operated by 
> separate organizations.
>
> chain, by authorized and authenticated users.  Economic and technical 
> factors dictate that Discovery Services and their protocol ESDS must 
> be designed for deployment on the Internet. Access control, data 
> protection and security are of utmost importance, due to sensitivity 
> and value of the information generated by the supply chain.
>
> Goals and Milestones:
> (e.g. who, what, when, where, why, links, identifier, lifecycle, 
> class, etc.)
> policies, purging  policies, audit policies, QoS policies, propagation 
> policies)
> events (e.g. a pallet is broken down into boxes and each box has its 
> own destination supply chain)

---

From: Mark Harrison <[email-masked]>
Date: Tue, 29 Jan 2008 14:58:20 +0000

Dear Kary, ESDS folks,

Many thanks for your comments!
The E in ESDS is certainly intended to cover both 'extensible' (in the  
technical sense) as well as referring to 'extended' supply chains.

When we said 'which can be used to gather and retrieve complete  
lifecycle information about the object', the intention is of course to  
cover the entire product lifecycle, allowing any organization that is  
involved at any stage in the life of a product to publish links to a  
Discovery Service - or to query it for links to those organizations  
who published a link, subject of course to authentication and  
authorization (governed by fine-grained access control policies set by  
each organization that publishes a link (or event) to a Discovery  
Service), as well as any other access control policies that are set by  
the operator of the Discovery Service or as a result of other  
legislative or regulatory guidelines).

i.e. organizations that interact with Discovery Services potentially  
include (but are not limited to):

designers of products
manufacturers
integrators of composite products
suppliers of components
distributors
wholesalers
companies providing storage
companies providing transport and logistics
retailers
organizations involved with collection, recycling and remanufacturing  
of products
organizations who provide spares, replacement parts and consumables  
(e.g. cartridges, refills etc.)
organizations involved in the maintenance, repair, overhaul and  
servicing of products
industry bodies and regulators
insurance companies
customs officials

In some situations, end-consumers may be provided with some access  
(subject to access control policies determined by the manufacturers,  
supply chain members or by legislation) - although it is unlikely that  
many organizations would provide Discovery Service records that are  
open to anonymous access.  Within a retail store, a retailer might  
provide product information kiosks, which provide the public with  
information that is gathered using Discovery Services - but in some  
cases, this will have been pre-cached by the retailer (using the  
retailer's own credentials) in order to make it available to anonymous  
customers within their store.

Other public access might be provided to traceability service, via a  
secure web page, which requires the customer to provide the serial  
number of the product - or some other details, such as a code that is  
printed on their receipt of purchase.  Such a web-based traceability  
service may (behind the scenes) interact with Discovery Services and  
other information services, such as EPC Information Services - and  
present a consolidated view of lifecycle traceability information to  
the customer.  However, like the example of an information kiosk  
within a retail store, the end-consumer is provided with information,  
mediated by an authorized supply chain player, such as the product  
manufacturer or the retailer.

In the two above examples, there is no need for a Discovery Service to  
hold a record (or link information) about which consumer brought a  
product - or enquired about a product in-store.   Both mechanisms  
described could allow the customer to remain anonymous.

Many thanks for your input!

Best regards,

- Mark

On 29 Jan 2008, at 12:51, Kary Främling wrote:

> Dear group,
>
> Just a quick comment about the charter text. It says "which can be  
> object" but apparently the definition of "object lifecycle" only  
> covers the design and manufacturing phases (i.e. the supply chain)  
> of the object.
>
> As I have been working on the PROMISE project (http://www.promise-plm.com/ 
> ) for the last years, my understanding of "object lifecycle" also  
> includes the usage phase (including consumers, not only airlines or  
> similar "commercial" or "industrial" end-user organisations) and the  
> "end-of-life", i.e. recycling.
>
> PROMISE-kind interpretation is used. But the vision also becomes  
> more interesting, i.e. a "true" Internet of Things.
>
> Another thing: if consumers are included in the vision, then  
> "privacy" also becomes a part of security. "Privacy" might sound  
> unattractive but anonymization and pseudonymization solutions are  
> used for tackling this in many systems already.
>
> Regards,
>
>  Kary Främling
> ---
> Mail: Helsinki University of Technology, P.O. Box 5500, FI-02015  
> HUT, Finland
>> its own unique ID, which can be used to gather and retrieve  
>> complete lifecycle information about the object, which is  
>> isolation from other systems.  There is a need to share data among  
>> these disparate systems, which are owned and operated by separate  
>> organizations.
>>
>> Discovery Service for global supply chains. ESDS's goal is to  
>> enable searching for information on physical objects flowing in a  
>> supply chain, by authorized and authenticated users.  Economic and  
>> technical factors dictate that Discovery Services and their  
>> protocol ESDS must be designed for deployment on the Internet.  
>> Access control, data protection and security are of utmost  
>> importance, due to sensitivity and value of the information  
>> generated by the supply chain.
>>
>> Goals and Milestones:
>> 2) Define core data sets for sharing on Discovery Service,  
>> including required data fields, optional data fields, and  
>> extensible data fields (e.g. who, what, when, where, why, links,  
>> identifier, lifecycle, class, etc.)
>> integrating security certificates into the protocol vs. relying on  
>> a security layer such as SSL)
>> 16) Determine if multilayer information visibility is required  
>> (e.g. a query with limited access can be informed of the existence  
>> of information for a particular object, but to view the actual

---

From: Kary Främling <[email-masked]>
Date: Tue, 29 Jan 2008 18:06:49 +0200

Dear Mark,

That was a quick reply! What I was thinking about was rather that 
products are sources of information also during their usage by consumers 
- and that usage information is valuable e.g. for manufacturers and 
service providers. Here I am thinking about cars, household appliances 
etc. This implies that "organisation" might need to be extended to 
include individuals, families/homes and maybe something more (could 
machines "own" themselves in the future?). Security is obviously 
important here also - you don't want thiefs to get an online inventory 
of your home or statistics indicating that you haven't opened your 
fridge for a week so they can come and visit your home.

Being anonymous is partially related to this - it's like with ONS 
queries that could allow someone to spy on what objects are located 
where. If your "intelligent machine" needs to do a Discovery Services 
lookup for some reason, it could be good for it to be anonymous.

I know that I am now going far from RFID-only scenarios and from the 
typical EPCGlobal scenarios. But considering such scenarios could 
hopefully help in defining the scope of ESDS.

Best regards,

   Kary

> The E in ESDS is certainly intended to cover both 'extensible' (in 
> the  technical sense) as well as referring to 'extended' supply chains.
>
> lifecycle information about the object', the intention is of course 
> to  cover the entire product lifecycle, allowing any organization that 
> is  involved at any stage in the life of a product to publish links to 
> a  Discovery Service - or to query it for links to those 
> organizations  who published a link, subject of course to 
> authentication and  authorization (governed by fine-grained access 
> control policies set by  each organization that publishes a link (or 
> event) to a Discovery  Service), as well as any other access control 
> policies that are set by  the operator of the Discovery Service or as 
> a result of other  legislative or regulatory guidelines).
>
> supply chain members or by legislation) - although it is unlikely 
> that  many organizations would provide Discovery Service records that 
> are  open to anonymous access.  Within a retail store, a retailer 
> might  provide product information kiosks, which provide the public 
> with  information that is gathered using Discovery Services - but in 
> some  cases, this will have been pre-cached by the retailer (using 
> the  retailer's own credentials) in order to make it available to 
> anonymous  customers within their store.
>
> In the two above examples, there is no need for a Discovery Service 
> to  hold a record (or link information) about which consumer brought 
> a  product - or enquired about a product in-store.   Both mechanisms  
>> (http://www.promise-plm.com/ ) for the last years, my understanding 
>> of "object lifecycle" also  includes the usage phase (including 
>> consumers, not only airlines or  similar "commercial" or "industrial" 
>> end-user organisations) and the  "end-of-life", i.e. recycling.
>>