RE: [dss] some changes in requirements draft 3

[Trevor Perrin <trevp@trevp.net>]

At 07:09 PM 4/10/2003 -0500, Anthony Nadalin wrote:





> >I think SAML is different than these other assertion types, in that it can
>
> >represent" them.  Ie, SAML can say "the user authenticated with Kerberos,
> >X509, etc.".  Since our interest is in communicating the facts of an
> >authentication between a DSS signing service and a relying party, it would
>
> >be good to reduce things to a single format (like SAML) that can represent
>
> >different authentication types, so the relying party only has to
>understand
> >this single format instead of knowing how to speak Kerberos if the
> >requestor authenticated to the signing service with Kerberos, and so on.
>
>I'm not convinced that SAML is the only assertion that should be used as
>speciifc tokens can do that just fine without going through the overhead of
>converting to SAML.

Then the relying party needs to process the specific token (Kerberos 
ticket, X.509 certificate, whatever).  That makes interoperability harder 
to achieve.  Furthermore, the relying party doesn't need to know the 
specific token the requestor used to authenticate - the particular Kerberos 
ticket you presented to the DSS service to authenticate is of no use to the 
relying party.

WS-Security supports different token types because it *authenticates* the 
user based on these tokens.  We aren't doing that.  We are just 
*representing an authentication*, and I think SAML's the best format for that.


> >On lines 164-169, they talk about a reference to a remote assertion that
> >specifies not just the URI of the Assertion, but also which SAML protocol
> >binding to use to retrieve it, and which key to search on for it.  I guess
>
> >we'll need to do the same, for referencing remote assertions.
>
>Why isn't the WSS-SAML Profile just used ?

We're not WSS.  But maybe we should borrow some things from it.

Trevor