Page History

...

Title	Federated Error Handling
Description	Develop a systematic approach to error handling at the Service Provider, especially in the common case where there are no (or too few) user attributes in the SAML response. One approach that has been suggested (but is by no means the only approach) is to leverage the Error Handling URL (`errorURL`) in IdP metadata so that end users are directed to an appropriate service point (e.g., help desk, IdM support, etc.). A possible outcome of this work item might be a profile of the `errorURL` in IdP metadata and a strategy for increasing its usage worldwide.
Proposer	Tom Scavo
Resource requirements	Profiling the use of `errorURL` in IdP metadata (if that is indeed a recommended approach) would be relatively easy
+1's	Scott Cantor

Title	Contacts in Metadata
Description	As interfederation increases in scope, so does the importance of contact information in metadata. The goal of this work group is to clarify and perhaps profile the use of contacts in metadata. Possible work items include: Under what situations (if any) is contact information required? What are the intended uses of specific contact types? Clarify the use of the `mailto:` prefix. Standardize the usage of `GivenName` and `SurName` elements in metadata. Recommend new contact types as needed (e.g., a security contact) Discourage the use of individual email addresses in favor of role-based email addresses (such as help_desk@example.org)
Proposer	Tom Scavo
Resource requirements	Federations have a long history of the use of contact information in metadata and so widespread agreement may be difficult to achieve but the results of this working group will make it easier for entities to interfederate
+1's	Scott Cantor

Title	Attribute authorities and group membership/role information
Description	Attribute authorities become interesting in VO world, where IdPs are not able to satisfy SP needs on additional attributes about the users especially group membership/roles. The main problem is when one SP wants to accept users from different VOs which use different attribute authorities. There is no common standard for representing group name/role in the attribute having VOs identification into account (just group name can lead to collision among different VOs). Some examples how group names are used by current group mgmt systems: Perun: {vo_name}:{group_name}:{sub_group_name}:... SufConext: urn:collab:group:{group_provider}:{group_name} Protocols which work with groups and theirs requirements on the group name: VOOT: apart from id (usually UUID) it uses displayName which is a translatable string giving the group a human friendly name. The name is supposed to give a clear meaning for users setting up access control. SCIM: apart from id (usually UUID) it uses displayName: A human readable name for the Group.
Proposer	Michal Prochazka
Resource requirements	Several conference calls should be enough for setting up the working group and produce recommendation on nameing schema for groups including VO identification.
+1's	Scott Koranda, Wendy Petersen (CAF), Niels van Dijk (SURFnet)

Versions Compared