The principal use of contact information in metadata is to enable effective communication between Federation participants, especially when systems fail, when users encounter problems, or when a security incident occurs.
A secondary function is to support user interfaces (UIs) but much of the contact information displayed by an identity provider or service provider (for example on error, discovery, login, or consent pages) is self-owned and therefore known by the presenting site. A notable exception is an identity provider contact suitable for brokering attribute release changes when users encounter failures accessing services because the Requested Attributes are not released to SPs.
There are four types of contacts in Federation metadata:
All are important in different scenarios, and participants are encouraged to provide at least one of each type. At least one technical contact is REQUIRED in metadata. At least one administrative contact is REQUIRED as well. As part of the roll out of InCommon's Baseline Expectations program, at least one security contact will be REQUIRED. You are advised to add a security contact to your metadata NOW.
Contact information should be role-based such as help_desk@example.org rather than individual such as janedoe@example.org. |
Here are a number of hypothetical user scenarios that rely on contact information:
errorURL
location, if available. In addition to displaying a message to the user, the SP software sends a back-channel message to an institutional administrative contact at the IdP, describing in detail the event that just occurred. The message includes a pointer to the SP's Requested Attributes in metadata.Reliable contact information in metadata will enable workflows and scenarios such as those described above.
Here is an example of an appropriate set of <md:ContactPerson>
elements in metadata:
<md:ContactPerson contactType="technical" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <md:GivenName>Technical Support Team</md:GivenName> <md:EmailAddress>mailto:tech_support@example.org</md:EmailAddress> </md:ContactPerson> <md:ContactPerson contactType="administrative" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <md:GivenName>Office of Administrative Support</md:GivenName> <md:EmailAddress>mailto:admin_support@example.org</md:EmailAddress> </md:ContactPerson> <md:ContactPerson contactType="support" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <md:GivenName>Help Desk</md:GivenName> <md:EmailAddress>mailto:help_desk@example.org</md:EmailAddress> </md:ContactPerson> <!-- there are two types of security contacts in metadata but both serve the same purpose --> <!-- security contact with (legacy) InCommon syntax --> <md:ContactPerson contactType="other" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:icmd="http://id.incommon.org/metadata" icmd:contactType="http://id.incommon.org/metadata/contactType/security"> <md:GivenName>IT Security Office</md:GivenName> <md:EmailAddress>mailto:security@example.org</md:EmailAddress> </md:ContactPerson> <!-- security contact with REFEDS syntax --> <md:ContactPerson contactType="other" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:remd="http://refeds.org/metadata" remd:contactType="http://refeds.org/metadata/contactType/security"> <md:GivenName>IT Security Office</md:GivenName> <md:EmailAddress>mailto:security@example.org</md:EmailAddress> </md:ContactPerson> |
|