[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] comments re draft-sstc-metadata-iop-03
Tom Scavo wrote on 2009-02-12: > As a very specific example, the Metadata Interoperability Profile does > not work within TeraGrid, a large grid deployment in the US. Would it help if I added language essentially stating "if you think X.509 works, stop reading"? More seriously, it sounds like it would help if there was language in the motivating text that talks about the overlap and explains that the profile is essentially aiming at deployments that don't have a PKI that they have confidence in the runtime behavior of. Speaking to your example directly, I don't really see what the use of metadata buys you at all. It makes sense that you would align the metadata to the naming that is already present at the layer of the credentials that already have to be trusted. But I think it makes more sense to just drop the layer out, actually... > Nor do I think X.509-based grids are an isolated example. If you look > at the Kerberos white paper that we discussed on the last concall, one > of the stated objectives is to "Leverage SAML metadata to enable > large-scale Kerberos cross-realm communities." Of course it's too > early to say exactly what that might look like, but coming off my > experience integrating SAML with X.509, I'd be willing to wager that > SAML metadata in a Kerberos environment can not be shoe-horned into > the Metadata Interoperability Profile. No, I would have to disagree. On the contrary, it would be *because* of that profile that one could simplify the use of Kerberos by leveraging the trust mechanisms the metadata can supply. If one were to go back to the use of X.509, well, Kerberos already supports that, I believe. I think we also see the strategies for integrating these things in virtually the opposite way, which is perhaps why we're not meeting minds on this. > But there is no evidence to the contrary. WS-Federation Infocard The query extension you mentioned Use of SAML within ID-WSF All of those protocols and profiles, where they have touch points with SAML trust evaluation, can be implemented more cleanly via this profile. > The SAML metadata > specification, like much of the SAML specification set, is biased > towards Web Browser SSO. The fact that we have a "Metadata Extension > for SAML V2.0 and V1.x Query Requesters" is testimony to this fact. No, it's testimony to the fact that we had a whole lot of work to do and stuff got missed that wasn't as important to the authors. What it proves is *my* point. You add that extension and it has no impact on the validity of the profile. > Once you move away from Web Browser SSO, you find less of what you > need in the SAML specifications and end up rolling your own. The metadata roles are specific to the profiles that were developed in the TC at the same time. That has nothing to do with this profile, which is extensible to roles that didn't even exist (at least schematically) when the ideas were being developed. As you've noted many times, it's a stretch as currently written to even call it a metadata profile, when it basically just deals with KeyDescriptor. That element is in the role base type, which by definition means it applies to any role in the same way. > So I think the onus is on you to show that the scope of the Metadata > Interoperability Profile transcends Web Browser SSO. I could say that I think I just did, but I don't really believe your premise is valid. There's nothing in SAML metadata as a framework that is specific to the SSO profile, and this profile doesn't even mention it (I don't think). -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]