Contact Information in Metadata
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 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 an<md:ContactPerson>
element with XML attributecontactType="support"
as well as an<md:ContactPerson>
element with XML attributecontactType="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.