RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded

["Greg Alvord" <galvord@attglobal.net>]

MISMO, Mortgage Industry Standards Maintenance Organization has a 1.0
specification for eMortgages called SMARTDOCS.

The over all structure is three fold <DATA/><MAP/><VIEW/>.  <VIEW/> content
is the XHTML presentation the borrower sees.  <DATA/> contains ... well
data. <MAP/> is composed of a collection of <ARC/> items that reference an
ID in the data section and on in the XHTML. A transform may be required, for
example a loan amount of $100,000 may need to be expressed in the XHTML as
"One Hundred Thousand Dollars and no cents" in order to meet the legal
requirements.

Signatures are applies to this structure:
1. The document provider creates a manifest of the text sections of the
XHTML and signs it to provide assurance that the document text has not been
altered.
2. After the organization that "fills in" the form finishes a manifest and
signature are created covering the data items that are now "frozen", their
arcs, and the XHTML sections presenting the data.
3. The borrower's electronic (not necessarily digital) signature is added as
well and any "open" last minute data, arc and view sections. Another
manifest and digital signature is applied using the certificate of the
"closing agent".  This may, for example, include, an image of the borrower's
signature.
4. The document travels to a recording entity (usually a county) where the
recording data filled in and a signature manifest of the recorders data, and
the other signatures is signed with the certificate of the recoding
entities.

There are additional steps along the way of an eMortgage. This scheme was
originally developed by Fannie Mae and is becoming the mortgage industry
standard.

I think this is an example of the kind of transforms and signing Gregor is
referring to. It does result in the data, the transforms and the resultant
XHTML being signed.

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Tuesday, March 25, 2003 2:38 PM
To: Gregor Karlinger; robert.zuccherato@entrust.com
Cc: ML OASIS DSS
Subject: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded

At 04:43 PM 3/25/2003 +0100, Gregor Karlinger wrote:

>Robert & Trevor,
>
>I would like to make a clarification regarding the use case
>"Securing The Transform Chain" I have submitted to the group:
>
>It seems that in the requirements draft there is a mix up of
>two different stories:
>
>   1. The use case "Securing The Transform Chain" (which has
>      been the first part of my message "Use cases and
>      requirements input" sent to the list on Wed, 15 Jan
>      2003 [1].
>
>
>   2. A collection of requirements regarding digital signature
>      services in general (which comprise the second part of
>      that message).

Okay.  I think all your general requirements are incorporated into section
3, in various places.  So we should change 2.7 to just mention the
particular aspects of your use case.  I have a question about the use case,
though:

You mention using transforms to make XML data human readable (by turning it
into HTML, say), and then signing the XML data along with the transforms,
so the relying party can reconstruct exactly what the signer saw when he
was signing.

But then the XML data isn't really signed, so the relying party can't do
anything with the XML itself - the transform might have turned the XML into
something completely different.  So if all this accomplishes is
transmitting signed HTML, why not just send signed HTML in the first place?

It seems that, if you want the relying party to process XML, the XML itself
needs to be signed, not a transformed, human-readable version of
it.  Presenting the to-be-signed data to the signer in an agreeable format
is the problem of the signer's application software.

Now if that software wanted to add a signed attribute containing the HTML,
or some transforms on the XML, to specify "this is what the signer actually
saw", that might be a good idea, and could be used to resolve disputes
about the signer's intent.  Should we modify the use case to something like
that?

Trevor