Anyway, that’s just techie stuff. Let’s not ge to bogged down in it. I think the real significance of law 5 is along the “trust fabric” axis. There needs to be a plurality of choices among the parties participating in the trust fabric. For example, in the famous Dick Hardt talk, beer buyers can present different cards frpm different motor vehicle departments (IdPs) that will provide testimony about their age. The beermonger (RP) will accept any of them.

And a side note for what it’s worth. Perhaps there’s another “orthogonal” axis. This comment was posted from a Macintosh!

You are&nbspright we need to agree to disagree, but I can’t help sharing what bothers me about the “optional” approach (and this comes from experience at having built systems that suffered from the problems I’m describing). I think it will be both SIMPLER and SAFER to keep each token quite tightly defined, so switching TOKENS switches defined SETS OF BEHAVIORS in their entirety rather than creating 100,000 potential combinations - many of which can be dangerous and all of which have to be tested.

Interesting comments about the signature problem. Yes, I’d like to work on this with you.

Agree that the mechanisms should not be specific to WS-Trust!

As far as the schema is concerned, most of the assertion content is in fact optional, and I disagree that there’s no value in that approach. A common token is IMHO a prerequisite for any real/useful commonality in the identity layer. That’s where we’ll have to agree to disagree and just advocate for what we think is best.

A sidenote: the ID thing is actually more of an XML signing problem than a SAML problem. To sign things right now in XML, you either have to rely on unique identifiers or on very hard to process XPath mechanisms. The uniqueness thing does predate the heavy use of signing in SAML, but the real challenge in relaxing it comes from the third-party signing use case.

I hope that people can work together to come up with new signature specs that accomodate the new crypto work and fix some of these limitations. And I think we would agree that they should not be specific to WS-Trust.

I don’t know that Microsoft would have been any wiser in&nbspguiding SAML than those who developed the specification were. After all, it was very forward thinking and solved a number of problems.

It might have made everyone feel better today if my ideas about a payload-agnostic protocol were aimed at improving a technology Microsoft was partly responsible for, but I wouldn’t change anything I was saying or doing.

You don’t need special cryptography as long as you are willing to employ “bearer tokens” to convey&nbspnon-unique assertions. You do need blind signatures once you want to associate tokens&nbspwith proof keys. The work of Stefan Brands and Jan Camenisch makes this all possible - both have shipped toolkits recently. But as you say, the traceable ID and IssueInstant in SAML would be non-starters.

As an aside, I don’t think it’s enough to remove a couple of XML attributes to avoid the correlation attack you’re talking about. I think it requires non-traditional cryptography to present a signed claim of anything from a third party in such a way that the whole bag of bits can’t be used as a correlatable handle. It’s doable, but it’s not doable with typical approaches to encryption or key proofs. At least I don’t think it is.

(That’s not to say the limitation you raise isn’t legitimate. It’s a necessary fix, just not a sufficient one.)