How best to import eduGAIN metadata? There are at least two options:
Option 1. Offer two aggregates:
where the latter contains eduGAIN metadata in addition to InCommon metadata.
Option 2. Tag every entity descriptor in the production aggregate with a new entity attribute value such as:
and then import eduGAIN metadata directly into the production aggregate.
Option 2 is strongly preferred since this method of distinguishing between InCommon metadata and eduGAIN metadata persists even if the entity descriptors are exposed as signed, per-entity metadata. Option 2 has the following additional advantages:
Import eduGAIN metadata directly into the production aggregate. Start by importing IdP metadata from eduGAIN since the impact on InCommon SPs is less than what it will be for InCommon IdPs.
As a general rule, a new entity attribute precludes the need for another aggregate. Consumers simply filter entities from the production aggregate on the basis of entity attributes.
Tag every entity descriptor in the production aggregate with a new entity attribute value (
Since the production aggregate will grow without bound, InCommon should deploy a production-quality metadata query server (mdq.incommon.org) that serves all the metadata of the world. All deployments should be advised to configure the following chaining metadata provider:
<MetadataProvider type="Chaining" precedence="first"> <MetadataProvider type="XML" ... /> <MetadataProvider type="Dynamic" ... /> </MetadataProvider>
In other words, every deployment is provisioned with an aggregate, which it checks first. If the deployment finds the metadata it's looking for in the aggregate, it uses that, otherwise it calls out dynamically to the query server. This allows a deployment to initially consume some subset of the production aggregate based on entity attributes.
Bring the beta metadata query server (mdq-beta.incommon.org) to production (mdq.incommon.org) as a distinct server environment (i.e., distinct from md.incommon.org).