Community Review

This consultation opens on April 1, 2024 and closes on April 30, 2024 at 5PM PDT.


In 2023, REFEDS published the latest revisions of three attribute release entity categories designed to facilitate privacy-preserving, standard, and streamlined user information release in federated transactions. These are Anonymous Access, Pseudonymous Access, and Personalized Access categories. Together, we refer to them as the REFEDS Access Entity Categories.

The InCommon Federation (InCommon) wishes to encourage the widespread adoption of these categories when requesting and releasing user information in federated transactions. To that end, the InCommon Technical Advisory Committee’s SAM2Int/Entity Category Deployment Guidance Working Group has produced a series of deployment guidance to help the InCommon Federation community adopt the REFEDS Access Entity Categories. 

This is a Three-in-One Document

The Working Group produced materials organized in three loosely-connected volumes:

  1. Understanding the REFEDS Access Entity Categories;
  2. Deployment Guidance for InCommon Participants;
  3. Working with Required Attributes; 

They are compiled together in a single document to facilitate community review. In their final published format, the topics will be parsed into a series of web articles cross-linked among each other.

More are Coming

We are aware that the InCommon community will likely need additional detailed guidance, for example, around migration strategies. A new TAC working group is forming to develop these additional materials. We welcome your input and participation. Please note your interest in the Feedback Log below.

Document for Review / Consultation

The PDF for the consultation is available: 

All comments should be made added to the Feedback Log below. Comments posted to other channels will not be included in the consultation review.

Participants are invited:

  • to consider the proposed deployment guidance to the REFEDS  Access Entity Categories 

This consultation opens on April 1, 2024 and closes on April 30, 2024 at 5PM PDT.

Feedback Log

Line NumberCurrent TextProposed Text / Query / SuggestionProposer+1 (add your name here if you agree with the proposal)Action

The R&S registration criterias is fuzy and have given unpredictability in a service fulfills a the criteria or not when you look over federation boundraries. It's better to have a clear defintion of what you mean in the document.Pål Axelsson, SWAMID

117-119Whether you support the automatic release 
 mechanism required by the REFEDS entity categories or not, you can at least use these 
 templates to standardize attribute release to individual SPs.
It states automatict release is required by the entity categories but that is not true. In personalized it's stated "An Identity Provider indicates support for this entity category by exhibiting the entity attribute in its metadata. Such an Identity Provider MUST, for a significant subset of its user population, release all required attributes in the bundle defined in Section 5 to all tagged Service Providers, either automatically or subject to user consent or notification, without administrative involvement by any party.". This means that thoose identity providers expressing support in metadata must do automatic release but if you don't express support in metadata you can still release attributes based on for example an manual informed decisions for entities.Pål Axelsson, SWAMID

93 - 103

Wherever you put it, the advice for the anonymous category needs to include a warning about existing attribute release policies in the IdP. Because I've worked with institutions that release something like the R&S bundle to ALL InCommon (or even all InCommon MDQ sourced) services, or even, in some cases, to ALL SPs for which the IdP has metadata. And it is not uncommon (no pun intended) for the current maintainer of that IdP to not even realize that. And, even if you then configure support for Anonymous tagged services, unless you explicitly DENY the already greater set (many of which will be personally identifying), you will then be releasing attributes to an Anonymous service that you should not be.   (I also think this is why explicit advice on how to easily test what you are releasing after adding support for the profile will be critical, including identifying a service that is "tagged"for this profile and how to see what your IdP would then send.)

Mike Grady, UniconAlbert Wu ( 
455,, staff@nursing.acme.eduThe guidance in this document about defining scope values for "e.g., school/college within a university" conflicts with the guidance at Scope that "Multiple scopes should not be used to distinguish multiple subgroups of users within a single security domain." I think InCommon should continue to recommend against registration of multiple scope values for a single entity, to avoid added complexity and to maintain consistency with current guidance.James Basney ( 

See Also

  • No labels