[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] some changes in requirements draft 3
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]