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:

When a credential is to be verified, the first step is to collect the appropriate verification information, in the form of a set of <KeyDescriptor> elements, from the appropriate role descriptor. Note that in the case of an IdP, the <IDPSSODescriptor> and <AttributeAuthority> will usually contain the same set of <KeyDescriptor> elements, but that this should never be assumed. Only the <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 <KeyDescriptor> elements remain, the verification has failed. UK federation metadata will normally contain, within each role descriptor, at least one <KeyDescriptor> element whose use includes signing either explicitly or implicitly through an absent use attribute.

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 the <KeyDescriptor> as valid for both signing and encryption purposes.

<KeyDescriptor> elements in SP role descriptors may or may not include explicit use attributes; again, no assumption about the presence of an explicit use attribute should be made by software relying on UK federation metadata.

Verification against the set of <KeyDescriptor> elements associated with an entity acting in a particular role can succeed if verification against any of the <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 <ds:X509Data> elements, each of which will contain exactly one <ds:X509Certificate> element.

2.1.1 Verification using the Direct Key scheme

See:

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 either <ds:X509Certificate> or <ds:KeyValue> elements. At present, UK federation metadata does not make use of <ds:KeyValue>. It is however possible that <ds:KeyValue> elements may be introduced at a later date and developers are RECOMMENDED to implement support for this as part of support for [SAML2MIOP].

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.