From esds-bounces@ietf.org Thu Sep 27 10:43:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaua4-0006Bi-Cw; Thu, 27 Sep 2007 10:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaua2-0006Af-Dr for esds@ietf.org; Thu, 27 Sep 2007 10:43:06 -0400 Received: from vgateway.libertyrms.info ([207.219.45.62] helo=mail.libertyrms.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IauZr-0000GU-Gh for esds@ietf.org; Thu, 27 Sep 2007 10:43:06 -0400 Received: from ibm-kelly.int.libertyrms.com ([10.1.3.42] helo=ibmkelly) by mail.libertyrms.com with esmtp (Exim 4.22) id 1IauZg-0005IT-Q1 for esds@ietf.org; Thu, 27 Sep 2007 10:42:44 -0400 From: "Kelly Stevenson" To: Date: Thu, 27 Sep 2007 10:42:46 -0400 Message-ID: <003201c80114$abdc3bd0$2a03010a@ibmkelly> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01C800F3.24CA9BD0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgBFKtPtjkMhCG9Sf6hiOooQbtokg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-SA-Exim-Mail-From: kstevenson@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Spam-Score: -4.0 (----) X-Scan-Signature: bec9f945e440571644307cbaef976a81 Subject: [ESDS] Messages from previous ESDS mailing list... X-BeenThere: esds@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of the ESDS \(Extensible Supplychain Discovery Service\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: esds-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0034_01C800F3.24CA9BD0" ------=_NextPart_001_0034_01C800F3.24CA9BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 esds-protocol@afilias.info has been replaced by esds@ietf.org. Best regards, Kelly Stevenson --- Kelly Stevenson Afilias 4141 Yonge Street, Suite 204 Toronto, Ontario, Canada M2P 2A8 416-673-4152 www.afilias.info/ads ------=_NextPart_001_0034_01C800F3.24CA9BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 esds-protocol@afilias.info= has been replaced by esds@ietf.org. =

 

Best = regards,

Kelly = Stevenson

 

 

---

Kelly = Stevenson

Afilias =

4141 Yonge Street, Suite = 204

Toronto, Ontario, Canada

M2P = 2A8

416-673-4152

www.afilias.info/ads

 

------=_NextPart_001_0034_01C800F3.24CA9BD0-- ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail00.afilias.info (localhost [127.0.0.1]) by antispam.ca.afilias.info (Spam Firewall) with ESMTP id 7EDCF55009; Tue, 10 Jul 2007 08:36:42 -0400 (EDT) Received: from [207.219.45.62] (helo=antispam.ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I8ExQ-00064s-Bh for kstevenson@ca.afilias.info; Tue, 10 Jul 2007 08:36:44 -0400 Received: from mail00.afilias.info (localhost [127.0.0.1]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l6ACagNW029682; Tue, 10 Jul 2007 08:36:42 -0400 Received: from mail00.afilias.info (mail02.afilias.info [69.46.107.12]) by antispam.ca.afilias.info with ESMTP id esBTmmbtt4AF5FjX; Tue, 10 Jul 2007 08:36:42 -0400 (EDT) Received: from [62.72.98.58] (port=19035 helo=[10.10.10.93]) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:465) with esmtpsa (PLAIN:mgh12) (TLSv1:DHE-RSA-AES256-SHA:256) id 1I8ExG-0007HW-N0 (Exim 4.63) (return-path ); Tue, 10 Jul 2007 13:36:34 +0100 Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l6ACadvI029672 for ; Tue, 10 Jul 2007 08:36:39 -0400 Received: from mail.libertyrms.com (ypres.int.libertyrms.com [10.1.2.16]) by imap (Cyrus v2.2.8) with LMTPA; Tue, 10 Jul 2007 08:36:45 -0400 Return-Path: From: "Mark Harrison" Sender: To: "Frank Thompson" Cc: References: Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt - Digital signatures Date: Tue, 10 Jul 2007 08:36:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C800F3.24C36FE0" X-Mailer: Microsoft Office Outlook 11 X-Sieve: CMU Sieve 2.2 In-Reply-To: Thread-Index: AcfC7vmpfdWOUjT2S/yldeLKZ8NJnw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-SA-Exim-Mail-From: esds-protocol-bounces@afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-ASG-Debug-ID: 1184071002-530c00080000-Kj5QqI X-Barracuda-URL: http://antispam.afilias.info:8000/cgi-bin/mark.cgi List-Help: List-Unsubscribe: , List-Subscribe: , X-ASG-Orig-Subj: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt - Digital signatures X-Barracuda-Connect: mail02.afilias.info[69.46.107.12] X-Barracuda-Start-Time: 1184071003 X-Barracuda-Virus-Scanned: by Afilias Spam Firewall at ca.afilias.info X-BeenThere: esds-protocol@afilias.info X-Mailman-Version: 2.1.8 x-virus-scanned: ClamAV 0.88/3620/Mon Jul 9 21:30:39 2007 onmail00.afilias.info x-envelope-to: x-spam-checker-version: SpamAssassin 3.1.7 (2006-10-05) on mail00.afilias.info x-spam-status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.7 x-virus-status: Clean x-asg-whitelist: Sender This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C800F3.24C36FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 >> > > 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 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 Esds-protocol@afilias.info https://mailman.afilias.info/mailman/listinfo/esds-protocol ------=_NextPart_000_0012_01C800F3.24C36FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt = - Digital signatures

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
Esds-protocol@afilias.info
http= s://mailman.afilias.info/mailman/listinfo/esds-protocol

------=_NextPart_000_0012_01C800F3.24C36FE0-- ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail00.afilias.info (mail02.afilias.info [69.46.107.12]) by antispam.ca.afilias.info with ESMTP id cB5S7NmlEPrFyB7o; Tue, 10 Jul 2007 08:14:25 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by antispam.ca.afilias.info (Spam Firewall) with ESMTP id 724F754EE7; Tue, 10 Jul 2007 08:14:25 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l6ACDu5c019002; Tue, 10 Jul 2007 08:14:03 -0400 Received: from fermi.int.libertyrms.com ([10.1.2.47]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I8EbJ-0004js-FK; Tue, 10 Jul 2007 08:13:53 -0400 Received: from mail.libertyrms.com (vgateway.afilias.info [207.219.45.62]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l6ACDrCU018988 for ; Tue, 10 Jul 2007 08:13:53 -0400 Received: from mail.libertyrms.com (ypres.int.libertyrms.com [10.1.2.16]) by imap (Cyrus v2.2.8) with LMTPA; Tue, 10 Jul 2007 08:14:29 -0400 Received: from [207.219.45.62] (helo=antispam.ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I8Ebr-0004oy-7l for kstevenson@ca.afilias.info; Tue, 10 Jul 2007 08:14:27 -0400 Return-Path: From: "Frank Thompson" Sender: To: "Mark Harrison" Cc: References: Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt - Digital signatures Date: Tue, 10 Jul 2007 08:13:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C800F3.24C5E0E0" X-Mailer: Microsoft Office Outlook 11 X-Sieve: CMU Sieve 2.2 In-Reply-To: Thread-Index: AcfC691YWYy5EV1iRSmOu3fDgnyh2g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-SA-Exim-Mail-From: esds-protocol-bounces@afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-ASG-Debug-ID: 1184069665-24c800110000-Kj5QqI X-Barracuda-URL: http://antispam.afilias.info:8000/cgi-bin/mark.cgi List-Help: List-Unsubscribe: , List-Subscribe: , X-ASG-Orig-Subj: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt - Digital signatures X-Barracuda-Connect: mail02.afilias.info[69.46.107.12] X-Barracuda-Start-Time: 1184069666 X-Barracuda-Virus-Scanned: by Afilias Spam Firewall at ca.afilias.info X-BeenThere: esds-protocol@afilias.info X-Mailman-Version: 2.1.8 x-virus-scanned: ClamAV 0.88/3620/Mon Jul 9 21:30:39 2007 onmail00.afilias.info x-envelope-to: x-spam-checker-version: SpamAssassin 3.1.7 (2006-10-05) on mail00.afilias.info x-spam-status: No, score=-100.0 required=5.0 tests=USER_IN_WHITELIST autolearn=ham version=3.1.7 x-virus-status: Clean x-asg-whitelist: Sender x-x-sender: fot@fermi.int.libertyrms.com This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C800F3.24C5E0E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > > > 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 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 Esds-protocol@afilias.info https://mailman.afilias.info/mailman/listinfo/esds-protocol ------=_NextPart_000_0016_01C800F3.24C5E0E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt = - Digital signatures

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
Esds-protocol@afilias.info
http= s://mailman.afilias.info/mailman/listinfo/esds-protocol

------=_NextPart_000_0016_01C800F3.24C5E0E0-- ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail00.afilias.info (localhost [127.0.0.1]) by antispam.ca.afilias.info (Spam Firewall) with ESMTP id 8C8505461A; Tue, 10 Jul 2007 03:45:05 -0400 (EDT) Received: from [207.219.45.62] (helo=antispam.ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I8APf-00047e-UM for kstevenson@ca.afilias.info; Tue, 10 Jul 2007 03:45:35 -0400 Received: from mail00.afilias.info (localhost [127.0.0.1]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l6A7j3Kg001082; Tue, 10 Jul 2007 03:45:04 -0400 Received: from mail00.afilias.info (mail02.afilias.info [69.46.107.12]) by antispam.ca.afilias.info with ESMTP id kyT6ShwCGwfogV1Z; Tue, 10 Jul 2007 03:45:05 -0400 (EDT) Received: from [62.72.98.58] (port=57900 helo=[10.10.10.93]) by ppsw-3.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.153]:465) with esmtpsa (PLAIN:mgh12) (TLSv1:DHE-RSA-AES256-SHA:256) id 1I8AOz-0001Rn-BL (Exim 4.63) (return-path ); Tue, 10 Jul 2007 08:44:53 +0100 Received: from ppsw-3.csi.cam.ac.uk (ppsw-3.csi.cam.ac.uk [131.111.8.133]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l6A7j0dZ031751 for ; Tue, 10 Jul 2007 03:45:00 -0400 Received: from mail.libertyrms.com (ypres.int.libertyrms.com [10.1.2.16]) by imap (Cyrus v2.2.8) with LMTPA; Tue, 10 Jul 2007 03:45:37 -0400 Return-Path: From: "Mark Harrison" Sender: To: "Frank Thompson" Cc: References: Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt - Digital signatures Date: Tue, 10 Jul 2007 03:44:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C800F3.24C82AD0" X-Mailer: Microsoft Office Outlook 11 X-Sieve: CMU Sieve 2.2 In-Reply-To: Thread-Index: AcfCxk3sJnF04l0/Rmu98HHXpnOhOw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-SA-Exim-Mail-From: esds-protocol-bounces@afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-ASG-Debug-ID: 1184053505-33ed00180000-Kj5QqI X-Barracuda-URL: http://antispam.afilias.info:8000/cgi-bin/mark.cgi List-Help: List-Unsubscribe: , List-Subscribe: , X-ASG-Orig-Subj: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt - Digital signatures X-Barracuda-Connect: mail02.afilias.info[69.46.107.12] X-Barracuda-Start-Time: 1184053506 X-Barracuda-Virus-Scanned: by Afilias Spam Firewall at ca.afilias.info X-BeenThere: esds-protocol@afilias.info X-Mailman-Version: 2.1.8 x-virus-scanned: ClamAV 0.88/3620/Mon Jul 9 21:30:39 2007 onmail00.afilias.info x-envelope-to: x-spam-checker-version: SpamAssassin 3.1.7 (2006-10-05) on mail00.afilias.info x-spam-status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.7 x-virus-status: Clean x-asg-whitelist: Sender This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C800F3.24C82AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >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 >> 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 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 Esds-protocol@afilias.info https://mailman.afilias.info/mailman/listinfo/esds-protocol ------=_NextPart_000_001A_01C800F3.24C82AD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt = - Digital signatures

>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
Esds-protocol@afilias.info
http= s://mailman.afilias.info/mailman/listinfo/esds-protocol

------=_NextPart_000_001A_01C800F3.24C82AD0-- ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail00.afilias.info (mail02.afilias.info [69.46.107.12]) by antispam.ca.afilias.info with ESMTP id k9oLtVgXZaeJWKE6; Mon, 09 Jul 2007 13:57:33 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by antispam.ca.afilias.info (Spam Firewall) with ESMTP id 0E63952D57; Mon, 9 Jul 2007 13:57:33 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l69HvMk2020021; Mon, 9 Jul 2007 13:57:29 -0400 Received: from fermi.int.libertyrms.com ([10.1.2.47]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I7xU8-00088S-9T; Mon, 09 Jul 2007 13:57:20 -0400 Received: from mail.libertyrms.com (vgateway.afilias.info [207.219.45.62]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l69HvKai020011 for ; Mon, 9 Jul 2007 13:57:20 -0400 Received: from mail.libertyrms.com (ypres.int.libertyrms.com [10.1.2.16]) by imap (Cyrus v2.2.8) with LMTPA; Mon, 09 Jul 2007 13:57:36 -0400 Received: from [207.219.45.62] (helo=antispam.ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I7xUM-0008AL-Qb for kstevenson@ca.afilias.info; Mon, 09 Jul 2007 13:57:34 -0400 Return-Path: From: "Frank Thompson" Sender: To: "Mark Harrison" Cc: References: Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt Date: Mon, 9 Jul 2007 13:57:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C800F3.24C82AD0" X-Mailer: Microsoft Office Outlook 11 X-Sieve: CMU Sieve 2.2 In-Reply-To: Thread-Index: AcfCUqG9zZTF2KLQToCNIij7PsrWdA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-SA-Exim-Mail-From: esds-protocol-bounces@afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-ASG-Debug-ID: 1184003853-184800070000-Kj5QqI X-Barracuda-URL: http://antispam.afilias.info:8000/cgi-bin/mark.cgi List-Help: List-Unsubscribe: , List-Subscribe: , X-ASG-Orig-Subj: Re: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt X-Barracuda-Connect: mail02.afilias.info[69.46.107.12] X-Barracuda-Start-Time: 1184003854 X-Barracuda-Virus-Scanned: by Afilias Spam Firewall at ca.afilias.info X-BeenThere: esds-protocol@afilias.info X-Mailman-Version: 2.1.8 x-virus-scanned: ClamAV 0.88/3615/Mon Jul 9 10:28:23 2007 onmail00.afilias.info x-envelope-to: x-spam-checker-version: SpamAssassin 3.1.7 (2006-10-05) on mail00.afilias.info x-spam-status: No, score=-100.0 required=5.0 tests=USER_IN_WHITELIST autolearn=ham version=3.1.7 x-virus-status: Clean x-asg-whitelist: Sender x-x-sender: fot@fermi.int.libertyrms.com This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C800F3.24C82AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > 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 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 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: mark.harrison@cantab.net > > _______________________________________________ > Esds-protocol mailing list > Esds-protocol@afilias.info > https://mailman.afilias.info/mailman/listinfo/esds-protocol > _______________________________________________ Esds-protocol mailing list Esds-protocol@afilias.info https://mailman.afilias.info/mailman/listinfo/esds-protocol ------=_NextPart_000_001E_01C800F3.24C82AD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Esds-protocol] Comments on = draft-thompson-esds-schema-00.txt

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:  mark.harrison@cantab.net
>
> = _______________________________________________
> Esds-protocol mailing list
> Esds-protocol@afilias.info
> http= s://mailman.afilias.info/mailman/listinfo/esds-protocol
>
_______________________________________________
Esds-protocol mailing list
Esds-protocol@afilias.info
http= s://mailman.afilias.info/mailman/listinfo/esds-protocol

------=_NextPart_000_001E_01C800F3.24C82AD0-- ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail00.afilias.info (mail02.afilias.info [69.46.107.12]) by antispam.ca.afilias.info with ESMTP id c7Z1hc6GYSy0QBCU; Mon, 09 Jul 2007 13:44:35 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by antispam.ca.afilias.info (Spam Firewall) with ESMTP id 1B88D52CFE; Mon, 9 Jul 2007 13:44:35 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l69HiWn6014802; Mon, 9 Jul 2007 13:44:35 -0400 Received: from fermi.int.libertyrms.com ([10.1.2.47]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I7xHg-0007ev-Bi; Mon, 09 Jul 2007 13:44:28 -0400 Received: from mail.libertyrms.com (vgateway.afilias.info [207.219.45.62]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l69HiSOP014789 for ; Mon, 9 Jul 2007 13:44:28 -0400 Received: from mail.libertyrms.com (ypres.int.libertyrms.com [10.1.2.16]) by imap (Cyrus v2.2.8) with LMTPA; Mon, 09 Jul 2007 13:44:38 -0400 Received: from [207.219.45.62] (helo=antispam.ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I7xHp-0007fD-Tb for kstevenson@ca.afilias.info; Mon, 09 Jul 2007 13:44:37 -0400 Return-Path: From: "Frank Thompson" Sender: To: "Mark Harrison" Cc: References: Subject: Re: [Esds-protocol] Comments on draft-thompson-esds-commands-00.txt Date: Mon, 9 Jul 2007 13:44:28 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C800F3.24C82AD0" X-Mailer: Microsoft Office Outlook 11 X-Sieve: CMU Sieve 2.2 In-Reply-To: Thread-Index: AcfCUNIEK1iWk8wNR5WE1B9uenFkVA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-SA-Exim-Mail-From: esds-protocol-bounces@afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-ASG-Debug-ID: 1184003075-4fef000e0000-Kj5QqI X-Barracuda-URL: http://antispam.afilias.info:8000/cgi-bin/mark.cgi List-Help: List-Unsubscribe: , List-Subscribe: , X-ASG-Orig-Subj: Re: [Esds-protocol] Comments on draft-thompson-esds-commands-00.txt X-Barracuda-Connect: mail02.afilias.info[69.46.107.12] X-Barracuda-Start-Time: 1184003077 X-Barracuda-Virus-Scanned: by Afilias Spam Firewall at ca.afilias.info X-BeenThere: esds-protocol@afilias.info X-Mailman-Version: 2.1.8 x-virus-scanned: ClamAV 0.88/3615/Mon Jul 9 10:28:23 2007 onmail00.afilias.info x-envelope-to: x-spam-checker-version: SpamAssassin 3.1.7 (2006-10-05) on mail00.afilias.info x-spam-status: No, score=-100.0 required=5.0 tests=USER_IN_WHITELIST autolearn=ham version=3.1.7 x-virus-status: Clean x-asg-whitelist: Sender x-x-sender: fot@fermi.int.libertyrms.com This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C800F3.24C82AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 and 4.2 introduces . > > 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. 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 > command? > What is the motivation for a client to do so? (other than a billing > element for connected time rather than number of sessions) is optional, if the client wishes to issuse 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 > > 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: > > * > > + Desc: if "true" sort results in ascending order on the > basis of the field specified by > > + 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 or > are specified, then both must be specified together, since neither > makes sense without the other also being specified, unless there are > default values for e.g. true and for 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 > > > > > > > > name="objectID" > type="esds:tObjectID"/> > name="type" > type="esds:tEventType" > minOccurs="0" > maxOccurs="unbounded"/> > name="lifeCycleStepID" > type="esds:tLifeCycleStepID" > minOccurs="0"/> > name="subscribe" > type="xs:boolean" > minOccurs="0"/> > name="startingAt" > type="xs:dateTime" > minOccurs="0"/> > name="endingAt" > type="xs:dateTime" > minOccurs="0"/> > name="sorting" > type="esds:tEventSorting" > minOccurs="0" maxOccurs="1"/> > name="limit" > type="xs:int" > minOccurs="0"/> > name="first" > type="xs:int" > minOccurs="0"/> > name="last" > type="xs:int" > minOccurs="0"/> > > > > > > > > > > > name="sortby" > type="esds:tEventSortBy" > minOccurs="1" maxOccurs="1"/> > name="ascending" > type="xs:boolean" > minOccurs="1" maxOccurs="1"/> > > > > > > > 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. > > 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. and p35, section 4.7 > > EventLookup supports - but does not appear > to allow for this. In version 01, the 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 commands. Thus, an would be issued and from the results individual 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)? 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 > > Puzzled why the description for 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 > 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 > Where is the authority attribute of 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: mark.harrison@cantab.net > > _______________________________________________ > Esds-protocol mailing list > Esds-protocol@afilias.info > https://mailman.afilias.info/mailman/listinfo/esds-protocol > _______________________________________________ Esds-protocol mailing list Esds-protocol@afilias.info https://mailman.afilias.info/mailman/listinfo/esds-protocol ------=_NextPart_000_0022_01C800F3.24C82AD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Esds-protocol] Comments on = draft-thompson-esds-commands-00.txt

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=3D"EventLookupIn">
>         = <xs:complexContent>
>          = <xs:extension base=3D"esds:tAbstractIn">
>          =    <xs:sequence>
>          =      <xs:element
>          =        name=3D"objectID"
>          =        = type=3D"esds:tObjectID"/>
>          =      <xs:element
>          =        name=3D"type"
>          =        = type=3D"esds:tEventType"
>          =        minOccurs=3D"0"
>          =        = maxOccurs=3D"unbounded"/>
>          =      <xs:element
>          =        = name=3D"lifeCycleStepID"
>          =        = type=3D"esds:tLifeCycleStepID"
>          =        = minOccurs=3D"0"/>
>          =      <xs:element
>          =        name=3D"subscribe"
>          =        = type=3D"xs:boolean"
>          =        = minOccurs=3D"0"/>
>          =      <xs:element
>          =        = name=3D"startingAt"
>          =        = type=3D"xs:dateTime"
>          =        = minOccurs=3D"0"/>
>          =      <xs:element
>          =        name=3D"endingAt"
>          =        = type=3D"xs:dateTime"
>          =        = minOccurs=3D"0"/>
>          =      <xs:element
>          =        name=3D"sorting"
>          =        = type=3D"esds:tEventSorting"
>          =        minOccurs=3D"0" = maxOccurs=3D"1"/>
>          =      <xs:element
>          =        name=3D"limit"
>          =        type=3D"xs:int"
>          =        = minOccurs=3D"0"/>
>          =      <xs:element
>          =        name=3D"first"
>          =        type=3D"xs:int"
>          =        = minOccurs=3D"0"/>
>          =      <xs:element
>          =        name=3D"last"
>          =        type=3D"xs:int"
>          =        = minOccurs=3D"0"/>
>          =    </xs:sequence>
>          = </xs:extension>
>         = </xs:complexContent>
>       = </xs:complexType>
>
>
>       = <xs:complexType name=3D"EventSorting">
>         = <xs:complexContent>
>          = <xs:extension base=3D"esds:tAbstractIn">
>          =    <xs:sequence>
>          =      <xs:element
>          =        name=3D"sortby"
>          =        = type=3D"esds:tEventSortBy"
>          =        minOccurs=3D"1" = maxOccurs=3D"1"/>
>          =      <xs:element
>          =        name=3D"ascending"
>          =        = type=3D"xs:boolean"
>          =        minOccurs=3D"1" = maxOccurs=3D"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:  mark.harrison@cantab.net
>
> = _______________________________________________
> Esds-protocol mailing list
> Esds-protocol@afilias.info
> http= s://mailman.afilias.info/mailman/listinfo/esds-protocol
>
_______________________________________________
Esds-protocol mailing list
Esds-protocol@afilias.info
http= s://mailman.afilias.info/mailman/listinfo/esds-protocol

------=_NextPart_000_0022_01C800F3.24C82AD0-- ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail00.afilias.info (mail02.afilias.info [69.46.107.12]) by antispam.ca.afilias.info with ESMTP id SbUBEXkOhSN0VTXp; Thu, 05 Jul 2007 11:16:12 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by antispam.ca.afilias.info (Spam Firewall) with ESMTP id A902548613; Thu, 5 Jul 2007 11:16:12 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l65FFmIa000961; Thu, 5 Jul 2007 11:15:48 -0400 Received: from cpc3-cmbg9-0-0-cust176.cmbg.cable.ntl.com ([81.103.20.177]:42558 helo=[10.0.1.2]) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:465) with esmtpsa (PLAIN:mgh12) (TLSv1:DHE-RSA-AES256-SHA:256) id 1I6Rw8-0006Gg-1R (Exim 4.63) (return-path ); Thu, 05 Jul 2007 15:04:00 +0100 Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l65E4DK7007176 for ; Thu, 5 Jul 2007 10:04:13 -0400 Received: from mail.libertyrms.com (ypres.int.libertyrms.com [10.1.2.16]) by imap (Cyrus v2.2.8) with LMTPA; Thu, 05 Jul 2007 11:16:37 -0400 Received: from [207.219.45.62] (helo=antispam.ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I6T4O-00077n-15 for kstevenson@ca.afilias.info; Thu, 05 Jul 2007 11:16:36 -0400 Return-Path: From: "Mark Harrison" Sender: To: Subject: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt Date: Thu, 5 Jul 2007 10:04:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C800F3.24C82AD0" X-Mailer: Microsoft Office Outlook 11 X-Sieve: CMU Sieve 2.2 Thread-Index: Ace/F3rfo2YtaKrZRxG7QHk8eA5Gog== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-SA-Exim-Mail-From: esds-protocol-bounces@afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-ASG-Debug-ID: 1183648572-341200010000-Kj5QqI X-Barracuda-URL: http://antispam.afilias.info:8000/cgi-bin/mark.cgi List-Help: List-Unsubscribe: , List-Subscribe: , X-ASG-Orig-Subj: [Esds-protocol] Comments on draft-thompson-esds-schema-00.txt X-Barracuda-Connect: mail02.afilias.info[69.46.107.12] X-Barracuda-Start-Time: 1183648573 X-Barracuda-Virus-Scanned: by Afilias Spam Firewall at ca.afilias.info X-BeenThere: esds-protocol@afilias.info X-Mailman-Version: 2.1.8 x-virus-scanned: ClamAV 0.88/3604/Thu Jul 5 06:33:34 2007 onmail00.afilias.info x-envelope-to: x-spam-checker-version: SpamAssassin 3.1.7 (2006-10-05) on mail00.afilias.info x-spam-status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.7 x-virus-status: Clean x-asg-whitelist: Sender This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C800F3.24C82AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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 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: mark.harrison@cantab.net _______________________________________________ Esds-protocol mailing list Esds-protocol@afilias.info https://mailman.afilias.info/mailman/listinfo/esds-protocol ------=_NextPart_000_0026_01C800F3.24C82AD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Esds-protocol] Comments on = draft-thompson-esds-schema-00.txt

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:  mark.harrison@cantab.net

_______________________________________________
Esds-protocol mailing list
Esds-protocol@afilias.info
http= s://mailman.afilias.info/mailman/listinfo/esds-protocol

------=_NextPart_000_0026_01C800F3.24C82AD0-- ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail00.afilias.info (mail02.afilias.info [69.46.107.12]) by antispam.ca.afilias.info with ESMTP id bhCTV5Aw76MSeJIp; Thu, 05 Jul 2007 11:15:57 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by antispam.ca.afilias.info (Spam Firewall) with ESMTP id 9D295485F6; Thu, 5 Jul 2007 11:15:57 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l65FFmW5000951; Thu, 5 Jul 2007 11:15:48 -0400 Received: from cpc3-cmbg9-0-0-cust176.cmbg.cable.ntl.com ([81.103.20.177]:42556 helo=[10.0.1.2]) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:465) with esmtpsa (PLAIN:mgh12) (TLSv1:DHE-RSA-AES256-SHA:256) id 1I6RvE-0005vo-2H (Exim 4.63) (return-path ); Thu, 05 Jul 2007 15:03:04 +0100 Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l65E3G9b006861 for ; Thu, 5 Jul 2007 10:03:17 -0400 Received: from mail.libertyrms.com (ypres.int.libertyrms.com [10.1.2.16]) by imap (Cyrus v2.2.8) with LMTPA; Thu, 05 Jul 2007 11:16:36 -0400 Received: from [207.219.45.62] (helo=antispam.ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I6T4N-00076v-B8 for kstevenson@ca.afilias.info; Thu, 05 Jul 2007 11:16:35 -0400 Return-Path: From: "Mark Harrison" Sender: To: Subject: [Esds-protocol] Comments on draft-thompson-esds-commands-00.txt Date: Thu, 5 Jul 2007 10:03:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C800F3.24CA9BD0" X-Mailer: Microsoft Office Outlook 11 X-Sieve: CMU Sieve 2.2 Thread-Index: Ace/F3pH0LyaTEVPTIS+LLmVpQ9Rsg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-SA-Exim-Mail-From: esds-protocol-bounces@afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-ASG-Debug-ID: 1183648557-341200000000-Kj5QqI X-Barracuda-URL: http://antispam.afilias.info:8000/cgi-bin/mark.cgi List-Help: List-Unsubscribe: , List-Subscribe: , X-ASG-Orig-Subj: [Esds-protocol] Comments on draft-thompson-esds-commands-00.txt X-Barracuda-Connect: mail02.afilias.info[69.46.107.12] X-Barracuda-Start-Time: 1183648558 X-Barracuda-Virus-Scanned: by Afilias Spam Firewall at ca.afilias.info X-BeenThere: esds-protocol@afilias.info X-Mailman-Version: 2.1.8 x-virus-scanned: ClamAV 0.88/3604/Thu Jul 5 06:33:34 2007 onmail00.afilias.info x-envelope-to: x-spam-checker-version: SpamAssassin 3.1.7 (2006-10-05) on mail00.afilias.info x-spam-status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.7 x-virus-status: Clean x-asg-whitelist: Sender This is a multi-part message in MIME format. ------=_NextPart_000_002A_01C800F3.24CA9BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit section 4.1.2 introduces a command and 4.2 introduces . 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 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 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: * + Desc: if "true" sort results in ascending order on the basis of the field specified by + Type: xs:boolean + Use: optional, but no more than 1 occurences We might also need to explain that if either or are specified, then both must be specified together, since neither makes sense without the other also being specified, unless there are default values for e.g. true and for 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: 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. 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. and p35, section 4.7 EventLookup supports - but 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 Puzzled why the description for 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 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 Where is the authority attribute of 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: mark.harrison@cantab.net _______________________________________________ Esds-protocol mailing list Esds-protocol@afilias.info https://mailman.afilias.info/mailman/listinfo/esds-protocol ------=_NextPart_000_002A_01C800F3.24CA9BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Esds-protocol] Comments on = draft-thompson-esds-commands-00.txt

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=3D"EventLookupIn">
        = <xs:complexContent>
          = <xs:extension base=3D"esds:tAbstractIn">
          &nbs= p; <xs:sequence>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"objectID"
          &nbs= p;     type=3D"esds:tObjectID"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"type"
          &nbs= p;     type=3D"esds:tEventType"
          &nbs= p;     minOccurs=3D"0"
          &nbs= p;     maxOccurs=3D"unbounded"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"lifeCycleStepID"
          &nbs= p;     = type=3D"esds:tLifeCycleStepID"
          &nbs= p;     minOccurs=3D"0"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"subscribe"
          &nbs= p;     type=3D"xs:boolean"
          &nbs= p;     minOccurs=3D"0"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"startingAt"
          &nbs= p;     type=3D"xs:dateTime"
          &nbs= p;     minOccurs=3D"0"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"endingAt"
          &nbs= p;     type=3D"xs:dateTime"
          &nbs= p;     minOccurs=3D"0"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"sorting"
          &nbs= p;     type=3D"esds:tEventSorting"
          &nbs= p;     minOccurs=3D"0" = maxOccurs=3D"1"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"limit"
          &nbs= p;     type=3D"xs:int"
          &nbs= p;     minOccurs=3D"0"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"first"
          &nbs= p;     type=3D"xs:int"
          &nbs= p;     minOccurs=3D"0"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"last"
          &nbs= p;     type=3D"xs:int"
          &nbs= p;     minOccurs=3D"0"/>
          &nbs= p; </xs:sequence>
          = </xs:extension>
        = </xs:complexContent>
      = </xs:complexType>


      <xs:complexType = name=3D"EventSorting">
        = <xs:complexContent>
          = <xs:extension base=3D"esds:tAbstractIn">
          &nbs= p; <xs:sequence>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"sortby"
          &nbs= p;     type=3D"esds:tEventSortBy"
          &nbs= p;     minOccurs=3D"1" = maxOccurs=3D"1"/>
          &nbs= p;   <xs:element
          &nbs= p;     name=3D"ascending"
          &nbs= p;     type=3D"xs:boolean"
          &nbs= p;     minOccurs=3D"1" = maxOccurs=3D"1"/>
          &nbs= p; </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:  mark.harrison@cantab.net

_______________________________________________
Esds-protocol mailing list
Esds-protocol@afilias.info
http= s://mailman.afilias.info/mailman/listinfo/esds-protocol

------=_NextPart_000_002A_01C800F3.24CA9BD0-- ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail00.afilias.info (mail02.afilias.info [69.46.107.12]) by antispam.ca.afilias.info with ESMTP id suIuOPv2Lu7pryeo; Thu, 05 Jul 2007 11:15:57 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by antispam.ca.afilias.info (Spam Firewall) with ESMTP id 7B218485F3; Thu, 5 Jul 2007 11:15:57 -0400 (EDT) Received: from mail00.afilias.info (localhost [127.0.0.1]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l65FFVM9000825; Thu, 5 Jul 2007 11:15:48 -0400 Received: from cpc3-cmbg9-0-0-cust176.cmbg.cable.ntl.com ([81.103.20.177]:42554 helo=[10.0.1.2]) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:465) with esmtpsa (PLAIN:mgh12) (TLSv1:DHE-RSA-AES256-SHA:256) id 1I6RuV-0005eL-0m (Exim 4.63) (return-path ); Thu, 05 Jul 2007 15:02:19 +0100 Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by mail00.afilias.info (8.13.1/8.13.1) with ESMTP id l65E2rnE006729 for ; Thu, 5 Jul 2007 10:02:54 -0400 Received: from mail.libertyrms.com (ypres.int.libertyrms.com [10.1.2.16]) by imap (Cyrus v2.2.8) with LMTPA; Thu, 05 Jul 2007 11:16:00 -0400 Received: from [207.219.45.62] (helo=antispam.ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1I6T3n-00075o-ET for kstevenson@ca.afilias.info; Thu, 05 Jul 2007 11:15:59 -0400 Return-Path: From: "Mark Harrison" Sender: To: Subject: [Esds-protocol] Comments on draft-young-esds-concepts-00.txt Date: Thu, 5 Jul 2007 10:02:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C800F3.24CA9BD0" X-Mailer: Microsoft Office Outlook 11 X-Sieve: CMU Sieve 2.2 Thread-Index: Ace/F2TSxwbMxwCHSIq6KcI31DaMGQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-SA-Exim-Mail-From: esds-protocol-bounces@afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-ASG-Debug-ID: 1183648557-249100150000-Kj5QqI X-Barracuda-URL: http://antispam.afilias.info:8000/cgi-bin/mark.cgi List-Help: List-Unsubscribe: , List-Subscribe: , X-ASG-Orig-Subj: [Esds-protocol] Comments on draft-young-esds-concepts-00.txt X-Barracuda-Connect: mail02.afilias.info[69.46.107.12] X-Barracuda-Start-Time: 1183648558 X-Barracuda-Virus-Scanned: by Afilias Spam Firewall at ca.afilias.info X-BeenThere: esds-protocol@afilias.info X-Mailman-Version: 2.1.8 x-virus-scanned: ClamAV 0.88/3604/Thu Jul 5 06:33:34 2007 onmail00.afilias.info x-envelope-to: x-spam-checker-version: SpamAssassin 3.1.7 (2006-10-05) on mail00.afilias.info x-spam-status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.7 x-virus-status: Clean x-asg-whitelist: Sender This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C800F3.24CA9BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 () 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 () at which the event was generated by the client system. The ESDS also records a separate timetamp () 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: mark.harrison@cantab.net _______________________________________________ Esds-protocol mailing list Esds-protocol@afilias.info https://mailman.afilias.info/mailman/listinfo/esds-protocol ------=_NextPart_000_002E_01C800F3.24CA9BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Esds-protocol] Comments on = draft-young-esds-concepts-00.txt

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.or= g/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.or= g/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:  mark.harrison@cantab.net

_______________________________________________
Esds-protocol mailing list
Esds-protocol@afilias.info
http= s://mailman.afilias.info/mailman/listinfo/esds-protocol

------=_NextPart_000_002E_01C800F3.24CA9BD0-- ------=_NextPart_000_0033_01C800F3.24CA9BD0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ESDS mailing list ESDS@ietf.org https://www1.ietf.org/mailman/listinfo/esds ------=_NextPart_000_0033_01C800F3.24CA9BD0--