Shibboleth Developers

["Scott Cantor" <>]

> From a technical perspective, though, Scott's always telling us that 
> federations don't exist in the code.  If the word "federation" has any 
> technical meaning at all, then, I'd hand-wave that it's a collection of 
> entity metadata that you trust because you trust the signer; each 
> signer, in this view, *forms a federation* by virtue of the set of 
> entity metadata they sign whether in one metadata document or many.

That's pretty close to my view.

> [The trust roots in current PKI-based federations complicate this logic, 
> of course, so let's just imagine we've moved beyond that and are talking 
> about having keys rather than key names in the metadata.]

They don't really...they only work because the metadata signer says to trust
them for those entities. It's a blessing that the name bindings of those CAs
are accepted by the signer. Without the signer, the CAs are meaningless.

This assumes signed metadata at all, of course. Any given site can install
metadata as they see fit.

> So, I'd argue that going to a "one big signer in the sky" model is 
> essentially opting for one big "Verisign federation".

Yep. Actually, it's more the case I think that you wouldn't expect Verisign
to sign anything, but simply use Verisign SSL certs to host the metadata
files over SSL. I think that amounts to self-assertion. It's saying that if
you lie to me, I'll sue your butt under some existing contract, so there's
no incentive to lie.

> This would apply similarly to any other extensions we might feel the 
> need of within specific communities.  In the end, the ability to talk 
> about policy *within some community* is the added value that I see in a 
> federation signature over and above merely registering endpoints.

Endpoints are a reasonable thing to self-assert. Keys or keynames, not so
much maybe. Maybe if the keynames are directly implied by the endpoints, but
not otherwise. I don't know. Maybe it's all just self-assertion anyway, so
why not just admit it.

> There is of course an argument that good metadata is context-free and 
> that things like scoped attributes were A Bad Idea.

It might be a separate question whether they were a bad idea vs. whether
using metadata to control them is a bad idea. Of course, metadata's not the
only way...AAP files also can control them.

> I can certainly 
> believe that the sort of thing I'm talking about here isn't what the 
> SAML TC had in mind when they wrote the metadata spec.  I don't know 
> whether Scott might like to comment as to whether the mindset was that 
> metadata was context-free or merely that its context was *implied*.

To me, metadata containing keys is a kind of certificate, and certificates
have policy and context all over the place. Of course, I think PKI is a
failure too, so...

> The other alternative that might be worth exploring if we're talking 
> about plug-in metadata resolution would be to invent a resolver that 
> resolved metadata for a particular entity ID by querying a RESTian 
> service at some (configurable) federation-specific URL for the metadata 
> for that specific ID.  The only difference between this and a single 
> metadata file with a single signature would be that it would scale 
> better to large federations.  Coincidentally, I've been thinking about 
> setting up just such a service for the SDSS federation for other reasons.

That's certainly not an illegal thing to do. Should we get everybody to put
in NAPTR records in DNS so that DDDS resolvers can get referred to the
federation? ;-)

-- Scott