RE: [dss] some changes in requirements draft 3

["jmessing" <jmessing@law-on-line.com>]

With regard to another method: 

We spent a considerable time in the LegalXML CourtFiling TC looking at ways of describing electronic signature information consistently with interoperability that could convey information useful to a relying party. We were also mindful of the provisions of the federal eSign law that required technology neutrality. 

We came up with two tags that we felt were useful: 1. <AuthenticationMethod> or <AuthenticationType>, and 2. <DataIntegrity>. 

These were incorporated into the CourtFiling 1.1 and CourtDocument 1.1 DTD's that were approved by a Joint Technology Commission of COSCA-NACM, which are membership bodies of court officers that are entrusted with these kinds of standards decisions within the US state court systems by a Conference of Chief Justices. 

In the CourtDocument 1.1 Specification, http://www.ncsconline.org/D_Tech/Standards/Documents/CourtDocument11-rev1/CourtDocument11/CourtDocument_11(rev1).html 
these were discussed in section 6.4.10. 

I wrote an unofficial note rather early on that explained some of the ideas we were working on. http://www.legalxml.org/archive/LegalXMLwebsitefiles/DocumentRepository/UnofficialNotes/Clear/UN_10009_2000_02_02.htm 

I have a number of issues with trying to squeeze the syntax exclusively into SAML Assertions for the sake of interoperability. First, creating new categories of SAML assertions that are not part of SAML is likely to generate considerable confusion. 

Secondly, recognizing that at least CMS will not fit neatly into this syntax, a separate category called "strings" is created, which is not SAML and does not create the kind of interoperability you seem to be looking for. Why this one exception is created and others resisted is unclear except that you personally feel this one exception is justified and appropriate. 

Third, using SAML may make some sense where a relying party upon the signature has already agreed to trust the SAML assertions of a particular domain, but not necessarily otherwise. 

Fourth, using SAML may be viewed as favoring one type of Single Sign On Solution over another, which may inject extraneous considerations that can distract from the issue of what information is needed for relying party purposes when generating a signature using a DSS. 

I would prefer a different way of approaching the issue. The LegalXML way may be sufficiently neutral and appropriate for our purposes, with some work, refinement, additions and tweakings. 

---------- Original Message ----------------------------------
From: Trevor Perrin <trevp@trevp.net>
Date:  Thu, 10 Apr 2003 23:00:34 -0700

>At 01:23 AM 4/11/2003 -0400, jmessing wrote:
>
>>However, none of these assertions apply to eNotarization in the presence 
>>of a notary, as the notary does the authentication in person. So... at 
>>least one use case is automatically excluded by this choice. Why is that 
>>desirable or laudable?
>
>A SAML Authentication Assertion could have an <AuthenticationMethod> of 
>"unspecified", or a new AuthenticationMethod could be defined to represent 
>notary-style human authentication.
>
>Is there a better solution that you're thinking of?
>
>
>Trevor 
>
>