RE: [dss] some changes in requirements draft 3

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

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

Contrary to this assumption, a relying party does not have to trust any one or any thing it is not comfortable trusting. Suppose A wants to borrow money from D. A promises to repay the money with interest. D will insist on the promise being enforceable before D will part with the money. A's signature is a way to accomplish the goal, if the signature is legally enforceable, which depends in large part, but not exclusively, on whether A is really A. Unless D is assured within the limits of D's comfort level of both of these points (enforceability and identity), the transaction will not be accomplished.

If A tenders to D a note that is signed by C, a DSS allegedly acting on behalf of A,  and incorporates a SAML assertion that C identified A on the basis and within the validity period of a SAML assertion by B about A's identity, D may well respond "so what?" unless at the very least, D is also willing to trust B's authentication assertion. Otherwise, the SAML assertion is superfluous. From D's point of view, it is equivalent to saying that the man in the moon vouches for A's identity.

The SAML assertion in this case means little to D's concern that it may never get repaid.

D should also want to know, even if it does trust B on the basis of a digital identifier like, for example, a security token, what steps were taken to assure that A was really A when the digital identifier was first given to A or generated by A, and even afterwards in terms of maintenance of the security of A's token. The first of these considerations is often considered to be out of spec in the writing of standards, yet it is critical to D's concerns.

IMO, this has been one of the chronic problems of electronic signatures in general and PKI in particular. Relying parties have been generally unwilling to trust the human and technology decisions about identity and their legal enforceability sufficiently to part with value in exchange for promises. Unless the spec can help solve the problem, it too may make little headway in this area.