[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] New Issue: AssertionID/ WSS Direct reference compatability
> Paul Cotton, sent the following references to the WSS TC. I don't > claim to completely understand their content, but it seems that > the ability to recognize identifier attributes without the schema > is a problem that is getting some attention, and that we should > consider making the SAML 2.0 schema compatible with the inclusion > of an externally defined identifier attribute. I'm glad to know the work is apparently happening, I hadn't noticed it, mostly because Xerces hasn't implemented it, I guess. It looks like some parsers have. But this still seems like a mess. Putting wsu:Id into the root element along with ID seems nuts to me, even if it's legal. As others have noted, it's crazy to require the issuer to know whether the assertion will be used that way. This is just a mistake by WSS, IMHO, that breaks with any XML token. It would be *better* to just declare the wsu:Id attribute as the SAML assertion ID for all cases, and when that's your better option, something seems wrong. I don't really see how xml:id changes things. It doesn't solve WSS' problem (which seems self-inflicted to me anyway) unless the WSS spec is changed, and just adds yet another ID attribute into the mix. Frankly, the reasoning behind xml:id was a lot stronger before DOM3. I can still see that it's a good idea for XML, but it's not helpful for SAML 2.0 implementers the way it would have been for 1.0/1.1. If it was implemented widely, I'd say use it for sure, but I don't see how we can today based on a quick look around. That doesn't leave a lot of options, since we have to have an ID attribute of some sort today. Seems like: - we leave <saml:Assertion> alone and somebody defines a wrapper element for WSS use that can carry wsu:Id - we replace ID with wsu:Id in <saml:Assertion> for all uses Independently, we could add <anyAttribute> to the root elements in the schemas just to future proof things a bit, but wildcards don't get around the limitation of a single ID and you've got three competing agendas there trying to grab one element. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]