The InCommon Federation has three standing committees that help guide federation operations and activities: The InCommon Steering Committee, The Technical Advisory Committee (TAC), and the Community Trust and Assurance Board (CTAB). Sponsored by all three of those committees, the Attributes for Collaboration and Federation Working Group was formed to research and examine the low adoption rate of the Research and Scholarship Entity Category (R&S) by InCommon members and develop recommendations to increase participation.
Through surveys and interviews, the Attributes for Collaboration and Federation Working Group reached over 130 organizations, examining participation and planned participation in R&S. As a result of this process, the Working Group has drafted a report of its findings and developed a set of recommendations. The Working Group is now soliciting additional feedback through the community consultation process.
Document for review/consultation (now outdated, see final report at http://doi.org/10.26869/TI.101.1 )
For more information about the working group, please see the Attributes for Collaboration and Federation wiki space.
Change Proposals and Feedback - We welcome your feedback/suggestions here
If you have comments that do not lend themselves well to the tabular format below, please create a new Google doc and link to it in the suggestion section below.
|Number||Current Text||Proposed Text / Query / Suggestion||Proposer||+1 (add your name here if you agree with the proposal)||Action (please leave this column blank)|
|"Rebrand InCommon's R&S efforts" to avoid giving the impression to the rest of the eduGAIN community that the recommendation is to change the name of the entity categroy.||Scott Koranda||+1 please don't open that rathole again!||Recommendation accepted.|
|2||"less secure alternatives to federation"||Page 5. "less secure and more privacy-invasive alternatives". It's ironic that SPs and IdPs that create incentives to use them "because privacy" are actually driving users to share more personal data!||Andrew Cormack||Recommendation accepted.|
|3||"practical examples"||Page 7. You may cover this later, and it may not apply to InCommon members but I suspect a lot of IdPs would be greatly helped by providing detailed instructions on how to configure their software to support R&S...||Andrew Cormack||This issue is addressed in our recommendation to "Improve R&S related documentation..."|
|4||"bigger tent"||Page 10-11. Can you use the existing R&S SPs as a channel, to explain to researchers how they could make their, and their institutions', lives easier? We've been trying to close the loop between researchers' needs and central IT provision for a long time||Andrew Cormack||While we're happy to encourage SP operators to spread the word about the value of R&S, we don't want to create an obligation for them to do the work of the federation.|
|5||"4.3.3 Make R&S attribute release the default policy for InCommon"||I'm confused about "default" versus "requirement" in this section. If the proposal is to make R&S support a requirement to Baseline Expectations, so all InCommon IdPs are required to support R&S, I think it could be stated more directly, and in my opinion, it should be the #1 recommendation, not the last one, since it's a big ask and buried on page 14 it's easy to miss.||Jim Basney||+1 - Gettes.||Recommendation Accepted. We have revised the report's recommendation to make it clear that we think R&S should be included in baseline expectations.|
|6||4.3.3||I agree with Mr. Basney. As I said at the Global Summit meeting, we should be making this a requirement for InCommon IdPs. And, as Jim notes, it should be the #1 recommendation. While InCommon would be supporting R&S from the REFEDs perspective, the notion of R&S within InCommon should be rendered moot by requiring every IdP to support it. No need to rebrand R&S, it just becomes moot for InCommon. InCommon has been dancing around this issue for far too long and it is time to make this a simple requirement. Yes, I should have done a +1 to Jim's entry, but I want to strongly support this perspective. I am also adding a +1 to Jim's comment.||Michael Gettes||See answer above to #5.|