RE: [dss] requirements draft 4

[<Frederick.Hirsch@nokia.com>]

It might be relevant to a relying party to have information from the DSS
on the "level" of authentication without requiring knowledge of the details.

The Liberty authentication context outlines such an approach. [1] 

An authentication context statement might be appropriate in a DSS server response.

regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones

[1] https://www.projectliberty.org/specs/draft-lib-arch-authentication-context-v1.2-05.pdf



> -----Original Message-----
> From: ext jmessing [mailto:jmessing@law-on-line.com]
> Sent: Friday, May 02, 2003 8:46 AM
> To: dss@lists.oasis-open.org; Trevor Perrin
> Subject: Re: [dss] requirements draft 4
> 
> 
> 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.
> 
> 
>