Child pages
  • Use Case Impact
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 27 Next »

Use Case Impact (this section is under development)

  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 require the ability to act differently depending on the source of the metadata.
      3. Importing IdPs into InCommon metadata will alter discovery interfaces across the Federation. Some SPs will want to filter such IdPs from their discovery interfaces.
    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 require the ability to act differently depending on the source of the metadata.
      3. Many IdPs will require the ability to act differently depending on if the SP is a member of the R&S Category or not.
      4. Some IdPs will require the ability to act differently based on if (i) AND (iii) are both asserted.
      5. Importing SPs into InCommon metadata will cause IdPs to automatically release attributes to those SPs. This may or may not be what those IdPs intended. We need to give IdPs a way to restrict attribute release, at least until they’ve had a chance to broach the subject with local data stewards.
      6. When SPs are imported into the production aggregate, an IdP that releases attributes to any SP is affected:
        <PolicyRequirementRule xsi:type="basic:ANY"/>
        Likewise an IdP that releases attributes based on the Name XML attribute in metadata is affected:
        <PolicyRequirementRule xsi:type="saml:AttributeRequesterInEntityGroup" groupID="urn:mace:incommon"/>
        IdPs need a way to mitigate these effects.
    3. Additional Information
      1. Recommendation: InCommon should convert 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 status.
      3. Recommendation: Introduce a new entity attribute that indicates whether or not an entity’s metadata has been registered by InCommon and vetted by the InCommon RA. (Every entity descriptor currently in InCommon metadata satisfies these two requirements.)
      4. Recommendation: Introduce a new entity attribute that indicates whether or not an entity’s metadata has been registered by InCommon but not vetted by the InCommon RA. (This addresses emerging use cases such as the Quilt use cases.)
    4. Questions on the R&S portion of the use case
      1. Should we recommend that 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. LIGO would benefit from the migration to a single R&S category (instead of the separate InCommon and REFEDs work.
      4. LIGO would benefit from more accurate metadata.  Existing metadata contains too much incorrect data, often issues in the area of support for ECP and Artifact Resolution. This may become more prevalent as the size of the metadata aggregate expands.
  • No labels