[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] some changes in requirements draft 3
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]