Metadata requireSignedMetadata=false Behavior

[Nate Klingenstein]

> Right, the new (in v3) ability to specify a single key/cert on the filter is really just a convenience, since it's the 99% case probably.  If you want to do advanced things, you do a full trust engine like in v2.

That makes sense and I think it's definitely the 99% case today.  I'm just trying to anticipate what the 10% case might be tomorrow.  This'd be neat as an enhancement to the distribution, but it's obviously not important.

> Just thinking out loud:

This is largely over my head, so I'm going to try to chime in without sounding totally silly.

> We could in theory support something like a Function<XMLObject, Set<String>> on the filter, allowing one to map which trusted credentials' managed by an explicit key trust engine were resolved by the underlying credential resolver, and therefore acceptable for validating a particular signature. I could imagine it being configured via one or more a Map<String,String>.  E.g. Key A is valid for entityIDs  X, Y, Z; key B is valid for EntitiesDescriptors with @name of D, E, F, etc.

That sounds like very appealing functionality to me.  It would certainly be heinous for deployers, but I fear that the alternative of a global oracle 

My dream implementation, if the identity vector idea remains completely rejected, would be a set of cross-signatures between federations ala PGP or the Federal bridge(please don't shoot) and republication of metadata that they have signed at local MDQ servers.  This would use TLS for mutual authentication and encryption between the MDQ server and the IdP, which would grant InCommon's imprimateur as well as the original signatures from the original authorities.

I would like to understand more about whether there is a legal difference between signing something yourself or saying "I have an MOU with this entity and they signed this".  I suspect there is, and that's one reason why I'm pushing on this.

Specifically, I think this would create a marketplace for metadata, allowing providers to select both aggregation and query authorities that they believe are offering the best service.  That gives authorities the opportunity to compete for adoption on merits as well as pricing, rather than a race to the bottom as happened with browser CA's.

I believe that we can definitely compete on merits, but it is hard to compete with corporations on pricing of commodity products, since that's what they're designed to be good at.  Browser-trusted CA rooted certificates are effectively fungible, much like metadata served by a single authoritative MDQ server and a single global MDX that is a universal oracle would be.  We know how that one's gone, and that's why I think we really do want to go there.

The alternative strikes me as not the status quo, but one of the much larger players that are already reaching to become the center of the federated identity marketplace finally succeeding.  All our problems -- attribute release variability, discovery, metadata distribution -- go away as soon as you assume you're one of a handful of IdP's in the universe, so I feel addressing these problems effectively is very important to the continued success of a multilateral model.

> We already did something similar for dynamically constructing the set of PKIX trusted names used in validating the signing cert with the PKIX engines.  Btw, that is the other way to go here for this kind of thing:  PKIX trust anchors (perhaps just 1) that issue signing certs to the parties who then self-sign their own metadata;

The idea of distributed metadata hosted at a URL entityID signed with a key derived from a real trust structure has always appealed to me, but the complete lack of control over what they choose to sign has always pickled me, but that might be something that policy could enforce.

Personally, I really like your first idea, but I would like to hear the opinions of others since it's a controversial proposal.

Signing off from somewhere in rural Nebraska,
Nate.