[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] SAML Public key authentication methods
Hi John, I agree that the current SAML 'AuthenticationMethods' would be actually better described as 'AuthenticatorVerificationMethods' (or perhaps TokenTrustModel). Distinguishing between, for instance, X.509 and PGP could be relevant to the SP in 'ranking' assertions and so we should be able to express in Authentication Context. With respect to the current list of key-based SAML AuthenticationMethods, XKMS seems somewhat of an oddity. By listing it along with X.509 etc, we give the impression that it is alternative to the others and would be valid in isolation, as opposed to being an interface in to some other key management/verification infrastructure. With respect to the relevant Authenticator, as it currently stands it would seem that 'DigSig' (authentication through signing) or 'AsymmetricEncryption' (authentication through proof of decryption) are the available options for these key-based SAML AuthenticationMethods. If we choose to, we could also further differentiate 'DigSig' according to the nature of the information that was signed, i.e. 'challengeplaintext' or 'randomplaintext'. Paul >-----Original Message----- >From: John Kemp [mailto:firstname.lastname@example.org] >Sent: Monday, May 03, 2004 11:09 AM >To: email@example.com >Subject: [security-services] SAML Public key authentication methods > > >Hi, > >In trying to map the SAML authentication methods to authentication >context classes, I've hit a snag, regarding the mapping of the >individual public key methods (X509 public key, PGP public key and so >on). These are called out separately as distinct >authentication methods. >However, it seems to me that the actual authentication >mechanism is not >specified in these cases. Instead, we are specifying how the key was >verified. So, I have a couple of questions/comments for the group: > >1) Is information regarding the actual verification of the key, rather >than the actual authentication mechanism, important in describing the >authentication event? If so, then we should model this in the >authentication context, probably by adding an attribute to the >authenticator to hold the "validation mechanism". >2) Unless I'm not understanding this correctly, it seems to me >that the >authenticator in all of the these public key cases is some kind of >digital signature over some piece of content. > >I'd appreciate thoughts on this matter as I aim to complete the >authentication context/method changes this week. > >Cheers, > >- JohnK > >To unsubscribe from this mailing list (and be removed from the >roster of the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/security-services/ members/leave_workgroup.php.