[
Lists Home |
Date Index |
Thread Index
]
<Quote>
I would be interested to know what this organisation had in mind when
using the terms "presentation", "content" and "context".
</Quote>
I should respectfully clarify that this was not an organization, but a
federal-sponsored pilot comprised of federal employees,
contractors/consultants, and vendors (such as Adobe and PureEdge)
getting together to study issues related to e-forms.
Here is more information on the terms, from a document that was produced
by the Security subteam of the pilot:
<Terms>
PRESENTATION:
The presentation describes how the XML data will be presented to the
user and rendered on the user's device. It may also define the user
experience of the interactive elements of the form.
[goes on to discuss SVG and XML as examples]
CONTENT:
The data content of the form is provided by the application or a user.
From a security perspective there are three types of content, based on
the degree of cryptographic protection;
[goes on to describe unsigned, signed, and encrypted content]
CONTEXT:
The context is any information deemed necessary by the application that
needs to be stored with the content to assist in its interpretation or
to ensure the document is trustworthy (when this is needed). This may
include information such as the role the user held during the session,
the assurance level assigned to the issuer of the user's credentials,
the jurisdiction in which the user was deemed to be operating, the
source of the authority the user as deemed to have invoked, etc.
</Terms>
More on context, from the U.S. Department of Justice document "Legal
Considerations in Designing and Implementing Electronic Processes - A
Guide for Federal Agencies" (November 2000[1]):
<DOJDocument>
"The legal significance of context surrounding the collection or
creation of electronic information"
Any information collection system should provide a means to define,
limit and show the context of the information supplied to the extent it
is necessary for a particular transaction. For example, a "form" to be
filled out may require specified information to be supplied on
particular lines or in boxes, and such forms usually are accompanied by
explanatory instructions. Completed paper forms include a means of
identifying not only the answers, but also the questions and
instructions. The meaning of the answers is evident from the document
itself.
Electronic processes that use "forms" generally display a template of
the form to the person filling it out. The person enters the
information requested by the form. If the system is designed to retain
and reproduce only the answers, and not the questions or instructions,
disputes may arise over the meaning of the information supplied.
Knowing an answer without knowing the corresponding question is of
little value. Electronic submission systems generally should be
designed to provide a copy of the form (including all questions and
instructions) in response to which information was supplied to the
agency, or bind the form to the answers provided. If an agency's forms
change over time, and the information on the form is important either to
the underlying transaction or to an agency process or program, then the
electronic process should be designed to keep track of the exact form
used by each submitter of information.
</DOJDocument>
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
[1] http://www.cybercrime.gov/eprocess.htm#IIC1
Mark Seaborne wrote:
>
> This is the kind of scenario that John has outlined on the XForms list, and for which both InfoPath and XForms appear to be lacking at present.
>
> I would be interested to know what this organisation had in mind when using the terms "presentation", "content" and "context".
>
> All the best
>
> Mark
>
> The information in this email is sent in confidence for the addressee only and may be legally privileged. Unauthorised recipients must preserve this confidentiality and should please advise the sender immediately of the error in transmission. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on its content is prohibited and may be unlawful.
>
> Origo Services Ltd accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or the contents.
>
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Sent: 29 October 2003 13:52
> > To: Mark Seaborne
> > Cc: Michael Champion; xml-dev@lists.xml.org
> > Subject: Re: [xml-dev] InfoPath Digital Signature controversy?
> >
> >
> > Earlier this year, the U.S. Federal CIO Council conducted an "E-Forms
> > for E-Gov" pilot in which I participated (PureEdge did as
> > well). One of
> > the points that was brought out in Section 6.7 (Archival
> > Records Domain)
> > of the final report [1] was the importance of binding together
> > presentation, content, and context:
> >
> > <Quote>
> > Briefly, the National Archives and Records Administration (NARA)
> > guidlines require that the "presentation", "content", and
> > "context" must
> > be bound together in such a way that they can be demonstrated
> > to belong
> > to the same transaction. This may mean physically combining
> > these into a
> > single physical file, or ensuring that they are bound together through
> > some other trusted means, such as electronic hashes and signatures. In
> > addition, any signature must be applied to this combination of
> > presentation, content, and context, and the authentication
> > process must
> > ensure integrity.
> >
> > For most government applications, E-Forms solutions must be
> > designed and
> > selected with these core archival requirements in mind.
> > </Quote>
> >
> > Kind Regards,
> > Joe Chiusano
> > Booz | Allen | Hamilton
> >
> > [1] http://www.fenestra.com/eforms/deliverables/final_report.htm
begin:vcard
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard
|
