The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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.

Use Cases

Typically a support contact is for end-user support whereas a technical contact is available to troubleshoot software or systems issues. Here are a few potential use case scenarios:

  • 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 a 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 technical contact, describing the event that just occurred. The message provides a pointer to the SP's Requested Attributes 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 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 inline). 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 the 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 technical contact with instructions how to federate the IdP with the SP.

Technical Details

Technical Requirements

  • Each <md:EntityDescriptor> element SHOULD contain at least two contacts: an <md:ContactPerson> element with XML attribute contactType="support" and an <md:ContactPerson> element with XML attribute contactType="technical".
  • Each <md:ContactPerson> element SHOULD contain at least one <md:EmailAddress> element.
  • If a contact (either support or technical) 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.
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels