This Consultation is now closed.
Background
The Security Incident Response Trust Framework for Federated Identity (Sirtfi) aims to enable the coordination of incident response across federated organisations. This assurance framework comprises a list of assertions which an organisation can attest in order to be declared Sirtfi compliant. Sirtfi has been developed by a REFEDS Working Group, supported by AARC.
This consultation asks for comments and change proposals to the Sirtfi Identity Assurance Certification Description. This document defines the ways in which Federation Operators and Participants (such as Service Providers and Identity Providers) should implement Sirtfi as an entity attribute and the requirements placed on participants to support Sirtfi.
Overview
The consultation opened on Friday 16th September 2016 and closed on Friday 28th October 2016 at 5pm CEST.
Participants are invited to:
- Review and comment on the Sirtfi Identity Assurance Certification Description with the intention of approving the document as a normative REFEDS specification.
Following the consultation all comments will be taken back to the Sirtfi working group for review and if appropriate the paper will then be forwarded to the REFEDS Steering Committee for sign-off and publication on the REFEDS website as per the REFEDS participants agreement.
The document for the consultation is available as an attachment to this page. Background on the SIRTFI Working Group is available. All comments should be made on: consultations@lists.refeds.org.
Change Log
Change Log for the Consultation on the SIRTFI Consultation. Please fill in your comments and change requests below. Line numbers are available in the document for ease of reference.
John Krienke
| 1 | Line 32
| Introduces the concept of a "registrar." I believe this is a Federation Registrar, and I would like to suggest the addition of the Federation adjective. Later, in Line 62, the document makes mention of an "entity's registrar"; however, I think the meaning is intended to be Federation Registrar here as well, not a different registrar that belongs to the entity. Short of defining the term, the addition of "Federation" before registrar would help the reader know to whom the registrar reports and is responsible. If there are others who might be registrars (attribute authorities, etc) perhaps a defined term is called for to explain further who this might be and what the role is/is not. | John Krienke | The Sirtfi WG agreed that the word federation was not appropriate in this context. No change recommended. |
| 2 | Line 32.
| Related to Sirtfi v1.0 and the attribute named on Line 47. How will versioning be handled? I imagine the committee has already discussed this. Will the federation operator be required to support new attributes whenever the spec is versioned? It might be prudent to add a brief section to this document that discusses how versioning and updates will be handled in relation to the attribute namespace. | John Krienke | Action to insert a change log at the top of the page to prepare for future versioning. |
| 3 | Line 76.
| I'd like to recommend that the word "membership" be replaced by the word "certification" to remain consistent with Lines 1 and 47 | John Krienke | Proposal accepted - Action to change reference. |
| 4 | Line 78. | Related to the requirement that a security contact MUST be in metadata (line 40), I have a question to consider. If an entity that is successfully tagged then later removes its security contact from metadata, is it the responsibility of the Federation (MUST?) to remove the Sirtfi tag from the entity? Or, is it the responsibility of the entity to notify the Federation registrar that the entity no longer complies? If the responsibility is the Federation's, this will become a requirement that our systems will need to automate against. While any kind of business process could be mandated here the presence of entity attribute and security contact person element is something that's trivial to monitor for automatically, so not something one should lose sleep over. Cf. the CoCo (GEANT Data Protection Code of Conduct for Service Providers) monitor at http://monitor.edugain.org/coco/ | John Krienke
| Action: agreed to add FAQ question - do I need a contact? Action: Add a clause that an entity must remove their Sirtfi attribute if they remove their contact. Proposal: Line 103. Add a new MUST for the entity: “If the entity removes the security contact [CONTACT] from metadata, it MUST also remove the corresponding Sirtfi Attribute.”
|
Number | Current Text / Reference | Proposed Text / Query | Proposer | Action |
|---|