Use Cases - New Entities Working Group
Group Leader (Chair): Jim Jokl, Univ of Virgina
Weekly meetings: Thursday, 3:00 pm ET
+1-734-615-7474 (Please use if you do not pay for Long Distance)
+1-866-411-0013 (Roll free US/Canada Only)
Access code: 0185876#
We invite community comments to the New Entity Working Group Recommendations found here. Please use the comment feature at the bottom of the Recommendations wiki page (you must be logged onto the Confluence wiki). The community feedback period will extend until April 10, 2015 but early feedback is greatly appreciated.
The InCommon metadata file contains, from a policy perspective, only one kind of entity---those owned and managed by, either directly or indirectly, an InCommon participant. There are proposals currently under review to add entities to metadata that deviate from this established practice:
- Operationalizing eduGAIN will add IdPs and SPs that are members of other federations, but not members of InCommon.
- A Social-to-SAML Gateway would rely on external/social identity providers to authenticate users and assert attributes about them (often self-asserted).
- Some Regional Network Operators would like to facilitate InCommon participation by K-12 systems without themselves being directly responsible for the operation of the K--12 entities that would appear in the metadata.
The appearance of these new types of entities within the InCommon metadata file will create new risk scenarios for current InCommon members.
The Mission of this Working Group is to identify what an IdP or SP operator needs to know about policies or practices associated with entities that would be added to metadata by any of the above practices, and especially which of those needs should be facilitated by the InCommon Federation itself. Each such need should be supported by a specific and documented use case. This Working Group should coordinate with other InCommon Working Groups that might be exploring issues in depth related to one of these new entity types.
- InCommon - Quilt Partnership Models
- IdP Proxy (proxying either IdPs or SPs) as a Metadata Entry
- EU IDP accessing SP at Brown
- Course with US-based and EU-based students
- Consequences of eduGAIN Metadata
- Importing eduGAIN Metadata
- LIGO as an International Virtual Organization
Use Case Impact and Recommendations
- Use Case Impact Summary
- Recommendations (old)
Membership in the Working Group is open to all interested parties. Members join the Working Group by subscribing to the mailing list, participating in the phone calls, and otherwise actively engaging in the work of the group. It is particularly important that the work group include schools, both large and small, that are perceiving hurdles to federating their institution. The goal is to make the process easier and that will require broad participation.
The chair of the Working Group is appointed by the InCommon TAC and is responsible for keeping the TAC informed regarding Working Group status.
- Identify use cases and functional requirements related to what an InCommon SP might want to know when receiving a response from one of these new IdP-like entities. What would be valuable to represent about each of these entities? How are they different (in a policy or practical sense) from current members?
- an IdP-proxy (e.g., the proposed Google-based Social-to-SAML Gateway acting as an IdP). The eduGAIN metadata will likely contain other IdP proxies.
- ordinary IdP entities from eduGAIN that are added to the InCommon metadata aggregate
- entities acting as IdPs that are registered by Regionals but are used by other third parties (e.g., K--12 systems). What should the nature of the relationships between these parties be, and what, if anything, needs to be known about the relationship between those parties?
- Identify use cases and functional requirements for what an InCommon IdP might want to know when receiving a request from one of these new SP-like entities:
- SP-proxies (e.g., the Terena proxy). The eduGAIN metadata will likely contain several of these. NIH has also proposed adding an SP-proxy to InCommon metadata.
- ordinary SP entities from eduGAIN that are added to the InCommon metadata aggregate
- SP entities sourced from REEP, which are "domain valid" instead of "organizationally valid"
- Where possible, requirements should be framed so that they might be represented in SAML metadata.
- Identify the information that should be included within future proposals associated with new entities.
- If there is time and interest, explore use cases and functional requirements for what an SP would want to know about an existing InCommon member IdP or SP (e.g., how important is it to know whether and IdP member reassigns EPPN values).
Items Out of Scope for this Effort
- Specify syntax, semantics, and usage for representing in SAML metadata the identified requirements.
Expected End Date
The subcommittee is expected to complete all deliverables and either close or recharter by October 31, 2014.