RE: [security-services] Dual implementations for each SSO binding?

[Scott Cantor <cantor.2@osu.edu>]

> I take your point that in some situations two mechanisms that provide
> essentially the same functionality may be required. But we have two
> mechanisms already ! browser artifact and browser POST. Each has quite
> different properties that may be suited to one situation or 
> the other. 

I think the issues are orthogonal to each other. POST vs artifact generally
relates to the ability to have the callback at all, based on what I've
gleaned.

The GET vs POST thing has more to do with the client's capabilities, and the
POST option seems to be the last resort option because the response is too
big.

Yes, it's a mess, but this is a browser use case....and there are some awful
weird browsers out there in wide deployment.

> FORM Post. We have also provided technology in SAML 2.0 to ensure that
> assertions can be encrypted, so the browser POST contents can 
> be hidden from the eyes of the user agent (and their disk cache). 

Maybe it's me, but this is where I have to sort of wonder...supporting XML
Encryption strikes me as 10 times harder than any of the GET/POST/artifact
stuff on the table. I just can't help feeling the arguments about complexity
aren't focused on the wrong areas.

> So why do we need even more implementation choices for these solved
> problems?

I have to assume the people who argued for these options originally didn't
feel they were solved.

> It would be really helpful if the end-users or vendors interested in any
> of the additional variations stand up and identify themselves.

No argument there...

> Speaking now as a representative of an ISV, I have to say 
> that some of the choices we seem to be making in SAML 2.0 (and, yes, even
> some choices made in ID-FF 1.2) are going to be a large burden to
> implementers and act as a brake on broad implementation. 

Maybe so, but I want to be clear...*all* of this is in ID-FF. The *only*
thing I added was the artifact generalization, and I have no problem
disregarding that for particular protocols...I think it's only needed in the
AuthnRequest protocol.

And people have implemented ID-FF, so...

It does strike me that if this stuff is deemed too complex, I can safely
ignore web services for the foreseeable evolutionary epoch...'cause that
stuff is string theory compared to this.

-- Scott