Child pages
  • Use Case Impact

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Quilt InCommon Initiative to Extend Federation to K12 and Community Colleges
    1. What does an InCommon SP need to know
      1. In real time, if individual in question is under age (under 13 or uner 12)?
      2. If the request is from an entity that has directly signed or indirectly signed the InCommon participation agreement (Cases I, 2, 3, and 4)
      3. In Case 4, the Full Service Steward Model", the InCommon member is required to pass the terns and conditions of the InCommon participation agreement on to its embers.  The InCommon member assumes liability for the actions of the entities listed in the metadata.
      4. Case 5, Full Federation Operator, is an interfederation issue and is not discussed here,
    2. What does an InCommon IdP need to know
      1.  If the request is from an entity that is operating under the terms of the InCommon participation agreement (Cases I, 2, 3, and 4)
    3. Additional Information
      1. The general question of student age and the different legal responsibilities that exist for different age groups is an issue, but not an issue for metadata and hence not the purview of this working group.  This group recommends that IdPs serving the K-12 community that are placed into the InCommon metadata be required to use new, yet to be defined eduPerson / k12Person attribute(s), to describe the age classification of the end user.
         
  2.  IdP Proxy (proxying either IdPs or SPs) as a Metadata Entry
    1. There is no fundamental problem with multiple services being offered behind a single entity-id in the InCommon metdata.
      1. InCommon policy should clearly state that such entities must be under the administrative control of the same legal entity.
      2. Advice to service providers should be documented to advise against the over-aggregation of services as it will make it less likely that IdPs will releae attributes to overly aggregated SPs. 
    2. What does an InCommon SP need to know
      1. No metadata changes needed
    3. What does an InCommon IdP need to know
      1. No metadata changes needed
    4. Additional Information
      1. We do not yet understand enough about Case 2, IdP proxy "in front of" multiple IdPs (that may be in the InCommon metadata themselves) to comment on potential metadata needs.
      2. IdP proxies that cache might be problematic as they might not accurately mirror the source IdPs attribute release policies.
      3. The committee suggests that, for now, InCommon policy clearly state IdP Proxies and their "proxied IdPs" must all be under the control of the same legal entity.
         
  3. EU IDP accessing SP at Brown
    1. What does an InCommon SP need to know
      1. No metadata changes needed
    2. What does an InCommon IdP need to know
      1. No metadata changed needed
    3. Additional Information
      1. This need to assert that an InCommon SP follows the EU Privacy Directive could also be considered as an interfederation issue.
      2. Group: do we recommend that InCommon members be given a way to self-assert a fixed set of attributes about their SPs in the InCommon metadata?
         
  4. Course with US-based and EU-based students
    1. What does an InCommon SP need to know
    2. What does an InCommon IdP need to know
    3. Additional Information
       
  5. eduGAIN Metadata
    1. What does an InCommon SP need to know
      1. Some SPs will require the ability to act differently if the IdP is operating under the terms of the InCommon Participation Agreement than if it isn't.
      2. Some SPs might SPs might require the ability to act differently depending on the source of the metdatametadata.
    2. What does an InCommon IdP need to know
      1. Some InCommon IdPs will require the ability to craft their attribute release policy based on if the SP is operating under the terms of the InCommon Participation Agreement or not.
      2. Some IdPs might IdPs might require the ability to act differently depending on the source of the metdatametadata.
      3. Many IdPs will require the ability to act differently depending on if the SP is a member of the Ris a member of the R&S Category or Category or not.
      4. Some IdPs will require the ability to act differently based on if (i) AND (iii) are both asserted.
    3. Additional Information
      1. Recommendation: InCommon should convert MFRPI MD-RPI elements into appropriate metadata entity attributes.
      2. Recommendation: InCommon should tag all InCommon SPs and IdPs operating under the terms of the InCommon Participation Agreement with an entity attribute that specifies InCommon membership InCommon membership status.
    4. Questions on the R&S portion of the use case
      1. Should we recommend that InCommon maintain InCommon maintain both InCommon R&S attributes and add in eduGAIN R&S to ease the migration path.
      2. Should we recommend that InCommon maintain separate metadata distributions for InCommon-only and InCommon + Interfederation
      3. What else?
         
  6. LIGO as an International Virtual Organization
    1. What does an InCommon SP need to know
      1. No metadata changes are needed
    2. What does an InCommon IdP need to know
      1. No metadata changes are needed
    3. Additional Information
      1. LIGO would benefit from a larger percentage of IdPs supporting R&S
      2. LIGO would benefit if more IdPs were to change their default attribute release policy to release EPPN even if they don't support R&S.
      3.