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 13 (if collecting PII from user - see: http://www.coppa.org/comply.htm)
      2. If the request is from an InCommon Member (entity signed the InCommon participation agreement) (Models 1, 2, 3)
      3. In Model 4, the Full Service Steward Model", the InCommon member (the Steward) is required to pass the terns and conditions of the InCommon participation agreement on to its Represented Constituents.  The Steward 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 ii).
      4. Model 5, Full Federation Operator, is an interfederation issue and is not discussed here,
    2. What does an InCommon IdP need to know (What's the scenario here?  Why would another IdP need to know anything?  Are we talking about an SP run by an entity that is not a member - Model 4?)
      1.  If the request is from an entity that is operating under the terms of the InCommon participation agreement - Models 1, 2, 3 (or 4 if it's the Steward)
    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. Does the group recommend that InCommon SPs that serve the K-12 community, K-20, or the general public, be required to "consume" the above referred to attribute(s)?
    4. 2015-01-08 Discussion Summary - start here on our next call.
      1. One of our goals is to make it easy (e.g., via a simple Shibboleth configuration) for relying parties to be able to emulate the existing InCommon metadata distribution. Fundamentally, this means transmitting knowledge if the metadata entity is operated by a legal organization that has signed the InCommon participation agreement and gone through the InCommon registration processes.
      2. Carrying this concept forward, think of "has signed the InCommon participation agreement" as the existing proxy for what in the PKI world would be a CP/CPS.   We call it here a Registration RP/RPS.
      3. There will be new RP/RPS cases in the InCommon metadata in the future. The first such case is a relatively rare Quilt use case where a school district is running their own IdP, the school district has elected not to execute the InCommon participation agreement, and the metadata for their entity is placed into the InCommon aggregate by a third party under contract to Internet2 (e.g., a regional network).
      4. Discussion Proposal(s)
        1. Short Term (where t is some small integer - a year or two)
          1. We use the "registrarID" entity attribute to convey both the name of the registrar and the "RP/RPS" that the registrar used for this particular entity.
          2. If the entity is operated by a legal organization that has signed the InCommon Participation Agreement, the Registrar value will be: https://incommon.org
          3. If the entity is operated by a legal organization that has not signed the InCommon Participation Agreement, the Registrar value will be different. The first such Quilt use case could be covered with a Registrar value such as: incommon-steward.org https://example.org
        2. Longer Term (where t is some larger integer, likely a few years from now)
          1. The registrar and policy/practices concepts would be split into two different variables
          2. The RegistrarID entity attribute would be the name of the entity that performed the registration work. A value of   https://incoommon.org   -https://example.org-   would be used for entities that were directly registered by InCommon and for entities that are registered by third parties under contract to InCommon. We are not presently aware of entities that InCommon would add to the metadata that would not be listed with https://incommon.org   -https://example.org-   as the RegistrarID.
          3. A new "RP/RPS" entity attribute would be added to the metadata to specify the policy/practices of the registration. Some initial known values would be terms such as: incommon-participant (has signed InCommon agreement RP/RPS) and steward-participant (some steward RP/RPS).
        3. We do need to consider transition issues in our discussion. Another topic might be if our threshold should be the number of different RP/PRS categories instead of time.
  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.  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.  We do not know why anyone would need this capability even though we see some of this type of entity in the eduGAIN metadata.
         
  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.)
      3. See also Section 4.c
         
  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
      1. While perhaps slightly out of scope but certainly interrelated, one of the main questions with #3 and #4 is if InCommon is willing and able to support a set of self-asserted entity attributes such as EU Code of Conduct.  The import of eduGAIN metadata will be less useful if InCommon entities are not able to populate metadata with needed attributes.
         
  5. eduGAIN Metadata (we will continue here on January 8, 2015) 
    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 some 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 (e.g., extended-validation-metadata). Resist the urge to create a new aggregate. 
      2. Recommendation: Import eduGAIN metadata directly into the production aggregate. Begin 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. 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)
    4. Plan Discussion - as of 20141218
      1. InCommonOrgPolicy -  the only current known value will be "this entity is under the control of an organization that has signed the InCommon Member Agreement"
        We will add a new metadata entity attribute that states that the entity is an InCommon member with a signed InCommon participation agreement in place.
      2. RegistrationAuthority - Values: InCommon, eduGAIN, etc.;  See 5.c.4 for how this eduGAIN requirement works
        Following the eduGAIN requirements for a Registrar entity-attribute solves some other use case issues.
      3. With (i) and (ii) above, we recommend a single production metadata aggregate
      4. Question: 5.d.i and 5.d.ii are redundant if we will never have a second defined value for 5.d.i.  Which use cases drive this?  Will it always be the case that InCommon will only add an entity to the metadata when it is certified that the entity is under the direct control of an organization that has signed the InCommon participation agreement?
      5. Transition plan: next topic
      6. Question: any discussion / recommendation for InCommon filtering of eduGAIN data (proxies, etc.)?
  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)?
      1. 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. Recommended value: {{ http://id.incommon.org/category/organizational-valid-metadata}}