spaces.at.internet2.edu has been upgraded to Confluence 6.15.10. If you have any questions and/or concerns, please contact us at techsupport@internet2.edu
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 50 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 members.  The InCommon member assumes liability for the actions of the entities listed in the metadata.  A globally unique URI from the QUILT aggregator will be used as the registrar in the metadata.  (Note: incommon.org is always asserted as the registrar in cases of an entity having full InCommon membership (participation agreement signed) e.g., case i or ii).
      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 (deferred discussion for next week) 
    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.  This administrative control includes vendor provisioned services that are under contract to the InCommon legal entity.
      2. Note that a proxy SP registered in InCommon metadata is still subject to section 9 of the InCommon participation agreement. That is, the proxy is responsible for ensuring appropriate use of the data by all of the SPs that it proxies for.
      3. 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. IdP proxies that cache might be problematic as they might not accurately mirror the source IdPs attribute release policies.
      2. 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. Add an exemption for Use Case #1 above
      4. InCommon is currently not capable of dealing with a single entity-id that is used for both an IdP and SP.  This committee does not, at least at this time, recommend that this capability be added to InCommon's infrastructure.
         
  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 EU IdP need to know
      1. Which attributes are required/optional for this SP
      2. That the SP will only use the asserted attributes in a manner compatible with the Code of Conduct
    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? (The proposal described in the "MARI plan and next steps" may simplify how this set of attributes is expressed.)
         
  4. Course with US-based and EU-based students, LMS is commercial and based in the US
    1. What does an InCommon SP need to know
    2. What does an EU IdP need to know
      1. Which attributes are required/optional for this SP
      2. That the SP will only use the asserted attributes in a manner compatible with the Code of Conduct.
    3. Additional Information
       
  5. eduGAIN Metadata
    1. What does an InCommon SP need to know
      1. Some SPs might require the ability to act differently depending on the source of the metadata.
      2. 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: Tag every entity descriptor in the production aggregate with a new entity attribute value (extended-validation-metadata). Resist the urge to create a new aggregate.
      2. Recommendation: Import eduGAIN metadata directly into the production aggregate. Start by importing IdP metadata from eduGAIN since the impact on InCommon SPs is less than what it will be for InCommon IdPs.
      3. Recommendation: Strongly recommend against the use of the AttributeRequesterInEntityGroup type in IdP attribute release policy. Advise IdP operators to re-evaluate the use of the basic:ANY type in attribute release policy.
      4. Recommendation: De-emphasize the <mdrpi:RegistrationInfo> element as a direct source of attribute release policy. Instead expose the registrationAuthority XML attribute value as an entity attribute.
      5. Recommendation: Bring the beta metadata query server (mdq-beta.incommon.org) to production (mdq.incommon.org) as a distinct server environment (i.e., distinct from md.incommon.org).
      6. 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.
      7. Recommendation: Consider introducing 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.) Recommended value: {{ http://id.incommon.org/category/organizational-valid-metadata}}
      8. Should we recommend that InCommon maintain separate metadata distributions for InCommon-only and InCommon + Interfederation
        1. (No, otherwise we force deployments away from production metadata. See: Importing eduGAIN Metadata)
           
  6. LIGO as an International Virtual Organization (what does LIGO have to do with new entities in metadata?)
    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.
        1. (No, LIGO filters all but R&S IdPs, so LIGO would not benefit from this)
      3. LIGO would benefit from the migration to a single R&S category (instead of the separate InCommon and REFEDs work).
        1. (I don't see how this matters)
      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.
        1. (Everyone would benefit from more accurate metadata)
      5. LIGO might benefit if we tested and tagged interoperable IdPs
        1. (LIGO would first have to be persuaded to consume all InCommon metadata)
           
  7. Campus metadata in InCommon Metadata
    1. Should there be a difference in the registration authority metadata for entities where the campus entered volumes of local metadata (e.g., the CMU case) ?
  • No labels