Below is a security contact metadata extension for identity federations in order to allow handling of security incidents between federation partners. 

Security Contact Metadata Extension
<EntityDescriptor ... >
... 
<ContactPerson xmlns:remd="http://refeds.org/metadata" contactType="other" remd:contactType="http://refeds.org/metadata/contactType/security">
    <GivenName>Security Response Team</GivenName>
    <EmailAddress>mailto:security@institution.edu</EmailAddress>
</ContactPerson>
...
</EntityDescriptor>

Who to include as the security contact?

  • An appropriate security contact, such as an individual or generic contact, with existing security responsibility within an organisation.
  • Existing incident response structures, including CERTs, may be leveraged where available
  • This contact will:
    • Use and respect the Traffic Light Protocol (TLP) during all incident response correspondence
    • Promptly acknowledge receipt of a security incident report
    • As soon as circumstances allow, investigate incident reports regarding resources, services, or identities for which they are responsible

Correspondence sent to this address must not be publicly archived

Which fields must be provided?

GivenName and EmailAddress are mandatory for a Sirtfi security contact.

Can additional fields be included?

Additional information, such as telephone numbers or secondary email addresses, may be added if desired. Only fields from the OASIS Standard for contactType may be added.

  • No labels

10 Comments

  1. Kindly let me know technically how can I configure my ADFS V3 metadata to assert Sirtfi?

    1. Hello Wael. Please reach out to the SIRTFI mailing list (sirtfi@lists.refeds.org). They may be able to provide more detailed guidance. Thank you for your interest in SIRTFI!

      1. Thanks Heather, I've sent them an email and waiting for a positive reply.

  2. Hi, the namespace URI provided in the example seems to be wrong. According to the REFEDS metadata extension XML schema definition (Metadata Extension Schema) shouldn't it be "http://refeds.org/metadata"?

  3. Davide, I changed it back to http. In March I tried to get all of the occurrences of http[s]://refeds.org/metadata and http[s]://refeds.org/metadata/contactType/security to agree across all of the pages that mention them, and to align with what's out in the wild. Somehow I did not get it right!

  4. Thanks Tom! Let's hope this is the last one (smile)

  5. Davide, I followed the guidance at https://refeds.org/metadata/contactType/security, which has https still. Can you arrange that that page is updated?

  6. Sure. I'll ask Nicole & Heather to take care of that (I do not have access)

  7. Just to note that it's not regarded as good practice to use an "individual" as a security contact. See RFC2350 para 3.2 for one reason; also individuals leave, go on holiday, etc.. Please could you at least reverse the order, so "such as a functional or individual contact". Thanks

    1. That's fine with me, fwiw. However, the web page https://refeds.org/metadata/contactType/security must also be updated accordingly. In fact, I wonder why there are two authoritative-seeming sources for REFEDS standards, one in the wiki and another on the web. Davide Vaghetti, can you add that to your request of Heather and Nicole?