[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] some changes in requirements draft 3
However, none of these assertions apply to eNotarization in the presence of a notary, as the notary does the authentication in person. So... at least one use case is automatically excluded by this choice. Why is that desirable or laudable? ---------- Original Message ---------------------------------- From: Trevor Perrin <trevp@trevp.net> Date: Thu, 10 Apr 2003 21:49:54 -0700 >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]