[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] Metadata, IdP Disco, AuthnRequest, etc...
> I can see that having the SPs get the IdP metadata is hard, too, and > I never meant to imply it was easy; I do think the IdP disco service, > even as flawed as we both agree that it is, could help immensely by > returning the (signed) metadata if asked to do so. I think the > redirect-with-identifier behavior should be preserved, too, but it's > not much additional complexity to have a flag indicating "post me the > signed metadata, please", and I think it's well worth it. SP > reliance on that is probably not ideal, but in the absence of a > better discovery mechanism... Well, I think in terms of our needs as an implementer, we wanted a spec to write to that would be stable in time for us to ship, and we were asked to offer it to the TC. I would suggest that we consider this as a follow on. It may be possible through the policy extension point in the profile or it may require formally altering it, perhaps something you could look at. (But you're also welcome to join a call and argue for getting it in now, I just don't personally have that on my agenda as the original co-submitter.) > Plus you still have to get it signed, and > that poses problems for SPs and IdPs in a multiple-federation > environment -- presumably you want the same entityId on a given > provider for all federations, but each federation will have its own > signing cert, so ... Yes, but that's why it's hard to split it all up. Who signs it? In the batch approach, each federation can just collect up what it signs and there's no ambiguity about the signer. > Even with the existing distribution schemes, except for the batch > load, you've got the problem of getting it signed piecemeal and > putting it on each SP. Maybe I wasn't clear...I actually don't think piecemeal works well in conjunction with signing. Until there's some kind of explicit service that can be leveraged to get trusted metadata more dynamically, I think batch is the simpler way to go, and I haven't been able to get my mind around a model where it's both distributed in content but still vetted by a third party. My experience has been that the people arguing for distributing the information are also advocating unsigned metadata, typically by that meaning they use an SSL cert or something, but I don't really find the notion comforting (as I don't think you do). > Batch downloads solve the problem, but rely on batch processes. Well, we should distinguish bulk from batch. Batch is one way, but the real point is that's it's centrally hosted and signed. It can be fetched and monitored in real time or batch. > I'm just arguing for flexibility in the protocol to allow metadata to > be more dynamically distributed. Use it, don't use it, it doesn't > matter, as long as your fellow federation members can follow along (a > matter of federation policy, I'd think, or maybe a metadata flag). I'm fine with that, I'm just trying to understand some of your assumptions better. I'm obviously not the gatekeeper here (apart from somebody asking me to actually author specs, which you're not). > As far as nitty gritty details, I think saml:Advice is obviously the > way it would go for assertions (not saying it's overly useful, but > there for completeness); a samlp schema modification at the level > necessary to do this (ie, a modification to the > samlp:RequestAbstractType) would probably be less-than-good, so > samlp:Extensions for the request. Thoughts on that? It's an Extension, that's what it's there for. It's explicitly an optional thing (in the sense that metadata is always somewhat non-normative), so it fits fine. My questioning was intended to better understand the scope of what you were suggesting and how it would address (or not address) certain problems. Clearly an SP that knows enough about an IdP to send it a request can include its metadata in the AuthnRequest and you could drive pretty much the rest of the process with it. If you wanted to just say that the SP needs to know only the SSO service information, then I suppose an IdP could include its metadata as well. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]