Re: [ESDS] Proposed Charter - update

[Ali Rezafard <[e-mail]>]

Dear ESDS members,

We have had considerable progress on the Discovery Services protocol  
discussions. I have summarized current status on some of the ESDS work  
items and updated our charter. Our charter is modified to include  
secure and restricted discovery for the broader Internet community.

Please review and comment.

Best Regards,
Ali Rezafard

ESDS Charter:
ESDS has been chartered to architect and define a protocol for Discovery
Services. Discovery Services at its core offers to authenticated and  
authorized
users the means to discover sources of information for a particular  
object.
Discovery Services can be implemented as a decentralized directory of  
resources
indexed by a shared identifier. Discovery Services need to be  
deployable in
both closed networks as well as open and global networks such as  
Internet.

ESDS will develop interfaces for users of Discovery Services as well  
as an
interface for peer-to-peer communication among Discovery Services.  
ESDS will
develop interfaces for publishing data, submitting onetime queries, and
registering for standing queries.  ESDS should support utilization of  
a trusted
external identity management service for Authentication. ESDS should  
enable
configuration of Authorization and Access Control for publishing  
clients.

Work item current status and summary:
1.Initial Conventions

     a) Define common vocabulary and terminology.
     http://www.ietf.org/mail-archive/web/esds/current/msg00085.html
     http://www.ietf.org/mail-archive/web/esds/current/msg00087.html

     b) Define core data sets for sharing on Discovery Service,
     There are two sets of core data fields, one for data being  
published, and
     another for the data returned in response to a query.
     Publishing data fields:
         required data fields:
             URI object identifier (what)
             Publish timestamp (server timestamp)
             Service list of URLs (links)
             Event class (event type attributes, such as TTL)
             URI of event publisher (who)
         optional data fields:
             Lifecycle step (why)
             Event timestamp (client timestamp)
             Change in identifier (aggregation, disaggregation,  
relabeling)
         example extensible data fields:
             Where (bizLocation)
             Transaction data (PO, AWB, Invoice)

     Query response data fields:
         required data fields:
             URI object identifier (what)
         optional data fields:
             Publish timestamp (server timestamp)
             Service list of URLs (links)
             Event class (event type attributes, such as TTL)
             URI of event publisher (who)
             Lifecycle step (why)
             Event timestamp (client timestamp)
             Change in identifier (aggregation, disaggregation,  
relabeling)
         example extensible data fields:
             Where (bizLocation)
             Transaction data (PO,AWB,Invoice)

     c) Define handling for time zones.
     ESDS will only support UTC timestamps

     d) Define handling for Aggregation, Disaggregation, and  
Relabeling events.
     These events are useful for expressing when it may be necessary  
to track
     a different identifier in order to follow the same object.
     http://www.ietf.org/mail-archive/web/esds/current/msg00101.html

     e) Define handling for Transaction events. These events would  
associate (or
     disassociate) one or more object identifiers from the identifier of
     a business transaction or document.

2.Security

     a) Considerations for access control policies and their impact on  
Work
     Items 3 and 4.

     b) 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).
     http://www.ietf.org/mail-archive/web/esds/current/msg00104.html

     c) Define a common interface and roles for access control  
configuration
     (e.g. supply chain, partner, user).

     d) Define a mechanism for verifying digitally signed DS events  
published.
     The challenge is that the DS may need to validate the signatures  
for signed
     events it receives and log whether the data underlying a link was  
from a
     verifiable signed source.  i.e. the DS should log and indicate  
the presence
     of a verified signature in the query response (especially when it  
does not
     pass the whole signed event record to the query client).

3.Publishing Interface

     a) Define mechanism for uniquely identifying objects in a scope  
without
     requiring a global unique identifier for each and all objects  
that enter a
     scope (e.g. supply chain).
     Closed deployments of DS can utilize internal numbering authority/ 
rule and
     to make the identifier globally unique prefix it with a  
registered domain
     name.
     http://www.ietf.org/mail-archive/web/esds/current/msg00114.html

     b) Define a protocol for advertising/publishing data resources  
(Resource
     Discovery).

     c) Define a protocol and policy for retracting or voiding  
published data.

     d) Define policies for updating stale and broken links (e.g. for  
events
     with a long retention period, it is vital that links can be  
updated, when
     required).
     Publisher profile described in BRIDGE's "High level design for  
Discovery
     Services" will address this requirement:
     http://www.ietf.org/mail-archive/web/esds/current/pdfuMVBqNwBjM.pdf

     e) Define a mechanism to enable linking Discovery Service servers  
together
     (e.g. retrieving information about the entire lifecycle of a  
product as it
     moves through various supply chains).
     a record that points to another DS (instead of an information  
source) In
     this case, the query client application may choose to make a  
separate query
     to the other DS, not necessarily involving any involvement of the  
original
     DS (other than if DS1 is required to provide a federated trust  
token to the
     client that it can present to DS2).

4.Query Interface

     a) Define a protocol for querying published data, supporting both
     one-time queries and standing queries (e.g. pull vs. push queries).

     b) 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 and access policy).
     Refer to 1.d above.

     c) 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).

     d) Determine if Discovery Services should facilitate an access  
negotiation
     process (e.g. 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).

5.DS-DS Peer Communications Interface

     a) Define a protocol for inter-DS  querying.
         Initial draft of approach to DS federation
         1) Each DS holds an index of neighboring DSs (URLs) in its DS  
federation.
         2) A propagating-query is sent to a DS.
         3) The DS forwards the propagating-query to DSs listed in its  
index and
         waits for the replies. The DS also appends its DS index to the
         propagating-query, so that the same DS is not queried  
multiple times.
         4) Each DS that receives the propagating-query will perform  
step 3 on
         DSs which are not queried already.
         5) Each DS will review the propagating-query and decides  
whether it is
         interested in volunteering to receive the actual query.
         6) Each DS will wait until a specified deadline is passed for  
its
         federation neighbors to reply back.
         7) Once that period has passed, it will merge the received  
replies
         along with its own reply and send it back to the initiating DS.
         8) The first DS will send back to the client a list of DSs  
(URLs)
         which have replied.
         Note: All above actions are voluntarily for any DS server. A  
server
         could provide discovery Services without opting into  
forwarding or
         replying to any propagating-queries.

     b) Architect a bootstrapping policy for objects while ensuring  
security and
     confidentiality (e.g. locating one or more Discovery Services for a
     product which is mis-delivered).

     c) Define a procedure for a Discovery Service server to join or  
leave a
     federation of Discovery Services. This could potentially involve  
some
     manual operations (e.g. physically validating identity of a DS  
operator).



On 5-Feb-08, at 6:40PM, Ali Rezafard wrote:

> Dear ESDS group,
>
> Thanks for your responses to the initial proposed charter. Attached  
> is the updated charter based on your feedback and comments by IAB  
> and IESG. Please review and comment.
>
> Best Regards,
> Ali Rezafard
>
> 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.
>
> Work Items:
> The work group will address to the following work items:
> 1.Initial Conventions
>    a)Define common vocabulary and terminology
>    b)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.)
>    c)Define handling for time zones (e.g. accepting only UTC  
> timestamps vs.
>    accepting timestamps with any timezone)
> 2.Security
>    a)Considerations for access control policies and their impact on  
> Work
>    Items 3 and 4
>    b)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)
>    c)Define a common interface and roles for access control  
> configuration
>    (e.g. supply chain, partner, user )
> 3.Publishing Interface
>    a)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
>    b)Define a protocol for advertising/publishing data resources  
> (Resource
>    Discovery)
>    c)Define a protocol and policy for retracting or voiding  
> published data
>    d)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)
> 4.Query Interface
>    a)Define a protocol for querying published data, facilitating both
>    one-time queries and standing queries (e.g. pull vs. push queries)
>    b)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 and access policy)
>    c)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)
> 5.DS-DS Peer Communications Interface
>    a)Architect a bootstrapping policy for objects while ensuring  
> security and
>    confidentiality (e.g. locating one or more Discovery Services for a
>    product which is mis-delivered)
>    b)Define a peer-to-peer protocol to enable linking Discovery  
> Service
>    servers together (e.g. retrieving information about the entire  
> lifecycle
>    of a product as it moves through various supply chains)
>    c)Determine if Discovery Services should facilitate peer-to-peer  
> access
>    negotiation process (e.g. 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)
>
> Goals and Milestones:
> Done            Submit a draft problem statement
> April 2008      Submit a document outlining the Initial Conventions
> July 2008       Submit a draft on requirements for Security
> September 2008  Submit a draft requirements for Publishing Interface
> November 2008   Submit a draft proposed protocol for Publishing  
> Interface
> January 2008    Submit a draft on requirements for Query Interface
> March 2009      Submit a draft proposed protocol for Query Interface
> May 2009        Submit a draft on requirements for DS-DS peer  
> Communications Interface
> July 2009       Submit a draft proposed protocol for DS-DS peer  
> Communications Interface
>
> 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
>
> Further Background Reading:
> BRIDGE project - Requirements for Discovery Services
> http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20Serial%20level%20lookup%20Requirements.pdf
>
> BRIDGE project - high-level design for Discovery Services
> http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design%20Discovery%20Services.pdf
> _______________________________________________
> ESDS mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/esds

_______________________________________________
ESDS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/esds