Contacts in Metadata

Contact Information in Metadata

Like User Interface Elements, contact information in metadata is used by federated applications to construct rich, dynamic user interfaces (UIs). Specifically, contact information in IdP metadata is used for the discovery and error pages at the SP, while contact information in SP metadata is used for the login, consent, and error pages at the IdP. Accurate and helpful contact information promotes open communication across security domains.

There are four types of contacts in Federation metadata:

• support contact: for end-user support, which is often technical support but may also address issues regarding attribute release policy, user privacy, etc.
• technical contact: for direct communication between participants regarding technical issues such as troubleshooting software, systems, or network issues
• administrative contact: for direct communication between participants regarding non-technical issues such as attribute release policy, on-boarding issues, etc.
• billing contact: for billing questions

Of these, the most important type of contact is the support contact.

Here are a few potential use case scenarios that rely on contact information:

• A user authenticates successfully at the IdP and is subsequently redirected to the SP. The SP software, seeing that the SAML assertion does not contain the desired attributes, displays an error message that refers the user to a support contact at the IdP.

• In the previous scenario, in addition to displaying a message to the user, the SP software sends a back-channel message to a 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.

• A user authenticates successfully at the IdP and is subsequently presented with a consent page. The SP's Requested Attributes are displayed on the consent page, along with a link to the SP's Privacy Policy. A support contact at the SP is also displayed on the consent page, for those users who have questions about the SP's Requested Attributes and/or the Privacy Policy.

• When a user attempts to access a protected resource, the SP redirects the user to a centralized discovery service (or displays an embedded discovery interface). The discovery interface displays a fall back link with the text "My institution is not listed, what should I do?" Upon clicking the link, the user is presented with a secondary list of institutions. Selecting an institution from this list, a text area with a prepared message appears. The user edits the message (if desired) and presses the Send button, thereby sending the message to a support contact at the user's home institution.

• In the previous scenario, the software, in addition to sending a message to the institutional support contact, also sends a back-channel message to the institutional administrative contact with instructions how to federate the IdP with the SP.

Technical Details

Here is an example of appropriate <md:ContactPerson> elements in metadata:

<md:ContactPerson contactType="support"
     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:EmailAddress>mailto:help_desk@example.org</md:EmailAddress>
  <md:TelephoneNumber>999-999-9999</md:TelephoneNumber>
</md:ContactPerson>
<md:ContactPerson contactType="technical"
     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:GivenName>Mary</md:GivenName>
  <md:SurName>Smith</md:SurName>
  <md:EmailAddress>mailto:mary_smith@example.org</md:EmailAddress>
</md:ContactPerson>
<md:ContactPerson contactType="administrative"
     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:GivenName>John</md:GivenName>
  <md:SurName>Doe</md:SurName>
  <md:EmailAddress>mailto:john_doe@example.org</md:EmailAddress>
</md:ContactPerson>

Technical Requirements

• Each <md:EntityDescriptor> element SHOULD contain at least three contacts, that is, three <md:ContactPerson> elements with XML attributes contactType="support", contactType="technical", and contactType="administrative".
• Each <md:ContactPerson> element MUST contain at least one <md:EmailAddress> element.
• If a contact is a real person, the <md:GivenName> and <md:SurName> elements SHOULD reflect the person's real name.
• If a contact is a non-person (such as a mailing list), the <md:GivenName> and <md:SurName> elements SHOULD be omitted.