W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2000

RE: SignaturePropert(y|ies) type identifier

From: Gregor Karlinger <gregor.karlinger@iaik.at>
Date: Mon, 29 May 2000 09:52:41 +0200
To: "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Message-ID: <NDBBIMACDKCOPBLEJCCDIELJCFAA.gregor.karlinger@iaik.at>
Hi Joseph,

> The other approach is to place an ID attribute in SignatureProperty, which
> seems like a better idea. So the identifier is the same, and
> SignatureProperty now has an ID. The grammar for SignatureProperty and
> SignatureProperties permits multiple instances of both, and that begs the
> question of what the semantic meaning is. Now, the grammar doesn't
> explicitly say this, it just states that you can place arbitrary
> content in
> an Object, and consequently you can repeat SignatureProperties if you so
> decided. But there's also the questin of where the Target
> attribute properly
> sits. Options:
> A. Remove all Targets; the SignatureProperty can only apply to
> the Signature
> it is within. (What if nested?)
I am sorry, but I do not understand this question. If we restrict the
to be applied only to the signature they are within, I do not see a problem
with nesting. Can you please give an example?

If we make this restriction (I do not see an argument against it), I suggest
to reject the SignatureProperties element at all, since it only works as
an additional "container" level between Object and SignatureProperty, but
nothing else.

> B. One and only one SignatureProperties per Signature, which includes a
> Target attribute that defines to which Signature the SignatureProperty(s)
> apply. (Remove Target from SignatureProperty(s)).

In this case I also suggest to reject SignatureProperties. Instead, supply
each SignatureProperty element with an Id AND a Target attribute.

Regards, Gregor
Gregor Karlinger
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Received on Monday, 29 May 2000 03:52:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:33 UTC