RE: [dss] some changes in requirements draft 3

[Trevor Perrin <trevp@trevp.net>]

At 11:43 AM 4/11/2003 -0400, jmessing wrote:

>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.

SAML was designed to be extensible.  Groups like Liberty and WS-Security 
have added new <AuthenticationMethod>s and <ConfirmationMethod>s.  So I 
don't think it would be too confusing to extend things with a new 
authentication method, even if this method is "human-based" instead of 
"computer-based".



>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.

The use of "strings" was tentative, maybe a better idea is to use an RFC 
3280 GeneralName in CMS, which is tagged to differentiate between name 
forms like email addresses, Distinguished Names, URIs, and so on.

Since CMS uses ASN.1, and DSIG uses XML, I think it's appropriate to use an 
ASN.1 data type (GeneralName) as a signed attribute for CMS signatures, and 
an XML one (SAML) for DSIG signatures.  It's true that a SAML Assertion can 
represent more facts about the authentication, as opposed to just the 
identity, than a GeneralName, so maybe we should also allow SAML Assertions 
as signed attributes in CMS, it's worth discussing.



>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.

I don't understand.  The relying party has to trust the DSS Service to 
speak authoritatively about the sender's identity and authentication no 
matter what, what format we encode this in is an orthogonal issue.


>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.

The documents you reference just use an <AuthenticationType> or 
<AuthenticationMethod> element to specify different authentication 
methods.  SAML uses an <AuthenticationMethod> element for the same 
purpose.  So I don't see how SAML is any less neutral, and SAML certainly 
has broader industry support.

Trevor