For questions, please contact email@example.com.
- EntityID* (example: https://service.example.org/sp).
For reference, see this guide to choosing an appropriate EntityID.
- User interface elements:
- SP display name*
- SP description
- SP information URL
- SP privacy statement URL*
- SP logo URL (HTTPS)
- Width and height of SP logo
- Requested attributes (list all requested, with a business rationale for each). You may choose from the attributes below.
For reference, see this list of standard InCommon identity attributes.
• cn (commonName)
• o (organizationName)
• sn (surname)
- Discovery response indexes and corresponding location URLs.
- Assertion consumer service types/profiles* (available choices are below) and corresponding location URLs*.
• SAML 2.0 HTTP-POST
Example: https://<domain name>/Shibboleth.sso/SAML2/POST
• SAML 2.0 HTTP-POST-SimpleSign
Example: https://<domain name>/Shibboleth.sso/SAML2/POST-SimpleSign
• SAML 2.0 HTTP-Artifact
Example: https://<domain name>/Shibboleth.sso/SAML2/Artifact
• SAML 2.0 PAOS
Example: https://<domain name>/Shibboleth.sso/SAML2/ECP
• SAML 1.1 Browser/Post
Example: https://<domain name>/Shibboleth.sso/SAML1/POST
• SAML 1.1 Browser/Artifact
Example: https://<domain name>/Shibboleth.sso/SAML1/Artifact
- Single logout service profile/binding types (available choices are below) and corresponding location URLs. Please note that this is optional, and SP owners should carefully review InCommon's materials on single logout.
For reference, please see this InCommon guide to SP endpoints.
• SAML 2.0 HTTP-POST
• SAML 2.0 HTTP-Redirect
• SAML 2.0 SOAP
- Contents of digital certificate, in .pem format*.
For reference, please see this InCommon guide to X.509 certificates in metadata.
- Contact names and email addresses for the roles below — additionally, please supply title, phone, and fax for the individual or team whom you wish to designate as a primary contact for your SP.
Note that, if appropriate, one individual or team may fill multiple roles.
What attribute information about an individual do you require in order to manage access to resources you make available to other InCommon participants?*
What use do you make of attribute information that you receive in addition to basic access control decisions?*
For example, do you aggregate session access records or records of specific information accessed based on attribute information, or make attribute information available to partner organizations, etc.?
What human and technical controls are in place on access to and use of attribute information that might refer to only one specific person (i.e., personally identifiable information)?*
For example, is this information encrypted?
Please describe the human and technical controls that are in place on the management of super-user and other privileged accounts that might have the authority to grant access to personally identifiable information.*
If personally identifiable information is compromised, what actions do you take to notify potentially affected individuals?*