Re: [ESDS] Interaction models for Discovery Services

[Mark Harrison <[e-mail]>]

Dear David,
Dear ESDS colleagues,

Many thanks for these observations.  I'll include a few responses to  
them inline.

On 15 Jul 2008, at 17:59, David Potter wrote:

> Dear ESDS Colleagues,
> I have now had time to study and digest Mark's submissions from one  
> week ago, which I found most interesting, and I would like to make  
> some high-level observations as follows:

> 1.  The Trade-offs.xls spreadsheet is very illuminating. For me it  
> speaks volumes about the potential complexity if the proposed  
> Discovery Services component is actually responsible for much more  
> than being a directory of information sources. Is it realistic to  
> expect a “Discovery Service”, among other functions, to handle “end- 
> user” clients, handle standing subscriptions, and to handle the  
> collection of data from multiple providers while according  
> appropriate access rights and responding with that data.

The presentation of interaction models considered different kinds of  
intermediaries.
The BRIDGE work considered that the Meta-Resource model would probably  
not be favoured in a supply-chain because companies do not want to  
give up control over their data.  In this sense, I would therefore say  
that it is not the role of a Discovery Service to handle the  
collection of data from multiple providers.  That role of gathering  
information is more for a value-added track-and-trace application or  
'consolidated information broker' than for a DS.

Regarding handling of standing subscriptions, the motivation for this  
is to allow a client to be notified about the existence of other  
organizations or who register at some point in the future that they  
hold information about a particular object (or topic).
In a supply chain context, this could help a manufacturer to identify  
which other companies handle their products after they have left the  
factory gates.
In a citizen-to-citizen context, a citizen might register with a DS  
that they have a photo or a video clip about a particular subject -  
and that they would like to be notified about others who at some point  
in the future also register about the same topic.  In this context, a  
DS is facilitating as a bottom-up mechanism to help with the building  
of a community that shares an interest in a common topic - whether it  
is an individual physical object or some topic of interest.  It's  
somewhat like subscribing to a mailing list on a particular topic.

Without supporting standing queries, a DS can only tell a client about  
those who have registered information about that object or topic in  
the past.  With standing query support, they can also keep the client  
informed about future queries.

Note that this is a different kind of standing query from the kind  
that an individual resource (such as an EPCIS) might support.  In that  
case, the ID and address of the resource is already known to the  
client - and the resource can notify the client directly about new  
additional information that the resource has recently added for that  
ID or topic.

What we are talking about for standing queries in a DS context is  
about helping the client to be notified about new / previously unknown  
resources who register with a DS for the same ID or topic at a future  
time.

On the question of whether a DS handles "end-user" clients, we  
probably need to make a distinction between:
1) an organizational end-user (e.g. an application within a company  
that attempts to query a Discovery Service directly)
2) an individual citizen end-user who attempts to query a Discovery  
Service.

 From the perspective of the EPC Network, the vision is that companies  
should be able to exchange serial-level information directly in a peer- 
to-peer or point-to-point manner without going through a broker or  
intermediate.  This is enabled by having a standardized protocol for  
sharing serial-level information and making queries about it - and  
something which the EPC Information Services (EPCIS) standard attempts  
to provide.  However, before that peer-to-peer communication between  
companies can happen, they need to know how to contact each other.  In  
small-scale pilots or where they have an existing business  
relationship, their addresses will be known to each other.  For global  
deployment and where two companies don't have an existing business  
relationship, Discovery Services can help two companies find each other.
So, my understanding is that in the EPC Network, it would be perfectly  
acceptable for an organizational end-user to query a DS directly, to  
find the address of other organizations holding relevant information  
(subject to their access control policies and whether they are willing  
to identify themselves to the client) and then to directly query the  
information resource for the detailed information.

Regarding individual citizens, it is not clear that they will have  
direct access to supply-chain Discovery Services or product-lifecycle  
Discovery Services, since there may be difficulties in authenticating  
them or making decisions about whether or not to grant them access  
(other than deciding 'no access').

More likely, an individual citizen may be able to make a request for  
traceability information on an individual they are considering buying  
- or on one that they have just bought.  In the pre-purchase scenario,  
a retail store might provide an information kiosk that allows a tagged  
object to be scanned (via serialized barcode or RFID).  The citizen is  
then provided with pre-cached traceability information for that  
individual object.  The cached information was obtained before the  
object was placed on the shelves, using the retailer's credentials to  
authenticate with a Discovery Service and with individual information  
resources, such as EPCIS instances across the supply chain.  In the  
post-purchase scenario, an individual citizen may be able to access  
pre-cached traceability information from the retailer's website or  
from the manufacturer's website.  Again, this cached info was obtained  
using the credentials of either the retailer or manufacturer and the  
access privileges granted to them by the other members of the supply  
chain for that product (which may or may not permit them to reveal  
each organization on the chain to the general public or final end- 
purchasers of the product.)

> 2.  I think that there appears to be too much focus on the specifics  
> of supply chain management and EPCIS. What is the scope of the ESDS  
> initiative?

Kary raised a similar concern.  I did mention that these presentations  
were prepared FOR the EPCglobal Data Discovery Joint Requirements  
Group - so I apologise if they seem rather too EPCIS-centric or too  
focused on supply chains.

When reading through these, the ESDS group should keep in mind the  
broader interpretation and uses of Discovery Services.

Of course you and Kary are both correct, that ESDS can take a broader  
perspective, beyond supply chains to consider entire product  
lifecycles or even completely esoteric or unrelated applications of  
Discovery Services.  Above, I gave the example of Discovery Services  
enabling citizen-to-citizen information discovery in a bottom-up  
approach that is not reliant on the top-down approach of today's  
search engines.  That *could* be a motivation for IETF to consider  
Discovery Services as being an important topic, even if the IETF is  
not so interested in supply chains.

> a.  To create a generic information directory service?

In ESDS, we can keep it quite general purpose.

> b.  Or to create a discovery service specifically for EPCIS and its  
> data scope?

Not specifically for EPCIS.  Of course, the EPCglobal community could  
be a major beneficiary of some of the work that ESDS does - but in  
ESDS we should try to keep it generic, while also considering how to  
make it easily transferable to an EPC Network context.

There are probably some terms in the existing ESDS drafts that are  
still too supply-chain-centric, that don't make sense in a citizen-to- 
citizen use of Discovery Services.  For example business step or  
lifecycle step - but so long as those are optional fields, we can  
probably live with them.

> 3.  I am uncomfortable with the portrayal of the role of the  
> Discovery Service as an intermediary, between the Query Clients and  
> the Information Resources. I think that this intermediary role  
> compromises the real role of DS by expecting DS to perform many,  
> potentially conflicting, roles as already mentioned in 1. above.  
> This significantly increases the complexity of what the DS is  
> supposed to be and also creates much more complex trust and access  
> relationships.

In the presentations, I have tried to indicate for each of the models,  
what data would need to be stored (either temporarily or permanently)  
in a Discovery Service.  If we want to support both a historical  
directory as well as future-looking standing queries, we will normally  
need to use a combination of two models.

Most of the models (with the exception of the Meta Resource model) are  
trying to keep the DS as a lightweight intermediary.  Another point to  
note is that the interaction models described are only about the  
initial step of helping a client to find a resource.  As soon as the  
client knows the address of the resource, it can contact the resource  
directly in a point-to-point manner, without having to interact  
further via a Discovery Service.  Sorry if that was not clear enough  
in the slides.

You are of course correct that the models differ from each other in  
the amount of complex trust and access relationships that they need to  
handle.
However, this is only one aspect of the trade-offs.  The spreadsheet  
was an initial attempt to show a balanced view of (ideally) all the  
trade-offs across the models.

> 4.  I would like to return for a moment to the concept of the  
> “Consolidated Information Broker”, or CIB, that I raised a few weeks  
> back (posting 21st  April 2008). If you replace the Query Client in  
> Mark’s models with a “broker” type function, even one of the “Value- 
> added track & trace applications & supply-chain management  
> applications” shown on slide 5 of Mark’s Terminology and Scope.ppt,  
> then the relationship between the broker, the DS and the Information  
> Resources is much more logical. The tasks of managing the real  
> client requests, standing subscriptions, access and permissions etc.  
> can then be handled by the “broker”/value-added application which  
> uses the DS to locate data on behalf of the query clients.

I suppose a question there is who operates the 'Consolidated  
Information Broker' role.  I can imagine that a company might have  
such an application within their organization, that can interact with  
underlying Discovery Services and Information Resources and insulate  
employees of that company from needing to make queries directly to a  
DS or information resource.

However, a 'Consolidated Information Broker' provided by a third party  
may be trickier to achieve, since an individual company may have  
different access privileges through their own credentials and business  
relationships to what the third party CIB provider has.  There might  
be ways for a company to securely pass-through their credentials to  
the third party, in a way that prevents the third party CIB provider  
from gaining the ability to impersonate the company that provided the  
credentials - but it is probably not straightforward.

> 5.  This creates a simpler trust/authentication/access model because  
> query clients would no longer have direct access to the DS, only  
> well-trusted and certificated “broker”/value-added applications  
> would be granted such access. Similarly query clients would have no  
> direct access to the Information Resources, only the “broker”/value- 
> added applications would have such access. The risk of information  
> harvesting by “honeypot” resources is more or less eliminated in  
> this way.

I think this vision (however valid) is in conflict with the vision for  
the EPC Network, where a client is technically allowed to access a DS  
or information resource directly, without having to go via a broker.   
For the ESDS work to be useful to the EPCglobal community, I think we  
still need to allow for any organization or individual to be  
technically able to query or register information with an ESDS or  
information resource without going via a broker.  Of course, they  
might be denied access or given very restrictive access - but in  
principle, subject to authorization, they can communicate directly.

> 6.  This approach, in my opinion, leaves the DS with a much clearer  
> role. It has on the one hand only to deal with properly registered  
> and authenticated Information Resources who are authorised to  
> publish the whereabouts of information, probably with some strict  
> scope controls to prevent false information from being published by  
> otherwise legitimate publishers. On the other hand it responds to  
> queries from properly registered and authenticated “brokers”/value- 
> added applications.

Although our views may differ somewhat on (5) and (6), I do agree with  
you on the need to support the idea of properly registered clients and  
publishers interacting with a DS.  This may require a client or  
publisher to present a digital security certificate that not only  
asserts who they are - but also that they are a genuine member of a  
particular industry sector or have a licence to operate (in highly  
regulated industry sectors).  This is certainly functionality that  
would be very useful for the design of a Discovery Service to include,  
even though it might only be implemented in Business-to-Business  
Discovery Services and might not always be implemented in Citizen-to- 
Citizen Discovery Services.

In this example, there is perhaps a role for an industry body or  
consortium to play in the certification process, to ensure that only  
bona fide members of the community can connect to a particular  
Discovery Service.

In a Business-to-Citizen context, an example might be a security token  
that is printed on the purchase receipt, which provides the retailer  
or manufacturer with assurance that the client is the purchaser of the  
individual product, rather than a random member of the public.

> As Mark hoped, I also hope that these remarks will stimulate still  
> further lively discussion which will move us towards our eventual  
> goal.
> Best regards,
> David.

Many thanks for this posting.  I hope that the responses above help to  
address some of your concerns and that your comments and my responses  
also help to stimulate further discussion.

Best regards,

- Mark



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf  
> Of Mark Harrison
> Sent: 08 July 2008 11:10
> To: [e-mail]
> Subject: [ESDS] Interaction models for Discovery Services
>
> Dear ESDS colleagues,
>
> Following on from the previous discussions on this mailing list about
> the interaction between Discovery Services and 'Consolidated
> Information Brokers', I have attached a couple of Powerpoint
> presentations, which I presented 3 weeks ago at a face-to-face meeting
> of the EPCglobal Data Discovery Joint Requirements Group.
>
> The presentation on the interaction models considers the possible
> sequences of message flows between a query client, an information
> resource and a Discovery Service, considering suitability of each
> model for one-off queries as well as standing queries, together with
> an analysis of their relative merits in terms of protecting the
> confidentiality of information resources, confidentiality of clients'
> queries, as well as considering the kinds of data to be stored in a
> DS, performance and latency issues and impact on the network traffic
> and possible security threats.
>
> The slides are intended to provide an easy-to-read animated summary of
> the analysis contained in section B of  the document D2.4 from the
> BRIDGE project (High-level design document).
>
>       http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design%20Discovery%20Services.pdf
>
> I would also like to acknowledge that the original BRIDGE document
> D2.4 section B was jointly authored by Trevor Burbridge (BT), Oliver
> Kasten (SAP), Cosmin Condea (SAP) and Mark Harrison (University of
> Cambridge, Auto-ID Lab), with additional inputs from Nicholas Pauvre
> (GS1 France) and members of AT4 wireless (who led BRIDGE WP2).
>
>
> I have also attached an Excel spreadsheet which indicates some of the
> advantages and disadvantages from the perspectives of the client,
> resource, DS and network traffic, together with some possible
> countermeasures.  Feel free to modify the spreadsheet - though I
> suggest that you highlight any changed cells (e.g. set background
> colour of cell to yellow) so it is clear to everyone which changes you
> have made.
>
> I really hope that these presentations and the spreadsheet will
> stimulate some lively discussion on this mailing list and I look
> forward to reading your comments about the different interaction
> models for Discovery Services.
>
> Best regards,
>
> - Mark Harrison
>

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