...
| Line Number | Current Text | Proposed Text / Query / Suggestion | Proposer | +1 (add your name here if you agree with the proposal) | Action |
|---|---|---|---|---|---|
| 79-81 | 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-119 | Whether 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, Unicon | Albert Wu (internet2.edu) | ||
| 455, 470-476 | staff@dentistry.acme.edu, staff@nursing.acme.edu | The guidance in this document about defining scope values for "e.g., school/college within a university" conflicts with the guidance at saml-metadata-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 (illinois.edu) | ||
| Can InCommon or REFEDS run simple SPs that IDP operators can use for testing their implementation of the Access Entity Categories? I'm thinking of a page that displays the attributes and values released to the SP. This relates to Mike Grady's comment regarding overlapping attributes release policies. | Andy Morgan, Oregon State University | ||||
See Also