Subject: [ESDS] Messages from previous ESDS mailing list...

From: "Kelly Stevenson" <[email-masked]>
Date: Thu, 27 Sep 2007 10:42:46 -0400

For those of you who are new to the ESDS discussions and may not have been
subscribed to the original ESDS mailing list, I've attached the archived
messages from that list. Please note that [email-masked] has
been replaced by [email-masked]. 

Best regards,

Kelly Stevenson

---

Kelly Stevenson

Afilias 

4141 Yonge Street, Suite 204

Toronto, Ontario, Canada

M2P 2A8

416-673-4152

www.afilias.info/ads

Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt - Digital signatures
From: "Mark Harrison" <[email-masked]>
To: "Frank Thompson" <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 10 Jul 2007 08:36:32 -0400

Dear Frank,

Some further comments inline below...

At 12:13 +0000 10/7/07, Frank Thompson wrote:
>comments below ...
>
>On Tue, 10 Jul 2007, Mark Harrison wrote:
>
>>  > Thanks Mark for another set of comments on the draft .. see my replies
>>  > inline and like the other comment email these will make it into the
-01
>>  > version of the draft.
>>  >
>>  > cheers
>>  > frank
>>  >
>>  >
>>  > On Thu, 5 Jul 2007, Mark Harrison wrote:
>>  >
>>  > > p6, Section 2.1.4	tDigitalSignature
>>  > >
>>  > > Two attributes are defined:  'alg' (digital signature alogrithm) and
>>  > > 'data' (digital signature data).
>>  > >
>>  > > Section 2.1.5 defines tDigitalSignatureAlgorithm as a token from an
>>  > > enumerated list, representing the encryption and hashing algorithms
>>  > > combined, e.g. 'rsa-md5', 'dsa-sha1'.  OK so far.
>>  > >
>>  > > The attribute 'data' is defined as a string data type - and
>>  > > according
>>  > > to the example given on p22 of draft-thompson-esds-commands-00.txt,
>>  > > the attribute called 'data' seems to contain the encrypted hash of
>>  > > the data.  However, I cannot find any indication within the
>>  > > <signature> element of a reference to the data that was hashed to
>>  > > construct the signature.  It clearly cannot be the entire message
>>  > > that embeds the signature - so where is this defined?  This
>>  > > information is essential for being able to verify a digital
>>  > > signature
>>  > > and check the authenticity of the data.
>>  >
>>  > The digial signature tags have changed in the -01 versions of the
draft
>>  > (not published yet but soon).  Upon further investigation, it may not
make
>>  > sense to store the hash and algorithm in the event record.  Instead
just
>>  > the digial signature itself encoded in base64.  The owner of the event
may
>>  > not want an unencrypted hash to be stored with the event. This is my
>>  > understanding of how digial signatures work:
>>  >
>>  > 1. generate document to be signed
>>  > 2. generate digest hash of that docuemnt
>>  > 3. encrypt the hash with the private key
>>  > 4. encode the encrypted value in base64
>>  > 5. include this base64 value with the event data to the DS
>>  >
>>  > given this the -01 version will have only a <digialSignature/> tag
which
>>  > represents the base64 value of the encrypted hash digest.
>>
>>  Dear Frank,
>>
>>  I agree that the above is a valid description of how a digital signature
is
>>  *constructed*.  However, the real value of a digital signature is in the
>>  ability to be able to verify it automatically, to check the authenticity
and
>>  integrity of the data.  For that, we need the following steps:
>>
>>  6. (if neccessary) use base64 to decode the embedded digital signature
>>  7. obtain the public key of the signatory
>>  8. use the public key, together with the specified decryption algorithm
to
>>  decrypt the signature and thereby obtain a hash value
>>  9. perform an independent re-calculation of the hash of the data, using
the
>>  specified hashing algorithm
>>  10. compare this value with the value obtained from step 8 
>>(decryption of the
>>  signature).
>>  11. if the two hash values are equal, we can be sure that the data 
>>corresponds
>>  to the signature (i.e. integrity of data is assured) and that it could
only
>>  have been signed by the organization that has the private key 
>>corresponding to
>>  the public key (i.e. authenticity of the data is assured).
>>
>>  Note that:
>>
>>  step 8 requires a reference to the public key, to enable anyone to 
>>verify the
>>  signature
>>  step 9 requires that we know which data was used for constructing the
hash.
>>  e.g. an XPath expression could specify a particular node within an XML
>>  document.  We may also need to specify a method to canonicalize the XML
data
>>  before hashing.
>
>Agreed, this was the reason for storing the hash and algorithm in the
>first version.  It was still unclear to me as to who would be performing
>the verification and without this authority to verify the data was the
>reason for just storing the digital signature alone.
>
>I see your points above and below and agree that keeping the hash and
>algorithm as they are is a better choice.  However as you say we should
>use a standardized way to store and verify the hash/algorithm derived
>from the original signature data.
>
>I will leave the current 00 notion of hash and algorithm as they are now,
>but it sounds like we can improve that method as well to help automate the
>verification process of the Discovery Service.
>
>thanks Mark!
>
>cheers
>frank

Within BRIDGE WP2, we have discussed that there may be situations 
when a Discovery Service does not return the full details of a 
records or event that was published to it.  For example, some data 
fields might need to be suppressed, to comply with some particular 
access control policies.  In this case, the original event data may 
not be revealed to the client making the query.

In our view, we may therefore need to consider two digital 
signatures, the first being checked by the DS at the inbound 
publisher/capture interface, the second being provided through the 
query interface:

1) a digital signature around a record published (input) to a DS, 
signed by the original publisher (e.g. owner of a company's EPCIS) - 
which can at least be verified by the Discovery Service upon receipt 
- and perhaps a Discovery Service then flags that a record was 
'verified' at the same time as the DS asserts the recordTime of 
receipt of the event.

2) a digital signature around a record retrieved from a DS in 
response to a query by a client.
This may be the original digital signature  provided by the publisher 
- OR (especially in the case where only a subset of the data for each 
event is returned to the client) a digital signature signed by the 
operator of the Discovery Service, together with a record or event 
that contains a field that indicates whether the DS was able to 
verify the signatures that accompanied the incoming event records 
from the publisher.

I hope this makes sense.  For both of these signatures, it is 
important to specify unambiguously which data payload is being 
signed, so that 1) the DS can verify the incoming signature and 2) 
the client can verify any signatures returned in the DS response to 
the client's query.

Best regards,

- Mark

>  > The question of whether you specify the reference to the data (e.g.
XPath
>>  expression), hashing algorithm and encryption algorithm within each
record
>>  depends on whether you want to allow for each information provider to
choose
>>  which algorithm they use.
>>
>>  I believe that we need some flexibility, so that in the future, we 
>>can migrate
>>  to stronger hashing and encryption algorithms.  (In contrast, if we
assumed
>>  that a particular Discovery Service only ever used one default hashing
>>  algorithm and one default encryption algorithm, that effectively
prevents a
>>  future upgrade path.)
>>
>>  At a minimum, we need to allow each record or event to contain a 
>>reference to
>>  the hashing algorithm, encryption algorithm, even if these are not
literally
>>  embedded per record - though it must be possible to retrieve them from a
>>  Discovery Service given the reference that is embedded in each record.
>>  We also need to know unambiguously which XML data is being hashed - and
this
>>  is something that could be common for all records - but somewhere, it
still
>>  needs to be specified unambiguously, so that we can perform step 9.
>>
>>  Best regards,
>>
>>  - Mark
>>

_______________________________________________
Esds-protocol mailing list
[email-masked]
https://mailman.afilias.info/mailman/listinfo/esds-protocol

Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt - Digital signatures
From: "Frank Thompson" <[email-masked]>
To: "Mark Harrison" <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 10 Jul 2007 08:13:53 -0400

comments below ...

On Tue, 10 Jul 2007, Mark Harrison wrote:

> > Thanks Mark for another set of comments on the draft .. see my replies
> > inline and like the other comment email these will make it into the -01
> > version of the draft.
> > 
> > cheers
> > frank
> > 
> > 
> > On Thu, 5 Jul 2007, Mark Harrison wrote:
> > 
> > > p6, Section 2.1.4	tDigitalSignature
> > > 
> > > Two attributes are defined:  'alg' (digital signature alogrithm) and
> > > 'data' (digital signature data).
> > > 
> > > Section 2.1.5 defines tDigitalSignatureAlgorithm as a token from an
> > > enumerated list, representing the encryption and hashing algorithms
> > > combined, e.g. 'rsa-md5', 'dsa-sha1'.  OK so far.
> > > 
> > > The attribute 'data' is defined as a string data type - and
> > > according
> > > to the example given on p22 of draft-thompson-esds-commands-00.txt,
> > > the attribute called 'data' seems to contain the encrypted hash of
> > > the data.  However, I cannot find any indication within the
> > > <signature> element of a reference to the data that was hashed to
> > > construct the signature.  It clearly cannot be the entire message
> > > that embeds the signature - so where is this defined?  This
> > > information is essential for being able to verify a digital
> > > signature
> > > and check the authenticity of the data.
> > 
> > The digial signature tags have changed in the -01 versions of the draft
> > (not published yet but soon).  Upon further investigation, it may not
make
> > sense to store the hash and algorithm in the event record.  Instead just
> > the digial signature itself encoded in base64.  The owner of the event
may
> > not want an unencrypted hash to be stored with the event. This is my
> > understanding of how digial signatures work:
> > 
> > 1. generate document to be signed
> > 2. generate digest hash of that docuemnt
> > 3. encrypt the hash with the private key
> > 4. encode the encrypted value in base64
> > 5. include this base64 value with the event data to the DS
> > 
> > given this the -01 version will have only a <digialSignature/> tag which
> > represents the base64 value of the encrypted hash digest.
> 
> Dear Frank,
> 
> I agree that the above is a valid description of how a digital signature
is
> *constructed*.  However, the real value of a digital signature is in the
> ability to be able to verify it automatically, to check the authenticity
and
> integrity of the data.  For that, we need the following steps:
> 
> 6. (if neccessary) use base64 to decode the embedded digital signature
> 7. obtain the public key of the signatory
> 8. use the public key, together with the specified decryption algorithm to
> decrypt the signature and thereby obtain a hash value
> 9. perform an independent re-calculation of the hash of the data, using
the
> specified hashing algorithm
> 10. compare this value with the value obtained from step 8 (decryption of
the
> signature).
> 11. if the two hash values are equal, we can be sure that the data
corresponds
> to the signature (i.e. integrity of data is assured) and that it could
only
> have been signed by the organization that has the private key
corresponding to
> the public key (i.e. authenticity of the data is assured).
> 
> Note that:
> 
> step 8 requires a reference to the public key, to enable anyone to verify
the
> signature
> step 9 requires that we know which data was used for constructing the
hash.
> e.g. an XPath expression could specify a particular node within an XML
> document.  We may also need to specify a method to canonicalize the XML
data
> before hashing.

Agreed, this was the reason for storing the hash and algorithm in the 
first version.  It was still unclear to me as to who would be performing 
the verification and without this authority to verify the data was the 
reason for just storing the digital signature alone.

I see your points above and below and agree that keeping the hash and 
algorithm as they are is a better choice.  However as you say we should 
use a standardized way to store and verify the hash/algorithm derived 
from the original signature data.

I will leave the current 00 notion of hash and algorithm as they are now, 
but it sounds like we can improve that method as well to help automate the 
verification process of the Discovery Service.

thanks Mark!

cheers
frank

> 
> 
> The question of whether you specify the reference to the data (e.g. XPath
> expression), hashing algorithm and encryption algorithm within each record
> depends on whether you want to allow for each information provider to
choose
> which algorithm they use.
> 
> I believe that we need some flexibility, so that in the future, we can
migrate
> to stronger hashing and encryption algorithms.  (In contrast, if we
assumed
> that a particular Discovery Service only ever used one default hashing
> algorithm and one default encryption algorithm, that effectively prevents
a
> future upgrade path.)
> 
> At a minimum, we need to allow each record or event to contain a reference
to
> the hashing algorithm, encryption algorithm, even if these are not
literally
> embedded per record - though it must be possible to retrieve them from a
> Discovery Service given the reference that is embedded in each record.
> We also need to know unambiguously which XML data is being hashed - and
this
> is something that could be common for all records - but somewhere, it
still
> needs to be specified unambiguously, so that we can perform step 9.
> 
> Best regards,
> 
> - Mark
> 
_______________________________________________
Esds-protocol mailing list
[email-masked]
https://mailman.afilias.info/mailman/listinfo/esds-protocol

Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt - Digital signatures
From: "Mark Harrison" <[email-masked]>
To: "Frank Thompson" <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 10 Jul 2007 03:44:53 -0400

>Thanks Mark for another set of comments on the draft .. see my replies
>inline and like the other comment email these will make it into the -01
>version of the draft.
>
>cheers
>frank
>
>
>On Thu, 5 Jul 2007, Mark Harrison wrote:
>
>>  p6, Section 2.1.4	tDigitalSignature
>>
>>  Two attributes are defined:  'alg' (digital signature alogrithm) and
>>  'data' (digital signature data).
>>
>>  Section 2.1.5 defines tDigitalSignatureAlgorithm as a token from an
>>  enumerated list, representing the encryption and hashing algorithms
>>  combined, e.g. 'rsa-md5', 'dsa-sha1'.  OK so far.
>>
>>  The attribute 'data' is defined as a string data type - and according
>>  to the example given on p22 of draft-thompson-esds-commands-00.txt,
>>  the attribute called 'data' seems to contain the encrypted hash of
>>  the data.  However, I cannot find any indication within the
>>  <signature> element of a reference to the data that was hashed to
>>  construct the signature.  It clearly cannot be the entire message
>>  that embeds the signature - so where is this defined?  This
>>  information is essential for being able to verify a digital signature
>>  and check the authenticity of the data.
>
>The digial signature tags have changed in the -01 versions of the draft
>(not published yet but soon).  Upon further investigation, it may not make
>sense to store the hash and algorithm in the event record.  Instead just
>the digial signature itself encoded in base64.  The owner of the event may
>not want an unencrypted hash to be stored with the event. This is my
>understanding of how digial signatures work:
>
>1. generate document to be signed
>2. generate digest hash of that docuemnt
>3. encrypt the hash with the private key
>4. encode the encrypted value in base64
>5. include this base64 value with the event data to the DS
>
>given this the -01 version will have only a <digialSignature/> tag which
>represents the base64 value of the encrypted hash digest.

Dear Frank,

I agree that the above is a valid description of how a digital 
signature is *constructed*.  However, the real value of a digital 
signature is in the ability to be able to verify it automatically, to 
check the authenticity and integrity of the data.  For that, we need 
the following steps:

6. (if neccessary) use base64 to decode the embedded digital signature
7. obtain the public key of the signatory
8. use the public key, together with the specified decryption 
algorithm to decrypt the signature and thereby obtain a hash value
9. perform an independent re-calculation of the hash of the data, 
using the specified hashing algorithm
10. compare this value with the value obtained from step 8 
(decryption of the signature).
11. if the two hash values are equal, we can be sure that the data 
corresponds to the signature (i.e. integrity of data is assured) and 
that it could only have been signed by the organization that has the 
private key corresponding to the public key (i.e. authenticity of the 
data is assured).

Note that:

step 8 requires a reference to the public key, to enable anyone to 
verify the signature
step 9 requires that we know which data was used for constructing the 
hash.  e.g. an XPath expression could specify a particular node 
within an XML document.  We may also need to specify a method to 
canonicalize the XML data before hashing.

The question of whether you specify the reference to the data (e.g. 
XPath expression), hashing algorithm and encryption algorithm within 
each record depends on whether you want to allow for each information 
provider to choose which algorithm they use.

I believe that we need some flexibility, so that in the future, we 
can migrate to stronger hashing and encryption algorithms.  (In 
contrast, if we assumed that a particular Discovery Service only ever 
used one default hashing algorithm and one default encryption 
algorithm, that effectively prevents a future upgrade path.)

At a minimum, we need to allow each record or event to contain a 
reference to the hashing algorithm, encryption algorithm, even if 
these are not literally embedded per record - though it must be 
possible to retrieve them from a Discovery Service given the 
reference that is embedded in each record.
We also need to know unambiguously which XML data is being hashed - 
and this is something that could be common for all records - but 
somewhere, it still needs to be specified unambiguously, so that we 
can perform step 9.

Best regards,

- Mark
_______________________________________________
Esds-protocol mailing list
[email-masked]
https://mailman.afilias.info/mailman/listinfo/esds-protocol

Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt
From: "Frank Thompson" <[email-masked]>
To: "Mark Harrison" <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 9 Jul 2007 13:57:20 -0400

Thanks Mark for another set of comments on the draft .. see my replies 
inline and like the other comment email these will make it into the -01 
version of the draft.

cheers
frank

On Thu, 5 Jul 2007, Mark Harrison wrote:

> p6, Section 2.1.4 	tDigitalSignature
> 
> Two attributes are defined:  'alg' (digital signature alogrithm) and 
> 'data' (digital signature data).
> 
> Section 2.1.5 defines tDigitalSignatureAlgorithm as a token from an 
> enumerated list, representing the encryption and hashing algorithms 
> combined, e.g. 'rsa-md5', 'dsa-sha1'.  OK so far.
> 
> The attribute 'data' is defined as a string data type - and according 
> to the example given on p22 of draft-thompson-esds-commands-00.txt, 
> the attribute called 'data' seems to contain the encrypted hash of 
> the data.  However, I cannot find any indication within the 
> <signature> element of a reference to the data that was hashed to 
> construct the signature.  It clearly cannot be the entire message 
> that embeds the signature - so where is this defined?  This 
> information is essential for being able to verify a digital signature 
> and check the authenticity of the data.

The digial signature tags have changed in the -01 versions of the draft 
(not published yet but soon).  Upon further investigation, it may not make 
sense to store the hash and algorithm in the event record.  Instead just 
the digial signature itself encoded in base64.  The owner of the event may 
not want an unencrypted hash to be stored with the event. This is my 
understanding of how digial signatures work:

1. generate document to be signed
2. generate digest hash of that docuemnt
3. encrypt the hash with the private key
4. encode the encrypted value in base64
5. include this base64 value with the event data to the DS

given this the -01 version will have only a <digialSignature/> tag which 
represents the base64 value of the encrypted hash digest.

> 
> 
> p8  Descriptions of "ets" and "sts" could be improved:

agreed

> 
> "ets"
> 
> Desc: event UTC timestamp recording the time of injection of the 
> event into the ESDS
> 
> 
> "sts"
> 
> Desc: client source system UTC timestamp (as asserted by the client)
> 
> 

agreed

> p12  regarding "flush", do we want to be so specific about queues in 
> the ESDS protocol - or allow the underlying message transport 
> protocol to handle such details?

yes, this will be expaned and include more documentation.

> 
> 
> p19  "authority" is defined as enabling the ability to authorize 
> addition or removal of related objects.
> The examples given in this document and in 
> draft-thompson-esds-commands-00.txt only show the authority attribute 
> being used in conjunction with the <partner> element.
> 
> If the same concept were in future to be applied to the authorization 
> to create events, then we would need to be much more precise about 
> the way in which the events are related?  Are they related because 
> they have the same Object ID  - or are they related if they 
> correspond to the same Object Class (assuming that this can be 
> deduced from the Object ID having a significant structure and not 
> being totally opaque [which it may be in some situations])?

There is a complete role based authentication interface that allows the 
breakdown of authority by object and and method and permission.  The 
partner authority could move to this mapping to eliminate this confusion.  
Perhaps by adding a new permission to represent the authority they can 
invoke.

thanks
frank

> 
> 
> 
> 
> Best regards,
> 
> - Mark Harrison
> -- 
> 
> Dr. Mark Harrison
> Senior Research Associate, Distributed Information and Automation
Laboratory
> Director, Auto-ID Labs at Cambridge
> Institute for Manufacturing
> University of Cambridge
> Mill Lane
> Cambridge, UK
> CB2 1RX
> 
> Tel: +44 (0)1223 338178
> E-mail:  [email-masked]
> 
> _______________________________________________
> Esds-protocol mailing list
> [email-masked]
> https://mailman.afilias.info/mailman/listinfo/esds-protocol
> 
_______________________________________________
Esds-protocol mailing list
[email-masked]
https://mailman.afilias.info/mailman/listinfo/esds-protocol

Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-commands-00.txt
From: "Frank Thompson" <[email-masked]>
To: "Mark Harrison" <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 9 Jul 2007 13:44:28 -0400

Thanks Mark, for your comments see my replies inline below ...

Most if not all your suggestions will appear in the -01 versions of the 
drafts

cheers
frank

On Thu, 5 Jul 2007, Mark Harrison wrote:

> section 4.1.2 introduces a command <UserLogin> and 4.2 introduces
<UserLogout>.
> 
> I'm not disputing that client authentication is required and that the 
> ESDS needs to check what information the client is authorized to 
> query from the ESDS or publish to the ESDS.
> 
> However, I'm not sure whether this would be handled at a lower layer 
> via the transport protocol binding (e.g. HTTPS, Web services 
> security) rather than as an explicit command called through the ESDS 
> interface?

At the lower levels there are other forms of user authentication, HTTPS 
two way certificate authentication is one example.  <UserLogin> provides 
a SASL user/password authentication layer that also ties into the security 
credential objects (Partner, SupplyChain).  This establishes a session for 
which to submit commands and also allows an audit trail of who did what 
when.

> 
> Is it realistic to assume that a client would remember to issue a 
> <UserLogout> command?
> What is the motivation for a client to do so?  (other than a billing 
> element for connected time rather than number of sessions)

<UserLogout> is optional, if the client wishes to issuse <UserLogout> it 
will have the same effect as a dropped connection or other connection 
termination.  It was added for completeness only and may not be needed as 
you state.

> 
> 
> 
> 
> p30  <ascending>
> 
> If ascending is set to false, does this imply 'descending' or 
> 'unsorted'?  How is 'descending' otherwise specified?  Probably also 
> need to extend the description to read:
> 
>      *  <ascending>
> 
>           +  Desc: if "true" sort results in ascending order on the 
> basis of the field specified by <sortBy>
> 
>           +  Type: xs:boolean
> 
>           +  Use: optional, but no more than 1 occurences
> 
> 

good point I will make the changes you suggest

> We might also need to explain that if either <sortBy> or <ascending> 
> are specified, then both must be specified together, since neither 
> makes sense without the other also being specified, unless there are 
> default values for <ascending> e.g. true  and for <sortBy> e.g. 
> sourceTS.

agreed

> 
> The XSD schema in draft-thompson-esds-schema-00.txt do not currently 
> constrain this on p75 - but if no default values are specified for 
> sortBy and ascending, this constraint (that both must be specified) 
> could be achieved by modifying the schema to read something like:

I will look at this as an option and include it in version 01

> 
>       <!-- EVENT METHODS -->
> 
>       <xs:complexType name="EventLookupIn">
>         <xs:complexContent>
>           <xs:extension base="esds:tAbstractIn">
>             <xs:sequence>
>               <xs:element
>                 name="objectID"
>                 type="esds:tObjectID"/>
>               <xs:element
>                 name="type"
>                 type="esds:tEventType"
>                 minOccurs="0"
>                 maxOccurs="unbounded"/>
>               <xs:element
>                 name="lifeCycleStepID"
>                 type="esds:tLifeCycleStepID"
>                 minOccurs="0"/>
>               <xs:element
>                 name="subscribe"
>                 type="xs:boolean"
>                 minOccurs="0"/>
>               <xs:element
>                 name="startingAt"
>                 type="xs:dateTime"
>                 minOccurs="0"/>
>               <xs:element
>                 name="endingAt"
>                 type="xs:dateTime"
>                 minOccurs="0"/>
>               <xs:element
>                 name="sorting"
>                 type="esds:tEventSorting"
>                 minOccurs="0" maxOccurs="1"/>
>               <xs:element
>                 name="limit"
>                 type="xs:int"
>                 minOccurs="0"/>
>               <xs:element
>                 name="first"
>                 type="xs:int"
>                 minOccurs="0"/>
>               <xs:element
>                 name="last"
>                 type="xs:int"
>                 minOccurs="0"/>
>             </xs:sequence>
>           </xs:extension>
>         </xs:complexContent>
>       </xs:complexType>
> 
> 
>       <xs:complexType name="EventSorting">
>         <xs:complexContent>
>           <xs:extension base="esds:tAbstractIn">
>             <xs:sequence>
>               <xs:element
>                 name="sortby"
>                 type="esds:tEventSortBy"
>                 minOccurs="1" maxOccurs="1"/>
>               <xs:element
>                 name="ascending"
>                 type="xs:boolean"
>                 minOccurs="1" maxOccurs="1"/>
>             </xs:sequence>
>           </xs:extension>
>         </xs:complexContent>
>       </xs:complexType>
> 
> 
> On p34, ets and sts appear - but are only defined as abbreviations of 
> eventTS and sourceTS on p8 of draft-thompson-esds-schema-00.txt
> It may be helpful to at least include an introductory paragraph in 
> draft-thompson-esds-commands-00.txt to advise the reader that the 
> following abbreviations (ets, sts, ....) are defined in section 2.1.7 
> of draft-thompson-esds-schema-00.txt

agreed, 01 will have this as well ...

> 
> 
> On p20-21, section 4.  <EventCreate>
> 
> the uri of the service is embedded within the EventCreate command.
> 
> A recent discussion we have had within BRIDGE WP2 is that it may be 
> preferable to decouple this URI information from the EventCreate 
> command, in order to be able to easily reconfigure multiple records 
> or events with an alternative URI, when there is a need to 
> systematically change a particular URI from a particular information 
> provider for a range of records.  Examples of why this might happen 
> are:  domain name expiry, company merger / de-merger / rebranding, 
> changes to the location of the service without taking care to provide 
> URL redirects.

I had the same idea while mapping the service records to an event.  The 
idea was that a partner would have a set of service uris that would then 
be referenced via an event create.  This way if the uri became outdated 
then there would only be one place to make the change.

However this also introduces many other problems:

1) Anyone who may have cached the service uri as it was initially posted

2) An update to the uri address means that you are changing historical 
records and thus will loose the history of where the uri was originally 
pointing.

3) The mapping means that at any point in time you do not have an exact 
snapshot of the uris associated with the service other than joining them 
based on the current values.

> 
> Our current approach is to divide this into two separate processes 
> for an information provider:
> 
> publisher profile registration  - where an information provider may 
> specify one or more profiles, each profile containing only one 
> service address and service type and a unique profile ID.  Each 
> publisher profile can be digitally signed - but one (signed) 
> publisher profile is allowed to be over-written with a revised 
> (signed) publisher profile from the same information provider, in 
> order to effect infrequent changes to the service address URI.  The 
> revised publisher profile shares the same ID as the original 
> publisher profile that it replaces.  The events or records embed the 
> publisher profile ID rather than embedding a fragile serviceAddress 
> URL.  This means that so long as the publisher profile ID is a 
> non-significant immutable identifier, it is safe to embed it within 
> an event - and even digitally sign the event.
> This has the advantage that journalled events in the ESDS that are 
> digitally signed no longer need to be voided in order to have their 
> serviceAddress URIs changed.

If the above is ok within the industry then agreed this is a much more 
flexible and maintainable solution.  I was being careful to avoid this 
folding of uris to a mapping like you state as it would have been quite 
different than the way things are handled in the current ONS. 

> 
> 
> 
> p28, section 4.6. <EventLookup>  and p35, section 4.7 <EventHistory>
> 
> EventLookup supports <subscribe> - but <EventHistory> does not appear 
> to allow for this.

In version 01, the <EventHistory> command has been dropped as it is will 
cause many issues during implementation.  The information requested by the 
history command can be retrieved by issuing individual <EventInfo> 
commands.  Thus, an <EventLookup> would be issued and from the results 
individual <EventInfo> command could be issued.

> How would a subscribed client be notified to events that are 
> subsequently voided.  Should this not also be permitted, especially 
> if they are relying on updates received from their standing query to 
> maintain the state history of a particular object of interest 
> (including voided events and the replacement events that correct the 
> information for the events that were voided)?

<EventLookup> will be changed to reflect events that have been voided 
which the history command would have shown in version 01.

> 
> end of p60 / start of p61, section 5.6  <UserInfo>
> 
> Puzzled why the description for <UserCreate> appears below, in 
> section 5.6.1.  Looks like a copy-and-paste error - and a description 
> for UserInfo is actually required here, especially as the XML does 
> not include PartnerID (which the description [albeit for UserCreate] 
> in section 5.6.1) says is required.

yes, looks like cut and paste error, will fix in 01.

> 
> p64, section  5.7  <UserUpdate>
> It might be helpful to specify which fields are immutable and used 
> for matching against an existing user - and which fields can be 
> changed as a result of executing this command.
> This command could for example be implemented in SQL as an 'UPDATE 
> .... WHERE ' - but we need to know which fields appear in the WHERE 
> clause and which fields can be updated.

agreed, this can be added to the field docs for updates.

> 
> p82, section 5.13 <SupplyChainCreate>
> Where is the authority attribute of <partner> within SupplyChainCreate
defined?

> Within this document, I can only find this explanation on p97,
> '* A partner is associated with a supply chain only by partners 
> within the supply chain that have been granted authority to add 
> partners.'
> 
> It might be more helpful to include further explanation in the 
> description of the authority attribute 5.13.1 before the XML and 
> perhaps also provide a cross-reference to section 2.1.30 of 
> draft-thompson-esds-schema-00.txt   for a description of tPartnerItem

agreed, I will expand on the use of authority.

> 
> 
> 
> Best regards,
> 
> - Mark Harrison
> -- 
> 
> Dr. Mark Harrison
> Senior Research Associate, Distributed Information and Automation
Laboratory
> Director, Auto-ID Labs at Cambridge
> Institute for Manufacturing
> University of Cambridge
> Mill Lane
> Cambridge, UK
> CB2 1RX
> 
> Tel: +44 (0)1223 338178
> E-mail:  [email-masked]
> 
> _______________________________________________
> Esds-protocol mailing list
> [email-masked]
> https://mailman.afilias.info/mailman/listinfo/esds-protocol
> 
_______________________________________________
Esds-protocol mailing list
[email-masked]
https://mailman.afilias.info/mailman/listinfo/esds-protocol

Subject: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt
From: "Mark Harrison" <[email-masked]>
To: <[email-masked]>
Date: Thu, 5 Jul 2007 10:04:03 -0400

p6, Section 2.1.4 	tDigitalSignature

Two attributes are defined:  'alg' (digital signature alogrithm) and 
'data' (digital signature data).

Section 2.1.5 defines tDigitalSignatureAlgorithm as a token from an 
enumerated list, representing the encryption and hashing algorithms 
combined, e.g. 'rsa-md5', 'dsa-sha1'.  OK so far.

The attribute 'data' is defined as a string data type - and according 
to the example given on p22 of draft-thompson-esds-commands-00.txt, 
the attribute called 'data' seems to contain the encrypted hash of 
the data.  However, I cannot find any indication within the 
<signature> element of a reference to the data that was hashed to 
construct the signature.  It clearly cannot be the entire message 
that embeds the signature - so where is this defined?  This 
information is essential for being able to verify a digital signature 
and check the authenticity of the data.

p8  Descriptions of "ets" and "sts" could be improved:

"ets"

Desc: event UTC timestamp recording the time of injection of the 
event into the ESDS

"sts"

Desc: client source system UTC timestamp (as asserted by the client)

p12  regarding "flush", do we want to be so specific about queues in 
the ESDS protocol - or allow the underlying message transport 
protocol to handle such details?

p19  "authority" is defined as enabling the ability to authorize 
addition or removal of related objects.
The examples given in this document and in 
draft-thompson-esds-commands-00.txt only show the authority attribute 
being used in conjunction with the <partner> element.

If the same concept were in future to be applied to the authorization 
to create events, then we would need to be much more precise about 
the way in which the events are related?  Are they related because 
they have the same Object ID  - or are they related if they 
correspond to the same Object Class (assuming that this can be 
deduced from the Object ID having a significant structure and not 
being totally opaque [which it may be in some situations])?

Best regards,

- Mark Harrison
-- 

Dr. Mark Harrison
Senior Research Associate, Distributed Information and Automation Laboratory
Director, Auto-ID Labs at Cambridge
Institute for Manufacturing
University of Cambridge
Mill Lane
Cambridge, UK
CB2 1RX

Tel: +44 (0)1223 338178
E-mail:  [email-masked]

_______________________________________________
Esds-protocol mailing list
[email-masked]
https://mailman.afilias.info/mailman/listinfo/esds-protocol

Subject: [Esds-protocol] Comments on draft-thompson-esds-commands-00.txt
From: "Mark Harrison" <[email-masked]>
To: <[email-masked]>
Date: Thu, 5 Jul 2007 10:03:07 -0400

section 4.1.2 introduces a command <UserLogin> and 4.2 introduces
<UserLogout>.

I'm not disputing that client authentication is required and that the 
ESDS needs to check what information the client is authorized to 
query from the ESDS or publish to the ESDS.

However, I'm not sure whether this would be handled at a lower layer 
via the transport protocol binding (e.g. HTTPS, Web services 
security) rather than as an explicit command called through the ESDS 
interface?

Is it realistic to assume that a client would remember to issue a 
<UserLogout> command?
What is the motivation for a client to do so?  (other than a billing 
element for connected time rather than number of sessions)

p30  <ascending>

If ascending is set to false, does this imply 'descending' or 
'unsorted'?  How is 'descending' otherwise specified?  Probably also 
need to extend the description to read:

     *  <ascending>

          +  Desc: if "true" sort results in ascending order on the 
basis of the field specified by <sortBy>

          +  Type: xs:boolean

          +  Use: optional, but no more than 1 occurences

We might also need to explain that if either <sortBy> or <ascending> 
are specified, then both must be specified together, since neither 
makes sense without the other also being specified, unless there are 
default values for <ascending> e.g. true  and for <sortBy> e.g. 
sourceTS.

The XSD schema in draft-thompson-esds-schema-00.txt do not currently 
constrain this on p75 - but if no default values are specified for 
sortBy and ascending, this constraint (that both must be specified) 
could be achieved by modifying the schema to read something like:

      <!-- EVENT METHODS -->

      <xs:complexType name="EventLookupIn">
        <xs:complexContent>
          <xs:extension base="esds:tAbstractIn">
            <xs:sequence>
              <xs:element
                name="objectID"
                type="esds:tObjectID"/>
              <xs:element
                name="type"
                type="esds:tEventType"
                minOccurs="0"
                maxOccurs="unbounded"/>
              <xs:element
                name="lifeCycleStepID"
                type="esds:tLifeCycleStepID"
                minOccurs="0"/>
              <xs:element
                name="subscribe"
                type="xs:boolean"
                minOccurs="0"/>
              <xs:element
                name="startingAt"
                type="xs:dateTime"
                minOccurs="0"/>
              <xs:element
                name="endingAt"
                type="xs:dateTime"
                minOccurs="0"/>
              <xs:element
                name="sorting"
                type="esds:tEventSorting"
                minOccurs="0" maxOccurs="1"/>
              <xs:element
                name="limit"
                type="xs:int"
                minOccurs="0"/>
              <xs:element
                name="first"
                type="xs:int"
                minOccurs="0"/>
              <xs:element
                name="last"
                type="xs:int"
                minOccurs="0"/>
            </xs:sequence>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>

      <xs:complexType name="EventSorting">
        <xs:complexContent>
          <xs:extension base="esds:tAbstractIn">
            <xs:sequence>
              <xs:element
                name="sortby"
                type="esds:tEventSortBy"
                minOccurs="1" maxOccurs="1"/>
              <xs:element
                name="ascending"
                type="xs:boolean"
                minOccurs="1" maxOccurs="1"/>
            </xs:sequence>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>

On p34, ets and sts appear - but are only defined as abbreviations of 
eventTS and sourceTS on p8 of draft-thompson-esds-schema-00.txt
It may be helpful to at least include an introductory paragraph in 
draft-thompson-esds-commands-00.txt to advise the reader that the 
following abbreviations (ets, sts, ....) are defined in section 2.1.7 
of draft-thompson-esds-schema-00.txt

On p20-21, section 4.  <EventCreate>

the uri of the service is embedded within the EventCreate command.

A recent discussion we have had within BRIDGE WP2 is that it may be 
preferable to decouple this URI information from the EventCreate 
command, in order to be able to easily reconfigure multiple records 
or events with an alternative URI, when there is a need to 
systematically change a particular URI from a particular information 
provider for a range of records.  Examples of why this might happen 
are:  domain name expiry, company merger / de-merger / rebranding, 
changes to the location of the service without taking care to provide 
URL redirects.

Our current approach is to divide this into two separate processes 
for an information provider:

publisher profile registration  - where an information provider may 
specify one or more profiles, each profile containing only one 
service address and service type and a unique profile ID.  Each 
publisher profile can be digitally signed - but one (signed) 
publisher profile is allowed to be over-written with a revised 
(signed) publisher profile from the same information provider, in 
order to effect infrequent changes to the service address URI.  The 
revised publisher profile shares the same ID as the original 
publisher profile that it replaces.  The events or records embed the 
publisher profile ID rather than embedding a fragile serviceAddress 
URL.  This means that so long as the publisher profile ID is a 
non-significant immutable identifier, it is safe to embed it within 
an event - and even digitally sign the event.
This has the advantage that journalled events in the ESDS that are 
digitally signed no longer need to be voided in order to have their 
serviceAddress URIs changed.

p28, section 4.6. <EventLookup>  and p35, section 4.7 <EventHistory>

EventLookup supports <subscribe> - but <EventHistory> does not appear 
to allow for this.
How would a subscribed client be notified to events that are 
subsequently voided.  Should this not also be permitted, especially 
if they are relying on updates received from their standing query to 
maintain the state history of a particular object of interest 
(including voided events and the replacement events that correct the 
information for the events that were voided)?

end of p60 / start of p61, section 5.6  <UserInfo>

Puzzled why the description for <UserCreate> appears below, in 
section 5.6.1.  Looks like a copy-and-paste error - and a description 
for UserInfo is actually required here, especially as the XML does 
not include PartnerID (which the description [albeit for UserCreate] 
in section 5.6.1) says is required.

p64, section  5.7  <UserUpdate>
It might be helpful to specify which fields are immutable and used 
for matching against an existing user - and which fields can be 
changed as a result of executing this command.
This command could for example be implemented in SQL as an 'UPDATE 
.... WHERE ' - but we need to know which fields appear in the WHERE 
clause and which fields can be updated.

p82, section 5.13 <SupplyChainCreate>
Where is the authority attribute of <partner> within SupplyChainCreate
defined?
Within this document, I can only find this explanation on p97,
'* A partner is associated with a supply chain only by partners 
within the supply chain that have been granted authority to add 
partners.'

It might be more helpful to include further explanation in the 
description of the authority attribute 5.13.1 before the XML and 
perhaps also provide a cross-reference to section 2.1.30 of 
draft-thompson-esds-schema-00.txt   for a description of tPartnerItem

Best regards,

- Mark Harrison
-- 

Dr. Mark Harrison
Senior Research Associate, Distributed Information and Automation Laboratory
Director, Auto-ID Labs at Cambridge
Institute for Manufacturing
University of Cambridge
Mill Lane
Cambridge, UK
CB2 1RX

Tel: +44 (0)1223 338178
E-mail:  [email-masked]

_______________________________________________
Esds-protocol mailing list
[email-masked]
https://mailman.afilias.info/mailman/listinfo/esds-protocol

Subject: [Esds-protocol] Comments on draft-young-esds-concepts-00.txt
From: "Mark Harrison" <[email-masked]>
To: <[email-masked]>
Date: Thu, 5 Jul 2007 10:02:22 -0400

On p2 and p9, the correct citation for URI notations for EPC 
identifiers should be:

EPCglobal Tag Data Standards  (currently at v1.3)	[TDS]
http://www.epcglobalinc.org/standards

(NOT EPCglobal Tag Data Translation   - TDS is the primary EPCglobal 
standard that defines the identifier formats, whereas TDT is a 
related standard that provides a framework for machine-readable 
encoding and decoding rules)

Note also that EPCglobal Tag Data Standards defines a Tag-Encoding 
URI that is a lossless structured representation of the identifier 
information stored on a binary tag, while the Pure-Identity URI 
format is considered to be the canonical representation of an EPC - 
and omits details about number of bits (64 , 96 etc.) and also omits 
the fast filter (logistics filter) value.  At the EPCIS layer and 
Discovery Services layer, it is expected that EPCs should only be 
communicated in the Pure-Identity URI format.

p3  'tagged with RFID tags'  (NOT 'tagged with RFIDs  because ID in 
RFID stands for 'Identification' not 'Identifier')

p3, section 1.2:

ONS is not a draft standard.  ONS v1.0 is a ratified standard 
available from http://www.epcglobalinc.org/standards

Can you be more specific about what you mean by 'that does not 
benefit from the IETF process' ?
(I'm not disputing that ONS was developed outside of IETF - but 
perhaps you can pick out specific differences compared with ENUM 
(IETF RFC 2916), where the development of ONS is considered inferior 
- just to help newcomers to IETF)

In the discussion about driving the number of public zone entries to 
extremely large numbers, we also need to be clear that ONS v1.0 does 
not handle serial-level records.  Currently ONS v1.0 only defines a 
lookup based on product class information for GTIN-encoded EPCs - and 
does not store a unique DNS record per serial number - ONS resolution 
stops at class level.

We probably also need to mention the difficulty in applying ONS to 
unstructured IDs.

Re 'Although EPCglobal has offered an alternate root system to assist 
with this problem', my understanding from reading ONS v1.0 is that 
their alternate root is at onsepc.com - and their ONS tree consists 
of deep level subdomains of this Internet domain name.  It's not 
clear that this is in any way separated from the Internet, so the 
phrase 'cost incentives are such that implementers will almost 
certainly use the Internet' seems ambiguous.

If you mean to say that 'cost incentives are such that information 
providers will almost certainly consider publishing records to 
alternative providers of ONS services', then perhaps it is better to 
say that instead.

We need to be clear that alternative ONS roots may emerge, allowing 
publishing of ONS records at lower cost, especially as ONS v1.0 
specifies the ONS query protocol as a freely available open standard.

Re 'cost incentives', we need to be very clear that ONS does not 
impose a cost barrier to querying - but that insertion of records 
into the EPCglobal root ONS is currently only available to EPCglobal 
subscribers and has not yet been 'unbundled'.

You mention the pilot ONS implementation at sgtin.id.ons.autoid.aero.

Q1)  Does this provide a mirror of the EPCglobal root ONS (i.e. we 
could also query this ONS for records from the consumer packaged 
goods sector?)

Q2) If not, then why do we use sgtin.id.ons.autoid.aero, since it is 
looking likely that the aerospace sector will use identifiers based 
on CAGE codes, rather than GS1 company prefixes and GTINs.

Q3) Do you envisage any reciprocal mirroring, such that records 
published to id.ons.autoid.aero will be visible via other ONS roots?

Re '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.', we probably need to be clearer about 
which services would be subjected to iterative queries.

The way I see it, Discovery Services provide for a layer of 
redundancy to maintain track and trace links across a supply chain or 
product lifecycle, which provides greater robustness that relying 
upon the following alternative approach:

Query ONS to find the start of the chain, then iteratively query each 
EPCIS in turn, to try to navigate forwards (downstream) along the 
supply chain, provided of course that each EPCIS provides an onward 
link, is online and responding and agrees to provide this information 
to the client (subject to the client's authentication credentials).

The way I see it, Discovery Services are not so much serving to 
minimize repetitive ONS queries, as to minimize redundant EPCIS 
queries, if for example a client is only interested in knowing where 
an object is at the current time (i.e. jumping to the end of the 
chain without going via all intermediate custodians).

Can we be somewhat clearer about this, given that reducing the need 
for tree-walking is a key concern raised by ESDS?

p5, Section 2.5.  Event.

Re 'An event represents a new step in the life cycle of a tracked 
object or service.  It carries a time stamp indicating the instant 
(<sourceTS>) at which the event was generated by the client system 
and injected into ESDS.'

I suggest re-phrasing to read,

'An event represents a new step in the life cycle of a tracked object 
or service.  It carries a time stamp indicating the instant 
(<sourceTS>) at which the event was generated by the client system. 
The ESDS also records a separate timetamp (<eventTS>) at which the 
event was injected into the ESDS.'

(eventTS does appear on p9 (section 2.1.10) of 
draft-thompson-esds-schema-00.txt - but is not mentioned at all by 
name in draft-young-esds-concepts-00.txt   - and we should not muddle 
up the distinct meanings of sourceTS and eventTS in section 2.5 of 
draft-young-esds-concepts-00.txt )

[ Note that EPCIS 1.0 uses eventTime to have the meaning you 
attribute to sourceTS  - and uses recordTime to have the meaning you 
attribute to eventTS .  This may be confusing for some readers 
familiar with EPCIS 1.0]

Best regards,

- Mark Harrison
-- 

Dr. Mark Harrison
Senior Research Associate, Distributed Information and Automation Laboratory
Director, Auto-ID Labs at Cambridge
Institute for Manufacturing
University of Cambridge
Mill Lane
Cambridge, UK
CB2 1RX

Tel: +44 (0)1223 338178
E-mail:  [email-masked]

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