Re: Unique identifier of the Voucher Component

[Ian Grigg <iang@systemics.com>]

Hi all,

(I think I've been blind CC'd by Mr Fujimura, apologies
for leaping in here.)

Ko Fujimura wrote:

> > I suggest that in the next version of this an ID attribute should be
> > added to voucher. To assure uniqueness, we might also recommend that the
> > ID value be the based64 of a hash of the Exclusive Canonicalization
> > <http://www.w3.org/TR/xml-exc-c14n> of the voucher element with the ID
> > attribute dropped out. That is, something like
> >
> > Base64 ( SHA1 ( ExclusiveCanonicalization (
> >            XPath ( voucher,
> >                    ( //. |
> >                      //namespace::* |
> >                      /@[ localname() != Id ] |
> >                      /descendant::node()/@
> >                    ) )
> > )))

I would fully approve of using the SHA1 of the "voucher"
as the unique identifier.  We've been using this with
Ricardian Contracts since 1995, and it has worked well.

In fact, it is a critical piece of the architecture,
allowing for a reduction of administration over all
other payment schemes that exist.  It literally
eliminates the need to control the issuance of new
contracts ("vouchers" in your system), which massively
expands the applicability.  It also enforces agreement
on the text of the contract with very little adminstration.

(It is critical to get the canonicalisation correct, of
course.  But you seem to already have that under control.)

> Thank you for inputting a good idea. Actually, I received a comment
> below about 3 month ago regarding this issue:
> 
> > > > We are currently working on a project where tickets are
> > > > stored in a central system and
> > > > can be sold by retailers using a POS terminal in a shop. The
> > > > terminal communicates
> > > > via GSM (SMS/internet/direct) to the central system.
> ... (snip)
> > > > So here they are:
> > > >
> > > > 1. We need some unique number for every type of ticket to
> > > >    identify the ticket.
> > > >    If the terminal ask for a certain type of ticket we want
> > > >    to search for this ticket-type in the central database.
> > > >    I was looking for adding this number in the 'issuer'
> > > >    part, but I think there needs
> > > >    to be some global authorization organization for ticket
> > > >    identifiers. What are you're thoughts about this?
> 
> I have been reluctant to add ID attribute to <Voucher> because
> I think an implementation may use the hash value of the whole
> Voucher Component as the unique identifier of the <Voucher>.
> In this case, I thought it impossible to define the hash value
> as the value of ID attribute within the <Voucher>, which is the
> subject to calculate the hash value. But, Donald's idea enables
> us not to include the hash in itself. So, I agree to add ID
> attribute to the <Voucher>. Any opinions?

I wonder why you would want to do that?  Thinking in
normalisation terms (c.f. Codd) this is a duplication
of information.  Thus, you would have to think of the
case for the wrong identifier being in place.  This
would be a bug, and would introduce complications into
the architecture.

I thought this morning about how I would add the digest
to the Ricardian Contract and realised that it would
break the notion of the contract.  Part of the security
of the system resides on the ability for all parties to
agree on the text, via the compression into the digest.
By offering a short cut, this would introduce a security
flaw into the Ricardo architecture which would impact on
a lot of the governance.

Now, maybe your vouchers are not necessarily considered
to be contractually strong, in the Ricardian sense, so
maybe you don't face the same security concerns.  And,
maybe there is a reason for caching the number.  But I
don't see it.

In practice, digest cycles are cheap.  I would suggest
that you want to look carefully at calculating the digest
on the fly rather than storing it in the voucher.  And,
if it were cached, consider very carefully what that
means, and why!

-- 
iang