RE: [dss] some changes in requirements draft 3

[Trevor Perrin <trevp@trevp.net>]

At 07:22 AM 4/10/2003 -0500, Anthony Nadalin wrote:


>We had this issue in WS-Security, we did not want to have to have the extra
>baggage of SAML just to do a assertion (when the requestor or recipient did
>not support SAML), so we defined a basic element that allowed one to assert
>a name and then we allowed for additional profiles that could use SAML,
>Kerberos, X509, XrML, etc to provide an assertion
>
>     <wsse:UsernameToken wsu:Id="...">
>         <wsse:Username>...</wsse:Username>
>     </wsse:UsernameToken>
>
>There are quite a few assertions that exist today in legacy systems, such
>as Kerberos, one should also be able to use these, especially since
>symmetric keys can be used for signing.

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.

So in the case where the signing service wants to give details about the 
authentication, I think a SAML Authentication Assertion is the best 
approach.  However, in some cases the signing service might not want to 
give these details, and might just want to give the requestor's name.  In 
this case, using a full SAML Authentication Assertion may be overkill, we 
could do something simpler.  On the other hand, there's something to be 
said for consistency, so I dunno.

On the subject of WS-Security, this document on the SAML profile of 
WS-Security has a few interesting things:
http://www.oasis-open.org/committees/download.php/1048/WSS-SAML-06.pdf

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.

On lines 213-214, and 286-289, they mention some issues with including SAML 
Assertions (or references to remote ones) within a dsig:Reference, which is 
what we're trying to do too.  In particular, the question of whether to 
sign the reference to a remote Assertion, or the remote Assertion itself.


Trevor