VOs straddle national Feds and we handle them in an ad hoc (at best!) fashion. What practices should the interfed community adopt to support their Fed/Interfed needs? Deliverables might include strawman recommended practices to national Feds and roles & responsibilities that together would define a consistent service presented to VOs. The purpose would be to inform ourselves of what it might actually take to operationalize such a service.

Could build on the VO Assessment activity proposed by Heather above.

As national federations continue to join eduGAIN the problem of supporting users across federation boundaries will increase. When a user has an issue attempting to access services provided in another federation how it will be resolved in this global federation of federations. Issues the end user may experience include;

• Understanding where the cause of the problem is;
• Language barriers;
• Service providers unaware that their services is available in other federations;
• Services providers unwilling to provide support to users in other federations;
• Global scale and time zone difference challenges

The development of a global incident handling/support framework. This framework would build on each federation’s user support strategies and seek ongoing support of the framework from federation through a memorandum of understanding.

1) Development of a service oriented approach eduGAIN Global Support Framework to provide seamless user experience, including:

i. Capability to log support request from anywhere (eduGAIN Support Zendesk)

ii. Incident Management process for National Federation on eduGAIN

iii. Incident Management process for Service Providers (Institutional, National, and International SPs)

2) A program of work to ingest (1) above into all national federations participating in eduGAIN.

Development and documentation of the framework Marketing of the framework and buy in for federations

eduGAIN to publish a register for participating members to log and manage Risk and Issues

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)

VOs straddle national Feds and we handle them in an ad hoc (at best!) fashion. What practices should the interfed community adopt to support their Fed/Interfed needs? Deliverables might include strawman recommended practices to national Feds and roles & responsibilities that together would define a consistent service presented to VOs. The purpose would be to inform ourselves of what it might actually take to operationalize such a service.

Could build on the VO Assessment activity proposed by Heather above.

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. 

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)

REFEDS has long appreciated the importance of IdP discovery in the federated model (see: REFEDS Discovery Guide). The current discovery model is dependent upon an aggregate of IdP metadata but advances in the distribution of per-entity metadata suggest that an aggregate may not always be available at the SP. A new model of IdP discovery in a world of per-entity metadata may be needed. Various approaches are possible:

• continued reliance on a comprehensive aggregate of IdP metadata

• a google-like, server-side search mechanism (trading latency for load time)

• domain mapping eduroam-style

• a client-side application or plugin

The latter includes the OpenID account chooser but its relevance in this space is not well understood.

Hub-and-Spoke federations operate a centralized authentication component as part of their Identity Federation. In Reseach and Education about 10 federations are currently running such a setup.

This activity gathers best practices form those running such federations. Possible topics may include:

• Operational topic, e.g. scale and security
• Enduser, IdP and SP support
• Trust establisment, privacy preservation and policy
• Business cases for running a central component
• Augmenting federation with e.g. group management, attribute aggregation, stepup authentication, credential and protocol translation and autherization
• Working with metadata
• Available tools and technologies
• Working with eduGAIN, Code of Conduct and attribute bundles
• Combining Hub-and-Spoke and Mesh federation technology