RE: [security-services] Some tech overview comments

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

> Well, I don't see what you're suggesting we do --within the scope--
> a SAML V2.0 TO should properly claim.

I'm doing nothing but agreeing with Brian (and perhaps going beyond) by
saying that any examples that don't specifically pertain to ECP should not
use ECP or anything that is derived from ECP as an illustration.

The rest was in response to what you sent and had nothing to do with the TO
at all.

> > Well, FWIW, I don't think the word WAP should appear in the TO.
> 
> And the SAMLv2.0 Profiles? It was in there last time I looked, but
> going by memory for now. Perhaps that historical path should not
> be overlooked in helping folks understand this mechanism?

I didn't say anything about the profiles document. I don't think this small
bit of confusing history is relevant to explaining something that has moved
beyond that history, and I certainly don't think it's important in the TO.
It's beside any point the TO is trying to help explain.

> And it seems we're kind of in agreement about *existing* work,
> which is, isn't it, the kind of work that many, many, folks just
> coming to SAML V2.0 will be dealing with?

Yes.

> While you rightly point out that given a lot of design latitude
> you might do something entirely different, I've seen folks think
> of ECP as a panacea, and get mired.

I've seen at *least* that much from people that start with the browser
profile, so if you're arguing that's going to work better, I would have to
disagree. It leads to a lot really broken and wacky profiles.

> I'm talking, e.g., about
> designers ALREADY in command of a fully-capable embedded user
> agent, in deployment, thinking they "want" or "need" to add SOAP,
> etc. in order to deliver basic SAMLv2.0 capabilities. Something
> is wrong with that. And I suspect the TO has contributed somewhat
> to that.

I wouldn't disagree with that (again, I didn't really disagree with the TO
aspect of this thread).
 
> s/requires enhancement/requires or offers enhancement/

I think that probably would have bothered me less.

> I fully favor even basic ECP when actual client enhancements are
> actually on offer. I would love to see a fuller explanation of
> how that works, or could work. But that, it seems to me, strays
> into these other design advice areas, and threatens to create
> an imbalance in what should be, basically, a simple elaboration
> of how to understand the specification.

Yes, I agree. Nice to have it, but not here.

> In that vein I restrained myself, for example, in that second
> bullet, from elaborating on the ways in which discovery can be
> enhanced, or the ways in which the principal could be assisted
> with enhanced services, even such as UIs. This is just a bit
> beyond a neutral TO, and also somewhat outside of SAMLv2.0's
> scope (even with shades of the dashed-line controversy, for
> a third/fourth time).

That I disagree mildly with, in the sense that this focus on keeping inside
the lines is a big contributor to SAML's "over-abstractness" and inability
to compete with alternatives that don't play nicely inside the abstract
boxes.

Which is to say, I'm not arguing that we should avoid it in the TO for now,
but it's past time SAML profiles stop leaving everything out of scope. We
argue for days over things like AuthnInstant and still leave 90% of the work
to deployers without seeing there's a problem there. That's probably the
cause of my overly grumpy response.

-- Scott