2 Trust Fabric
One of the roles of the metadata published by the UK federation is to allow
the federation to act as a broker of technical trust between members. This is
enabled by including
<KeyDescriptor> elements for each entity, with each
<KeyDescriptor> representing a credential (in the form of an RSA keypair)
held by the entity.
As described in section 3.10 below,
<KeyDescriptor> elements in metadata published by the UK federation broker
trust through the direct embedding in entity metadata of public key values in
the form of X.509 certificates with any origin, containing the public key part
of the credential. All entity metadata published by the UK federation SHALL
support this mechanism.
The PKIX-based trust mechanism originally used by the UK federation and described in previous editions of this document was discontinued in June 2014.
2.1 Verifying Entity Credentials
There are a number of circumstances in which entities present credentials which must be verified by a relying party:
Authentication responses issued by an IdP to an SP using the Browser/POST profile are signed using a credential which must then be verified by the SP. In this case, the SP locates the information required for the verification in the IdP entity’s
During SOAP callbacks from the SP to the IdP (whether for attribute query or for artifact resolution) both the IdP and SP present credentials (normally through the TLS handshake) which must then be verified by the other party:
The SP locates the information required to verify the IdP’s credential within the role descriptor element associated with the endpoint to which the callback is being made:
For attribute query callbacks, in the IdP entity’s
For artifact resolution callbacks, in the IdP entity’s
The IdP locates the information required to verify the SP’s credential in the SP entity’s
When a credential is to be verified, the first step is to collect the
appropriate verification information, in the form of a set of
elements, from the appropriate role descriptor. Note that in the case of an IdP,
<AttributeAuthority> will usually contain the
same set of
<KeyDescriptor> elements, but that this should never be assumed.
<KeyDescriptor> elements from the role descriptor associated with the
particular endpoint in use should be considered.
For verification purposes, all
<KeyDescriptor> elements with an explicit
use="encryption" attribute should now be discarded. If no
elements remain, the verification has failed. UK federation metadata will
normally contain, within each role descriptor, at least one
element whose use includes
signing either explicitly or implicitly through an
For compatibility reasons,
<KeyDescriptor> elements in IdP role descriptors
will always include explicit
use attributes in UK federation metadata.
However, this should never be assumed by software and the case of an omitted use
attribute should always be handled correctly by regarding the credential within
<KeyDescriptor> as valid for both signing and encryption purposes.
<KeyDescriptor> elements in SP role descriptors may or may not include
use attributes; again, no assumption about the presence of an
use attribute should be made by software relying on UK federation
Verification against the set of
<KeyDescriptor> elements associated with an
entity acting in a particular role can succeed if verification against any of
<KeyDescriptor> elements succeeds: a failure to verify requires that
verification against every appropriate
<KeyDescriptor> element fails
independently. One implication of this is that software is at liberty to perform
tests against the set of
<KeyDescriptor> elements in any order; one
performance optimisation would be to cache information about which
<KeyDescriptor> was successfully verified during a previous operation.
[SAML2Meta] defines the
<KeyDescriptor> element as
always containing a single
<ds:KeyInfo> element, but goes into no more detail.
UK federation metadata supports a direct key model of credential verification,
in which the
<ds:KeyInfo> will contain one or more
each of which will contain exactly one
2.1.1 Verification using the Direct Key scheme
Shibboleth 2 implementation:
Shibboleth 1 implementation:
The direct key verification scheme corresponds to the [SAML2MIOP] SAML V2.0 Metadata Interoperability Profile. This means that an X.509 certificate embedded in metadata is treated only as a convenient wrapper for a cryptographic public key, with none of the additional semantics normally associated with X.509 certificates. In particular, such a certificate is not subject to PKIX path validation or to checks against its expiry.
The [SAML2MIOP] profile requires that all runtime decisions are made solely on the basis of key comparisons. One way to perform such checks is to extract the public key from the metadata certificate and compare it against the key extracted from the certificate presented by the claimant (after, of course, verifying that the claimant has cryptographically demonstrated its possession of the corresponding private key). However, in some circumstances a performance optimisation is available by comparing the certificate presented by the claimant directly against the certificate included in metadata, as these will frequently be identical. However, failure of such a comparison has no significance but to signal that key extraction and direct key comparison will be necessary.
[SAML2MIOP] allows keys to be represented using
<ds:KeyValue> elements. At present, UK
federation metadata does not make use of
<ds:KeyValue>. It is however possible
<ds:KeyValue> elements may be introduced at a later date and developers
are RECOMMENDED to implement support for this as part of support for
UK federation metadata currently contains only RSA public keys, and support of other public key cryptosystems (such as elliptic curve cryptosystems, or DSA keys) is not envisaged in the near future.
2.2 Future Directions
2.2.1 Transition to non-PKIX Trust Fabric
During calendar years 2013 and 2014, the UK federation metadata underwent a trust fabric evolution with the dual aims of modernising the trust fabric and increasing the security of the federation environment.
One major part of this evolution was to move the trust fabric away from the original PKIX model towards one in which the simpler and more widely supported direct key model is supported for all entities, so that the direct key scheme may be relied on exclusively.
This transition was completed during June 2014, and the PKIX trust fabric is no longer supported in UK federation metadata.
2.2.2 Transition to Stronger RSA Keys
The second major part of the trust fabric evolution was to follow the NIST recommendations in [SP800-57part1] and [SP800-131A] to first deprecate and then disallow any use of RSA keys whose modulus is less than 2048 bits in length.
This transition was completed during calendar year 2013.