[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Some tech overview comments
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]