Click on the title of any column to reorder the list. # Name Document (if any) Issue Description Theme Scope for this group? Action Item 1 Warren Will publishing of InCommon IdPs and SPs into eduGAIN be opt-in or opt-out? opt-in/ In Scope for policy decision Key Issue. 2 Warren Will eduGAIN metadata feeds be aggregated into the InCommon feed or pulled separately by InCommon IdPs and SPs? Metadata practices Out of Scope; operational policy TAC 3 Warren Will InCommon simply publish the metadata as it arrives from eduGAIN, or will it add value, by, for instance: Metadata practices Minimally In scope TAC 4 Von Research SPs and making sure that the ease of obtaining attribute release that the Research and Scholarship category has enabled within InCommon expands to the international arena. R&S Out of Scope but Nota Bene; a related but not primary focus InC Ops/ 5 Ann FOPP Section 1. Add international context/role description Role Definition In Scope 6 Theresa FOPP Section 2. Organizational Structure: do we need a basic flow chart? Document Clarity Out of Scope Doc Editors 7 Bill FOPP Section 7.2 Relationship of Systems to Participant: Are ownership structures different in eduGain? Does that matter? Are their significant commercial or government systems influencing federations? [Warren's response] Legal/ Process In Scope ]]></ac:plain-text-body></ac:structured-macro> 8 Steven FOPP Update the IdP and SP definitions to better reflect the complexities of the environment. Participant System Definition In Scope with TAC support TAC 9 Bill FOPP Are the types of Identity Providers and Service Providers in eduGain substantially different entities than what we see in our federation? Are there different trust marks or certification marks than what we tend to use? If substantially different how will we inform our participants of what those entities are? [Warren's response] Participant System Definition In Scope with TAC support TAC 10 Ann FOPP Section 7.3.2 Metadata description needs to reflect interfederation InCommon Practices In Scope for draft; operational policy InC OPs/ TAC 11 Bill FOPP Do we need to include dispute resolution between federations? Dispute Resolution In Scope Key Issue ]]></ac:plain-text-body></ac:structured-macro> 12 Steven FOPP Section 9.2 InCommon must put in place processes to require the POP. Participant Practices; Nota Bene; AAC reviewing In Scope ]]></ac:plain-text-body></ac:structured-macro> 13 Theresa PA Disclaimer and Limitation: How will this be worded? Attorney's get really squeamish with these types of statements. Legal/ Process In Scope ]]></ac:plain-text-body></ac:structured-macro> 14 Ann FOPP Federation Technical Infrastructure will need mention of how eduGAIN is supported. InCommon Practices In Scope for Drafting 15 Ann PA Add description to section 1. Role Definition In Scope 16 Ann PA Update 6. Participant Requirements regarding governing law, accurate metadata, and documenting practices as needed for participant to support eduGAIN. Participant Requirements/ In Scope 17 Ann PA Section 7 InCommon Federation Services. Will be sharing metadata internationally as well. Upon request? opt-in/ In Scope 18 Bill PA Section 9. I suspect "privacy" rules are the biggest impact from a regulation standpoint. What are eduGains requirements from their participants in this area? [Donald's response] Privacy In Scope Key Issue 19 Ann PA Section 7: Federation Rules - Do we need to allude to other federations here or let the responsibility for applying those rules rest on InC to promulgate? [Bill's response] [Donald's response] ]]></ac:plain-text-body></ac:structured-macro> 20 Bill PA Section 13: Are edGAIN insurance requirements similar, equitable? Does InCommon verify insurance contracts of participants? 21 Theresa PA Section 15. Many public institutions are not allowed to agree to governance that is not within their state. Can this be reworded? 22 Group PA Participants have a choice and would sign a new agreement. Opt-out, we would send them the changes and propose a time when they would take effect. Either way, this the changes to this Agreement would be publicly vetted and discussed. opt-in/ 23 Ann PA Section 11: Is there an international impact on liability? Is there increased risk to the federation and participant? How should we proceed? Legal/ Process 24 Bill PA Section 10. Dispute Resolution: Should InCommon help with international disputes? Dispute Resolution ]]></ac:plain-text-body></ac:structured-macro> 25 Theresa PA Section 9. This is pretty ambiguous, can "as be required by federal and European law be added to the statement? privacy 26 All FOPP Section 10. Termination or Suspension: what does this mean in the international context? ]]></ac:plain-text-body></ac:structured-macro> 27 Steven Recommended attributes for interoperability: Includes SCHAC attributes. What does InCommon want to recommend to our members? 28 Steven eduGAIN uses two metadata fields that are not required or different from what we do. (isRequired and MDUI) What does InCommon want to recommend to our members? 29 Steven What configuration should we recommend to our IdPs and SPs? 30 Bill Why is there an additional risk statement on the FOPP page? https://incommon.org/docs/policies/risk_assessment.html Can this be eliminated or incorporated into the policies in some way? Trust? 31 Steven FOPP 32 Steven FOPP
In particular, if we make publishing metadata into eduGAIN an opt-in activity, it seems to me we might be able to simply have separate agreements and operating procedures for those efforts. It also seems to me as though we can start asking those IdPs and SPs that choose to participate what added value might be of most benefit to them.
opt-out
a) filtering eduGAIN metadata (to remove malformed metadata or metadata that does not comply with InCommon standards/expectations, metadata from commercial enterprises entering through other federations, etc?)
b) negotiating attributes release policies, entity category tags, SAML versions, hash algorithms, etc with other eduGAIN participating federations.
c) interpreting legal obligations related to PII or other attribute release from other federations to make it easier for InCommon IdPs and SPs.
d) other similar value-adding activities.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="122645a5-1e50-45c6-8cc5-a548694e28a5"><ac:plain-text-body><![CDATA[[John's response] Perhaps in an adjacent or linked document (TBD), InCommon Ops should publish our import filtering rules and export filtering rules in human readable format. Import filter will remove any tags we are authoritative for (e.g., InCommon Bronze, Silver), all certs <1024 bit key strength, duplicate md entries from eduGAIN sources, other filters...
]]></ac:plain-text-body></ac:structured-macro>
item C; operational policy
Wants to ensure that InCommon IdPs and SPs can participate in the international R&S standard. If we do come across any wording that would prevent participation in this program, we would address accordingly.
TAC
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="72095c26-7f2c-4dc4-bbe0-0b8feae367b3"><ac:plain-text-body><![CDATA[[Tracy's response] or a graphic?
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4f2f218b-ea8f-4383-9151-ade904be5aaa"><ac:plain-text-body><![CDATA[[Susan response] What about a federal inquiry? How do we handle those things that aren’t an adjudicated order? Or sensitive research with an entity in a hostile nation that raises questions from the US Gov?
Need an explicit definition of IdP, SP and other entities. Add to PA too.
. eduGAIN itself does not add additional tags to metadata of this sort.
7.3.2.1 Certificate practices check.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7ac9ec4b-a97c-4432-985d-1aed3407d5f7"><ac:plain-text-body><![CDATA[*[Tracy's response]* Could we get guidance from the Global Network at Berkman for international governance models?
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="63277222-7d23-47ef-8615-059f7e9f71e5"><ac:plain-text-body><![CDATA[[John's response] This is dealt with in eduGAIN policy.
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="20291686-7305-4226-b498-814f8d93cc67"><ac:plain-text-body><![CDATA[*[group discussion] *Is InCommon going to help manage or not? We are facilitators not arbitrators of Interfederation. There are legal and non-legal ways of handling dispute resolution.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="77e9928d-82f5-4de6-8894-67ce75ac4de9"><ac:plain-text-body><![CDATA[[Bill's Comments] Section 9.2 talks about "communications" and "support" but seems to be mainly about support. It states documents and POPs are published on InCommon Website. Is that the only communication requirement? Where are POPs published? I am not real familiar with the Federation Manager, does it allow users to browse POPs?
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="31ab29bb-5413-48ce-a55f-645a7fd5b3d6"><ac:plain-text-body><![CDATA[[Johns response] Do we need educate participants regarding international entities and lack of POP? Do we need require of InCommon IdPs/SPs before we export them to eduGAIN?
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="783b0efa-746c-46e7-b858-4a42bf2cb560"><ac:plain-text-body><![CDATA[[Group discussion] International implications
Practices
opt-out
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="1e5ba8e0-3716-454d-9ca1-68668d5e02f6"><ac:plain-text-body><![CDATA[[John] Yes, the provenance of each entity (i.e., the Federation responsible for each published IdP and SP) will be a "tag" that is stamped in each entity's metadata and retained when InCommon republishes each. In this way, InCommon participants will know which entities are based in InCommon and which are based in some other Federation's trust framework.
opt-out
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="02354900-56c7-46ce-ba9d-562d003014c1"><ac:plain-text-body><![CDATA[[John's comment] Liability:
]]></ac:plain-text-body></ac:structured-macro>
InCommon to Participant
InCommon to International Federations
Participant to Participant (external contract)
Participant to Participant (no contract)
Participant to International Federation Member (contract)
Participant to International Federation Member (no contract)
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d59c42fe-4b8f-4f2b-8fe9-c6df5a59e072"><ac:plain-text-body><![CDATA[[Bill response] Sounds like a slippery slop to suggest international dispute resolution. I will confer with Scott David for an opinion.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="105f4bdb-4382-4ad7-86e6-816b3c9e6de7"><ac:plain-text-body><![CDATA[[John] Suspension of Publishing Metadata. A fundamental question of how much power InCommon Participants would like to bestow to the Federation. Should InCommon import filter rules be minimal and necessary only for technical security reasons, or should InCommon act as a more active broker, with the power to drop international IdPs and SPs for a defined set of other reasons? Current federation policy is lean, increasing scalability and interoperability rather than a heavyweight policy enforcement role based on other non-technical issues. Is it important to consider certain minimal use cases such as international business treaties and hostile nation issues mentioned in #7?