MHonArc v2.5.0b2 -->
legalxml-courtfiling message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [legalxml-courtfiling] Strawman non-repudiation issues
From: "Scott Came" <>
To:
Date: Wed, 4 May 2005 09:46:25 -0700 (PDT)
Comments inline...
> It is my understanding that we introduced the Entity Seal that as provided by DSS
to help create a new method of
> non-repudiation that was separate from the messaging layer.
The
key here is to base our implementation of non-repudiation and integrity requirements on XML Signature.� In the Web
Services Messaging Profile, we would get to XML Signature via WS-Security.� Other profiles may use other methods to
represent the hash (a digital signature is, of course, just a specific type of hash), but I think we should consider
using XML Signature in other profiles--why invent a new vocabulary for representing signatures when a perfectly usable
open standard already exists?
> We have also agreed within Blue that there is a
> separation
between authentication of the message layer and who actually signs or approves the submission.
Dallas, I
don't know what "authentication of the message layer" means.� Hopefully the New Orleans minutes will
illuminate this issue.� I thought we were moving towards using mechanisms like SAML to represent authentication
tokens, and XML Signature for non-repudiation an integrity requirements.
> Using the
> message
layer security would restrict any possible non-repudiation to just the sender, which may not be the signer of
> the documents.
Again, I don't know what "message layer security" means.� Using XML
Signature does not force the restriction you suggest.� Anyone with a digital certificate (private/public key pair) can
sign the SOAP body (or specific parts thereof) and attachments.� Signatures can also be layered (e.g., I sign the
document, you sign the document and my signature, etc.)� In the Web Services profile, using WS-Security, this is
implemented as SOAP headers; other profiles would likely have their own way of structuring the signature information,
hopefully leveraging the XML Signature vocabulary.
>
> I have not had time to read the
documents posted yet, so I recognize that I have some work to do before I give further
> comment, however, for
each attachment there needs to be a block of data that includes the information about who is
> authorizing or
signing the document,
Each profile needs to handle this requirement; the Web Services Messaging Profile
will handle it via WS-Security.� Those who would satisfy the non-functional requirements via a different profile would
be obligated to specify how that profile would handle it.� I would hope the TC would favor open-standard
implementation mechanisms, like XML Signature or at least S/MIME.
> and from New Orleans we agreed to a
either a hash or a digital signature per
> attachment,
Ditto previous comment.� WS-Security handles
this fine.
> and then strongly recommend the Entity seal around the package,
Please define
term "package".� It would be possible (I think...we should confirm) to create a single signature
(represented as a header using the XML Signature vocabulary) for the SOAP body and all attachments.� Has this notion
of "entity seal" made it into the non-functional requirements yet?
> and that all these items
be embedded
> within the envelope, which we now have agreed to in New Orleans to be embedded in within the
body element of SOAP.
Are we abandoning the notion of profiles, or was this decision made in New Orleans
with respect to the Web Services messaging profile?� I would strongly disagree with having the Web Services messaging
profile place signature information in the SOAP body.� This contradicts the WS-Security and WS-I standards.
Even for non-WS profiles, I would suggest a term other than "envelope" here.� It has a specific meaning
for SOAP, and according to that meaning, saying that the "envelope [is] embedded within the body element of
SOAP" is non-sensical.� In SOAP, the envelope contains headers and a body.
> My
>
interpretation of this is that what we once referred to as the legalxml root element is now the body element of SOAP.
> This does not mean that when you use SOAP messaging layer you can eleminate the requirements within the
body.
>
> Dallas
>
