[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"?
> Does being an IDP basic or extended imply that you must keep per-SP > state about the IDP side of the identifiers too (in order to honor > AllowCreate)? Not unless you add SP-initiated name registration, so with regard to AllowCreate, I see no such requirement. If people see one, then we need to add that to the spec, because I don't see it anywhere, or see how anybody could come to that conclusion. So that means there's obviously confusion over this point. What I see is the spec trying to say (badly) is that IF you maintain such state, THEN AllowCreate means..... That's a big IF, especially when dealing with the more typical kinds of identifiers. > Maybe keeping state is too strong as there way be ways to > honor AllowCreate w/out actual state but I think I gravitate to > describing it as keeping state because that that's what the external > behavior of the IDP looks like. I'm fine with that approach. Because if I'm not maintaining SP-specific state, then I don't see where in the spec I'm obligated to act like I am externally. > Does being a light IDP mean that you must ignore AllowCreate? See other note, but I vote no. > Can a light IDP issue identifiers with the 'persistent' format? If so, > is AllowCreate meaningful in this situation? See other note, but I say yes, if you're willing to live with a suboptimal implementation of it. I doubt AllowCreate could be meaningful, but....I don't what else to say but it depends. Light says what you don't support (NIM), not how you implement what you do support. > If so, is operational mode inferred from the available endpoints in > metadata? If not, what is it based on and how is an SP to know how the > IDP will treat AllowCreate an NIM? How is an SP to know that an IdP supports SHA-256 hashes in its signatures? It can't. It has to be told that. Same here. I don't see why one being "above" the SAML stack and the other "below" changes the fact that both are out of scope of the spec. However (and I granted this), if you want real interop, you better have a profile. SHA-256, of course, is interoperable. Use of AllowCreate at the level we're talking won't be until somebody defines semantics that go beyond what's there. Or we bake those semantics into the core spec and force everybody to follow them. Since we didn't, I think a profile is the right approach here. > A little off topic here but I don't see how NIM can be used to change > the format of an identifier - the <NewID> element in a > <ManageNameIDRequest> is of type string. Seems like all you can do is > change the value. Format is a SAML thing. The NewID can have a different Format attribute value from the old one. That effectively changes the Format of the NameID. I saw no reason to preclude this within the protocol, since core simply doesn't care what Format is involved, transient being about the only exception case. > It sounds like it is still at the IDPs discretion as to if they want to > maintain such sender-imposed state. It seems a bit of a contradiction > that there are situations where a sender can impose state but cannot > know if the receiver is in fact honoring that state. Maybe I'm missing > something here - I don't know. Maybe impose is the wrong word to use. The sender can't impose state except in the case where there's no other way to honor the request. SPProvidedID is the only place in core I see this happening currently, and that happens *after* all this stuff. What I meant was, the sender can't impose state, but might wish to signal to the IdP that it shouldn't create such state if it can't fulfill the request without doing so. Otherwise, you can't clarify the spec any way other than mandating particular implementation strategies. > The wording feels better on first read but I'm not sure it doesn't just > push the problem to a different level. It does. My only goal was to try and unify the treatment of Terminate and AllowCreate more, but I'm still not going the extra mile here. > Who decides if it is not deemed applicable to the identifier? If this > decision isn't normative, then different implementations will have > different interpretations and that can lead to interop problems. I'd like to see an actual explanation of what it is that your SP is going to do based on AllowCreate that somehow "breaks" because of what an IdP does internally. (Or vice versa.) I'm not saying you're wrong, but specifics would help me understand this a lot better. If I send false, then it seems to me the goal is nothing more than to communicate that to the IdP, not force it to behave in a particular way. This isn't the same as IsPassive, as I keep trying to note. > To me, what is important is what behavior the SP can impose on the IDP > with the attribute. How is the SP to know if the IDP implementation > provides such state in the mere issuance of assertions? The same way it knows lots of other things, out of band. There are all kinds of things like that, seems to me. > Is it completely arbitrary and at the discretion of the IDP? Is it > a function of name identifier used? Is it a function of the operational > mode (light or basic/extended)? Or is it something else? I think it's completely at the discretion of the IdP and always has been. > All of the ID-FF implementations I've seen used the Liberty equivalent > of the AllowCreate attribute quite explicitly on the SP side. The SP > would only tell the IDP to allow creation of an identifier if the > principal had authenticated locally at the SP and had not previously > federated his/her identity with that IDP - so the SP knew it was linking > accounts as a result of the SSO. As far as I could tell it wasn't about > user consent it was about having a little control over the state of > linked user accounts. Ok, then explain to me how anything you wrote there has anything to do with the IdP side. What MUST I do? I guess I just don't see it. I never did, and that's why this problem exists. I didn't try and codify things in the spec that I saw no precedent for. The fact that SAML was intended to be more general (granted, that means less interoperable in core) was merely stronger encouragement to take that position. > The spec is about identity so I do think it is appropriate for clear > normative rules about how identity is represented and managed to be at > the lowest levels of the spec. Assuming anybody could really agreee on that in any but a narrow context, I think that probably belongs in a profile of a spec as general as SAML should be. In that sense, AllowCreate is no different than AudienceRestrictionCondition. It means something general, but can be profiled into something much more precise. -- Scott