OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]