Shibboleth Developers

[Ian Young <>]

Chad La Joie wrote:

> There is nothing that says the signature needs to be with a key specific 
> to a federation.

I can see what you mean here, if what you're saying is that the entity 
that signs metadata need not be related to the organization (political 
entity) that we tend to call a federation.

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.

[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.]

> I think if we went to this model, and I know where 
> you're coming from when you worry about scalability, you have some big 
> entity in the sky that everyone trusts sign your data.  All you're 
> really after from that signature is the assurance it provides that the 
> keying info and metadata binding is good.  A Verisign like entity could 
> provide that functionality.

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

This kind of thing works for SSL certificates because what Verisign 
means by the action of signing an SSL certificate is pretty well 
understood.  All they are doing is asserting that the holder of that key 
owns that cn, really.  It's easy to see how a wide community can agree 
that Verisign can make such assertions reliably; the assertions are 
unambiguous, relatively easy to verify and most importantly context-free.

If metadata were similarly only a binding of context-free attributes to 
a name, I'd probably reluctantly accept some signer in the sky (or more 
likely, as with SSL, multiple signers) as workable.  However, even our 
existing use of metadata goes beyond that with things like the Scope 
extension.  Which scopes an IdP is allowed to use is a policy question, 
not a factual one; and it is an important one, too, if you use scoped 
attributes for anything.  So, it's contextual; different communities 
might have different policies they want to enforce about their allocation.

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.

There is of course an argument that good metadata is context-free and 
that things like scoped attributes were A Bad Idea.  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*.

> I hate to even suggest, because the topic is an absolute quagmire, but 
> if we really insisted on having a federation sign the metadata, 
> federations could investigate cross-signing and bridging PKI.  I think 
> such a solution would be a monumental kludge prone to huge heartache, 
> but you might be able to get it to work.....  maybe.

I have to admit I'm a sceptic on this front.  My admittedly surface 
understanding of how things like the federal cross-certification thing 
works with respect to things like LOA to prevent absolute assertions 
being necessarily trusted by people elsewhere in the tree doesn't make 
me feel happy suggesting it as something we want to get into.

Other than scaling back what we can do with metadata, or thinking up 
some way of getting contextual metadata out of the entity ID location (I 
notice that Scott has just posted something on this, saying 
"authentication, however done"), I can only think of another couple of 
options.

One would be to take anything that might be context-dependent and push 
it down into per-federation (per-context) containers that were 
extensions.  These could be federation-signed but you could have more 
than one and the overall metadata (including the context-independent 
stuff like endpoints) could be covered by an overall signature from a 
source trusted to speak for the federation-independent components.  Roughly:

EntityDescriptor
   Signature (overall)
   Extensions
      FedSpecific fed="fed1"
         Signature (fed1-specific)
         fed1-specific stuff here
      FedSpecific fed="fed2"
         Signature (fed2-specific)
         fed2-specific stuff here

This looks... less than beautiful, but I thought I should include it for 
completeness.

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.

Again, this would work best in the context of multiple resolvers that 
were queried in turn, starting with locally held metadata.

        -- Ian