[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] some changes in requirements draft 3
>okay, tokens can also be used for signing and encrypting. My point stays >the same - none of those are the problem we're trying to solve here. We're >trying to allow a DSS signing service to communicate facts about the >requestor's authentication to someone verifying the signature. SAML >Assertions allow you to speak about different authentication events - with >SAML, the service can say "Alice authenticated at time X using Kerberos", >or "Bob authenticated at time Y using an X.509 certificate". >So a SAML Assertion can serve to describe any other type of >authentication. Kerberos tickets or X.509 certificates are specific >authentication mechanisms, they don't have this descriptive capacity. >So I'm not saying we should choose SAML over other authentications >methods. I'm saying we should choose SAML because it can *describe* these >other methods. Security tokens are all about claims, claims can be *any* statement and they can be signed or unsigned. Security tokens are containers for all sorts of claims. So security tokens can represent requestor's authentication to someone verifying the signature. This just points out that we should not limit the specification to SAML assertions, I agree that they are one way to represent the fact that an authentication of some sort has taken place. >So I'm not saying we should choose SAML over other authentications >methods. I'm saying we should choose SAML because it can *describe* these >other methods. SAML is not an authentication method Anthony Nadalin | work 512.436.9568 | cell 512.289.4122 |---------+----------------------------> | | Trevor Perrin | | | <trevp@trevp.net>| | | | | | 04/10/2003 11:49 | | | PM | |---------+----------------------------> >----------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Anthony Nadalin/Austin/IBM@IBMUS, dss@lists.oasis-open.org | | cc: | | Subject: RE: [dss] some changes in requirements draft 3 | >----------------------------------------------------------------------------------------------------------------------------------------------| At 09:56 PM 4/10/2003 -0500, Anthony Nadalin wrote: >WS-Security does not *authenticate* the user based upon tokens, where did >you get this ? Tokens in WS-Security have many usages, authentication may >be just one usage. okay, tokens can also be used for signing and encrypting. My point stays the same - none of those are the problem we're trying to solve here. We're trying to allow a DSS signing service to communicate facts about the requestor's authentication to someone verifying the signature. SAML Assertions allow you to speak about different authentication events - with SAML, the service can say "Alice authenticated at time X using Kerberos", or "Bob authenticated at time Y using an X.509 certificate". So a SAML Assertion can serve to describe any other type of authentication. Kerberos tickets or X.509 certificates are specific authentication mechanisms, they don't have this descriptive capacity. So I'm not saying we should choose SAML over other authentications methods. I'm saying we should choose SAML because it can *describe* these other methods. >You may think that SAML is the best, that's fine but the >specification needs to be flexible I think using SAML does give us flexibility, since a SAML Assertion can speak about any type of authentication mechanism. Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]