RE: Some possible rqmt/design points

Gents,

I would re-state Dave's comment a bit differently. There are two flavors of
attribute, those that apply to the business logic and those that apply to
the signature process. Among the former we can distinguish two categories.
The attributes that apply to the data content and those that apply to the
signature content.

Preferably, attributes that apply to the content should be sealed into the
body of the document. However, if we assume that there could be an XML-based
equivalent of CMS (signature envelope), then it is really worth considering
content attributes in the signature block. Though it should be quite simple
to define a new XML element for combining such attributes and the document
body, this would require development of a new piece of software while an
of-the-shelves toolkit could have been sufficient. Support for attributes in
CMS has been proven very valuable in many circumstances.

On another hand, attributes that apply to the signature process should be
sealed into the signature manifest and should be represented by specific XML
elements (i.e. SignatureAlgorithm, Resource ...). However, depending on our
ability to par with new requirements and to update the specification in a
timely fashion, it might be worth considering a means that could be used for
extending this set of attributes. Allowing insertion of simple Name/Value
pairs in the signature block could be also worthwhile in such circumstances.

Finally, there are attributes that intrinsically apply to the business logic
but explicit properties of the signature block. Some could be common and
shared across applications while others might be very specific (i.e. eCheck
Signature Purpose, IOTP Signature Referent ...). Furthermore, it has been
noticed that some would like to attach properties on a per resource basis.
For example, a resource attribute could explicit the application-type of an
external resource, thus saving the application core from fetching content
that it does not care about.

Now, with regard to attribute criticality, I agree with Dave in that
criticality should be a matter of the relying party and not of the signer.
In circumstances as the one depicted by Phil ($10,000 limit), I strongly
feel that the attribute should have been sealed in the credential of the
signer rather than in every single signature block produced by the signer.

To conclude, I would suggest that we allow the use of signature attribute
not only on a per signature block basis (Dave's single bucket) but also on a
per resource basis.

Sincerely,

Richard D.

Received on Wednesday, 16 June 1999 14:22:24 UTC