4 Metadata Publication Service
The UK federation makes metadata available to participants and other partners through its Metadata Publication Service, or MPS.
4.1 Service Implementation
The MPS is implemented using a number of distinct physical computers in multiple geographic locations. At present, up to five computers are in use across two locations, but these details are subject to change without notice to allow for service scaling and maintenance.
The service is accessed through the DNS name
which resolves to both IPv4 and IPv6 addresses (A and AAAA records) for each
machine. These DNS records have a low time-to-live value (currently 5 minutes)
to allow rapid reconfiguration of the service to be performed.
4.2 Service Interface
The MPS makes available a number of defined aggregates, or aggregated metadata documents. Each of these aggregates may be retrieved using a standard HTTP GET method, as defined in [RFC2616] section 9.3.
A MIME media type of
application/samlmetadata+xml is reported for all
aggregates, as required by [SAML2Meta] appendix A.
The most important of these aggregates is the production aggregate, which is located at the following URL:
The production aggregate is intended to be used by all federation participants under normal circumstances.
From time to time, it is necessary to make significant changes to either the format or content of the production aggregate. To allow testing of such changes before they are implemented in the production aggregate, a test aggregate is maintained alongside it at the following URL:
The test aggregate is re-signed and re-published in the same way and at the same times as the production aggregate. This is intended to allow sites wishing to make use of the test aggregate to use it as a direct replacement for the production aggregate without loss of functionality or timeliness. However, as the test aggregate may be used to test experimental features, it is not recommended for long-term use by production deployments.
Although the test aggregate is usually composed of metadata for the same entities as the production aggregate, it may from time to time include additional entities of an experimental nature.
Features initially introduced for testing purposes in the test aggregate are periodically migrated into the production aggregate. In most cases, because notice is usually given to allow participants to verify these features through the test aggregate, no problems are encountered at this stage. However, the MPS also maintains a fallback aggregate to cover transitional problems, located at the following URL:
The fallback aggregate is composed of metadata for the same entities as the production and test aggregates, but omits features that have been only recently introduced to the production aggregate. The delay in introducing new features, normally of around one month, provides a temporary solution for problems which were not detected through use of the test aggregate.
Like the test aggregate, the fallback aggregate is not intended for long-term use by production deployments. Use of the fallback aggregate should always be temporary, and should always be notified to the federation helpdesk.
The MPS publishes an export aggregate, for use by by partner federations as part of inter- federation metadata exchange arrangements, at the following URL:
Entities are currently selected for inclusion in the export aggregate by agreement between the entity’s registrant and the federation operator. In the longer term, the contents of the export aggregate will be based instead on all entities from the normal aggregates which meet appropriate technical eligibility criteria.
An additional export preview aggregate is made available for use by partner federations wishing to test future changes to the standard export aggregate:
Use of any other aggregates published by the MPS is not supported.
4.3 Support for Conditional GET
The large aggregate metadata documents provided through the MPS are normally signed and re-published once every working day. Client software accessing the service more frequently than this may therefore end up repeatedly downloading and re-processing large quantities of redundant information.
To allow clients to optimise their behaviour, the service returns both a last modified date and a strong entity tag value, and supports the use of these values with the HTTP conditional GET mechanism described in [RFC2616] section 9.3.
For example, a successful initial fetch of one of the UK federation’s published aggregate documents might result in the following HTTP response headers, amongst others:
HTTP/1.1 200 OK Date: Tue, 29 Jun 2010 15:53:36 GMT Last-Modified: Mon, 28 Jun 2010 17:58:54 GMT ETag: "9de907-dfb7f380" Content-Length: 10348807 Content-Type: application/samlmetadata+xml
The entity tag and last modified date values returned as part of this initial response could be used as part of a later conditional GET by including the If-None-Match and If-Modified-Since headers in the request:
GET /ukfederation-metadata.xml HTTP/1.1 Host: metadata.ukfederation.org.uk Accept: */* If-None-Match: "9de907-dfb7f380" If-Modified-Since: Mon, 28 Jun 2010 17:58:54 GMT
Note that as described in [RFC2616] section 13.3.4, both of these headers SHOULD always be sent in a conditional GET to the MPS, as both values were provided to the client in the original response. The entity tag value MUST always be sent.
If the requested document has not changed since the initial request, the response headers resulting from this later request might include the following:
HTTP/1.1 304 Not Modified Date: Tue, 29 Jun 2010 15:59:19 GMT Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7d ETag: "9de907-dfb7f380"
Here, the 304 status code indicates that the document has not been modified; in this case, the response body will be omitted.
It is recommended that, where possible, client software designed to access the MPS makes use of conditional GET requests as described above in order to minimise both local processing and load on the service.
4.4 Aggregate Specification
All metadata aggregates published through the MPS conform to the profile described by the following sections.
4.4.1 Aggregate Structure
Aggregate documents published by the MPS currently have a simple “flat”
structure in which all
<EntityDescriptor> elements in the aggregate are
directly contained within a single
<EntitiesDescriptor> document element.
Metadata consumers MUST however be capable of processing aggregates containing
<EntitiesDescriptor> elements, as described in
[SAML2Meta] section 2.
4.4.2 Aggregate Signature Profile
<EntitiesDescriptor> document element of a UK federation metadata
aggregate is digitally signed using a 2048-bit RSA key called the UK federation
metadata signing key, described in section 4.4.3
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
Current best estimates (see, for example, [SP800-57part1] tables 3 and 4) are that the 128-bit security strength believed to be delivered by SHA-256, and the 112-bit security strength believed to be delivered by the UK federation’s 2048-bit RSA signing key, will be adequate through to the year 2030. A transition to an even stronger signature profile is therefore unlikely to be required on security grounds within the next decade, unless significant new cryptanalytic results are reported against either SHA-256 or RSA.
4.4.3 Aggregate Signing Key
The UK federation metadata signing key is published in the form of an X.509 certificate referred to as the UK federation metadata signing certificate.
Metadata consumers MUST verify an aggregate’s signature against this key and MUST reject an aggregate whose signature cannot be verified. This acts as a protection against attacks in which consumers are provided with fabricated metadata.
Verification of the signature against the signing key SHOULD be performed by direct key comparison as described in [SAML2MIOP]. For the benefit of software which cannot implement [SAML2MIOP] and requires the signing certificate to be taken into consideration, the signing key has been re-certified from time to time and re-published as a new signing certificate. The certificate which comes into use in November 2014 has an expiry date in late 2037, so it is not anticipated that this recertification will be performed again.
The current UK federation signing certificate can be retrieved in Base64-encoded form from the following location:
The fingerprints for the version of the signing certificate in use from November 2014 is:
SHA1: AD:80:7A:6D:26:8C:59:01:55:47:8D:F1:BA:61:68:10:DA:81:86:66 SHA256: 89:E5:40:74:AA:05:48:73:BF:A1:41:E8:67:5A:45:31: C9:13:5B:6E:F3:B6:A7:49:DE:7B:B8:62:92:9D:8B:17
The fingerprints for the version of the signing certificate in use from November 2012 to November 2014 are:
SHA1: F9:7F:1A:1E:43:D3:D5:41:6D:C9:D5:0E:3B:6E:8F:5B:97:6C:4B:2E SHA256: BB:9F:84:9F:F5:BB:F1:A2:97:EA:F4:0D:F1:EF:E9:89: 34:38:6F:7E:FC:B7:0D:84:E1:F6:40:9E:E6:08:18:B7
The fingerprint for the version of the signing certificate in use from November 2010 to November 2012 is:
The fingerprint for the version of the signing certificate in use from November 2008 to November 2010 is:
The fingerprint for the version of the signing certificate in use from November 2006 to November 2008 is:
4.4.4 Aggregate Validity
<EntitiesDescriptor> of a UK federation metadata aggregate
validUntil attribute defining the last instant during which the
aggregate should be considered valid. The
validUntil attribute’s value is set
at the time of construction of the aggregate to allow a “validity interval” of a
certain number of days after the aggregate’s construction. This interval acts as
a protection against certain attacks involving replay of old federation metadata
containing compromised information.
Metadata consumers SHOULD reject metadata aggregates lacking a
attribute and MUST discard aggregates whose
validUntil instant has passed.
In normal operation, the validity interval used for UK federation metadata aggregates is 14 days. This may be varied in either direction for operational reasons, but until further notice will never be less than 7 days nor more than 28 days.
4.5 Future Directions
4.5.1 Compressed Metadata Service
SAML metadata, as an XML document format, tends to be bulky but repetitive. One result of this is that most large SAML metadata documents are capable of being compressed at roughly a 10:1 ratio.
The MPS will be enhanced to allow metadata clients to request delivery of the compressed form of published metadata. This will allow a large reduction in the amount of data a compatible client needs to transfer. This obviously benefits the individual client while improving the scaleability of the central service.
This enhancement would be provided through use of the HTTP content coding system
as described in [RFC2616] section 3.5, with at least
gzip” and “
deflate” compression schemes supported.
It is recommended that client software designed to access the MPS should support
at least the “
gzip” content encoding. Clients indicate which encoding types
they support by means of the Accept-Encoding header within the GET request.
4.5.2 Query-Based Metadata Service
The current MPS provides metadata for all entities known to the UK federation within a single, large, aggregate document. This has the advantage of simplicity. However, entities participating in SAML federation do not, in general, require continuous access to metadata for all possible communication partners and in most cases the overwhelming majority of metadata downloaded by clients of the MPS lies unused by the consuming entity.
One way of reducing the burden on both individual MPS clients and on the service itself is to add a second publication method through which an MPS client can request only those individual entity-level metadata documents for which it has an immediate need.
Such a metadata publication protocol is currently being standardised (see [MDQuery], [MDQuerySAML]), and initial implementations of compatible publication servers and client software are becoming available.1 The technology will be evaluated for use within the UK federation.
4.5.3 Aggregate Structure
In order to support future inter-federation metadata exchange, the UK federation metadata aggregates may transition from the “flat” aggregates described above to a “hierarchical” structure. This would allow those entities registered by UK federation members to be separated from those entities imported from other registrars in order to preserve the semantics of attribute release based on relying parties named by the federation URI.
Experiments with this structure within the test aggregate have revealed the use
within the UK federation of several software implementations that process this
construct incorrectly, and as a result it is not regarded as viable in the short
term. This position will be re-evaluated in the future, but for now
distinguishing between entities owned by UK federation members and other
entities is best achieved through examination of the
metadata element’s registrationAuthority attribute as described in section