Metadata are dynamically updated configuration data about the service providers and identity providers making up the federation.
Technically, WAYF metadata are XML documents. XML is the standard format within identity federation — also with the very protocol messages exchanged at runtime. This is true of the SAML protocol, which is still dominant. But the newer protocol OIDC can also be used with WAYF; and there, the format is JSON.
WAYF metadata may only be used for connecting to WAYF, and at your own risk. Any other usage must be approved by the WAYF Secretariat.
Metadata
Metadata in WAYF are issued both as a number of feeds (with numerous entities in each feed) and as seperate entities (through the MDQ protocol). On the WAYF entities dashboard, in each entity's entry you will find a link to dynamically updated metadata for that particular entity. The main feeds are as follows:
- Metadata for service and identity providers connected to WAYF
- Metadata with individual IdPs, for service providers connected to WAYF (Use this feed if you want to make a discovery service of your own, or rely on SAML2 entityIDs for identifying identity providers.)
- For convenience, we also expose this summary JSON feed for service providers wishing to identify IdPs by either SAML2 entityIDs or schacHomeOrganization values.
- Static configuration for WAYF as an OpenID Provider using OIDC.
- Dynamic configurations for WAYF and for each user organisation in WAYF as OpenID Provider(s).
Key* for verifying signed metadata feeds from WAYF
WAYF signs its metadata feeds with the private key corresponding to the certificate whose fingerprint and PEM encoding are published here:
3d:61:09:30:52:74:c6:95:3a:de:46:d0:ec:7b:36:00:81:6d:97:54:
-----BEGIN CERTIFICATE----- MIID4DCCAkigAwIBAgIQP9aA4aDHT+7GWsIqTRb+HjANBgkqhkiG9w0BAQsFADAi MSAwHgYDVQQDExd3YXlmLjNLLjIwMjUubWV0YWRhdGEtMDAgFw0yNTExMTExMTEx MTFaGA8yMTI1MTExMTExMTExMVowIjEgMB4GA1UEAxMXd2F5Zi4zSy4yMDI1Lm1l dGFkYXRhLTAwggGiMA0GCSqGSIb3DQEBAQUAA4IBjwAwggGKAoIBgQDakvmWe5Sk 5VBedBetlqz5x7JeYFw3OvakopmY/32ZYvWgnfxEcwx03eEvcNphB/ITCBqcchG6 28rsOq2D2FDy7TnamVCerT1KLtikr8OnhdnAJr0VXxon2w2U1d9ucDHV4KpxYWiR HEyXn8/l7JErqJ1coGj24nI20ssaR5rP+g3lIfaIePOdKufIJMJDhANwMJ+2kleu rtLcNL33UQKi6QOovHkXis6xlqGBfEIRgaVg0QkKT7dSKgP2OVry7LEYOyWb1PL5 abuRqWCGIB2pdyP1JECm6cyrqqtSIznQQvzPQiNB22bJ1Iml0P+OaQNb5upCegZ1 XhBQJXu6F53RQxbLaigH409v4bnjkEtSFbb4B2o5en39/Hdn+tMRt45AHbokbuqm z7NT8ieeheWYB7rG2tbGvCsPTlaRUFATT5yaujWZ3sBrtT0aj/05E2X5H6VYh5hq qI6EPZRXWEoFxyytFMTRZbXVX2O0As9S2xGGlFL7/zUv23Jv50mNFh8CAwEAAaMQ MA4wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAYEATCa5qNdSY49yQQBc iVwzX+xfTkRPT2tCNBL8wOiVhmOUvi74CKTpmK5sdU86WKAUgtyV38i5L8iJIt6f MfDd0HOphm6xR7l9OzBIL1AG2vB6odkiEoykU8TBWKIleNq/MXSqq8XiwCo3ImpH L697ewfQQCKsZThdWeMhclBfD+iwqLllqCtCn5zTxwCS4kwFMitB77kTlwEYAdQx UyskHKl555PRpw1tjX/HyRbhDdORdlzg2LDt4CcwbGKRu21Huhki0n19IeLTGCoM SZwnjgSf1cOVvfobIjQcRslkD+biX1xnMOwpsSkck+9fNUQmAkrPzFUNxoCVW+Fs MH801L8nigEmHV2mVQ74wKCE1MFqnViKmnkKY0lYe5sIicZvB+nHHfCjcfGw+/EG TTpL3/lBnEOTpM5lN3/zlgzmlfH6MLhNqkzLL9yOzO/+WYMZfEFVIHJHsBGE3nRN r6NEYWLm2zBurlRbwf3lVeqxlt+eh195sdaJ7RKeh/48g0uT -----END CERTIFICATE-----
*Remember that X509 is only used as a technical format (as a “wrapper” around) the public key: It is not permitted to interpret any fields in the “certificate” other than the key itself; they have no meaning. X509 is used solely because it is the most common format for exchanging public keys.