RE: [dss] some changes in requirements draft 3

[Anthony Nadalin <drsecure@us.ibm.com>]

>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