[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Trust management and validation viametadata
> Well, I'm not going to argue that point too loudly. We're debating exactly > that in our project, that's partly why I'm asking these questions. If nobody > else is implementing anything like this, that sends a message. OTOH, my > sense is that people are using ordinary PKI and trust lists to deal with > SSL, but perhaps not so much with signatures. I think that's inconsistent > for users, and I'm bothered by the fact that the metadata can't express the > configuration rules to apply for both cases. But it can with some pretty > simple extensions. I'm becoming convinced based on discussions here and in the Shib project that while managing a trust configuration in a fine-grained way is really important for a SAML installation, and there are motivations to do so interoperably and in a way that supports trust config distribution, that this isn't SAML work, and shouldn't be done as extensions to SAML metadata. The fact we can refer to an entity's key easily using existing metadata, and that that key can be used directly for validation, leads to the notion that more complex validation could be expressed as an add-on. But the presence of a key in metadata also doesn't say how that key comes to be trusted for validation; that comes from, say, the metadata being signed, and that signature being validated by trust anchors or some such; stuff that is not represented in the metadata itself (and can't be, really). There is definitely important work in mapping application-specific naming and validation and constraint requirements into some common infra that can rely on PKI (whether traditional or new-age) for scalability (eg Paul Madsen's "Machine Assisted Trust Mechanisms for Grids" paper from a couple of years ago), and having that at hand would definitely help SAML deployments interoperate, but it would help lots of other layered security infra scale and interoperate too. So I'm inclined to say that this work should be pursued independently (unless of course the TC wants to take it up as a new work item, which would likely need a rechartering discussion). - RL "Bob"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]