Re: [dss] requirements draft 4

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

The distinctions you have drawn undoubtedly should be refined but some of the items you have listed are useful generally for continued discussion purposes.

You wrote:

>So I sort of think we have a 3-layer stack:
>
>  Signature Profiles
>---------------------
>  Core DSS Protocol
>---------------------
>  Protocol Bindings
>
>The Core Protocol specifies the mechanics of sending data to be signed or 
>verified and receiving the result.
>
>Protocol Bindings specify how transport, authentication, confidentiality, 
>and integrity are supplied to the core protocol.
>
>Signature Profiles specify the interpretation of signatures produced by the 
>core protocol.
>
>I think we should first tackle the core protocol, since that's the one 
>piece everything depends on - then we (and other people) could supply 
>bindings and profiles to make the core protocol useful in particular 
>environments.
>
>
In designing the DSS protocol, care should be taken to distinguish signing from verification. 

With regard to signing, authentication of the signer is paramount. This statement is equally applicable to a single shared key of an enterprise as it is to a multi-user XKMS service. A relying party must know the degree to which it can trust an identity assertion of a DSS in order to determine the suitability of a generated signature to its needs. It will also need to know, where an individual signs on behalf of another person or entity, that the signature has been properly authorized.

However, authentication of identity and authorization will not play a part in a signature verification by a relying party, who will only verify the cryptographic signature of the DSS. Verification of a legal signature should only have to involve cryptographic verification of the key and where relevant, the certificate chain. All the rest is based upon trust by a relying party in the DSS. This trust is the primary commodity that the DSS will offer to users. 

Therefore, your apparent concerns are unfounded, IMO, that allowing the DSS protocol to specify various incompatible authentication mechanisms may complicate interoperability and thus "open a can of worms". A relying party will trust the DSS's statement of how it authenticated a signer without having to verify the authentication on its own. Whether the authentication information is semantically expressed as SAML, or WSS, or another way, the relying party will necessarily trust the DSS in this regards. It has no way to verify the authentication method on its own, and likely has no interest.

Therefore, your attempts to shoehorn all authentications into a SAML syntax to avoid interoperability issues is based upon a false premise.

If later a signer claims that he or she is not properly associated with a transaction, then with regard to authentication, the problem should be that of the DSS, not the relying party, because that assurance is what the relying party purchased. 

It is therefore important to provide in the protocol standardized ways of expressing the trust relationships to a relying party so that it knows what it has purchased by way of assurance, can do "comparison shopping" based upon clearly understood terms,  and can provide understandable proof to a court later in ways that are uniformly expressed through a DSS protocol.

If you proceed to develop a DSS protocol solely as a technical matter upon which later other levels, including assurance levels, can be engrafted, then a risk is created of missing an ingredient that is needed later in the process, and winding up with a perfectly designed technical specification that in the end has little real world use and will have to be redesigned from scratch. This is a less than ideal way of proceeding for those with practical business and legal needs to solve.