[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?
> I would think that the more straightforward and clear, the better. I'm > not claming to be an expert in identity protocols by any means but I > have implemented a few of them and have spent a fair amount of time with > the SAML 2 spec and it is not at all clear to me exactly how this is > suppose to work. I suspect that I won't be the only one that has > difficulty with it. Straightforward and clear can also mean "overly constrained". I think it would be much clearer, for example, if I knew what KeyInfo is supposed to have in it, but we say nothing about it. In the scheme of things, that bugs me a *lot* more as an implementer. I don't think it's "supposed to work" in the same way across all implementations internally. I viewed AllowCreate (and Terminate less so) as deployment knobs. All I see is a protocol flag that triggers pluggable behavior in implementations based on some very general guidelines. It would help me a lot if I understood what was *different* in ID-FF such that what was clear there is somehow not clear here. Because I just don't see it. There were no rules in ID-FF around what implementations did internally in response to this "federation" thing. Nor any rules about what you deleted in response to Termination. It was also perfectly legal in ID-FF to use a long-term persistent ID if the deployment had no use for pseduonyms. The only difference was you couldn't really tell because it was all a single NameID Format, or at least was unspecified. If you can explain to me what the "federate" flag was supposed to mean there, it might spark an idea on what could be said here. I'm not trying to pass the buck, but rather I'm trying to understand what it is about the language now that is apparently more confusing. My take was that before, the old specs may have implied you had to do certain things that were basically contradicted by the ability to do other things that were clearly allowed. So whatever they may have explicitly said, it wasn't something you could just assume. -- Scott