Page History

...

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 (CESNET)
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), Heather Flanagan, Tom Barton

Group 3:

...

...

...

Titleedugain recommended practices	eduGAIN Recommended Practices
Description	With edugain gaining steam, national Feds are trying different approaches to managing import, export, and filtering. This activity would review an early harvest of national Fed experiences and produce recommended practices that national Feds can use to produce a more consistent experience for IdPs and SPs, and hence for users.
Proposer	Tom Barton
Resource requirements	Perhaps 6 conference calls for a working group to organize, gather materials, net out essential recommendations. Someone to edit a resulting doc. Email list support.
+1's	Mikael Mikael Linden, Jean-François Guezou, Ann West, Heather Flanagan

...

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 presumably the results of this working group will make it easier for entities to interfederate
+1's	Scott Cantor

...

Title	Federation at scale
Description	Determine next steps towards dynamic resolution of entity metadata. The assumption is that this is how metadata will eventually be obtained at transaction time. This activity might focus on furthering the development and experimentation with protocols and implementations for so doing, or on how metadata comes to be sourced for dynamic resolution, or on identifying criteria by which to assess that a given dynamic resolution mechanism is working well. The purpose is to gain further experience and not necessarily to attempt anything definitive as yet.
Proposer	Tom Barton
Resource requirements	This one might have some hard resource needs. Some development. An environment in which to try things out, somehow including IdP or SP instances with which to experiment.
+1's	Lukas Hämmerle