OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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:john.kemp@nokia.com]
>Sent: Monday, May 03, 2004 11:09 AM
>To: security-services@lists.oasis-open.org
>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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]