Date:

Feb 26, 2014

Time:

12 Noon Eastern, 9AM Pacific, 5PM UK

Dial-in Info:

+1-734-615-7474 (English I2, Please use if you do not pay for Long Distance),
+1-866-411-0013 (English I2, toll free US/Canada Only)
PIN: 0195401 #

Agenda:
  1. Announcements, new agenda items
  2. InC counsel review of eduGAIN policy?
  3. Tom's document on eduGAIN metadata aggregation
  4. John's notes on eduGAIN policy framework.
  5. International R&S entity category.
  6. AOB
Attending:

Warren, Scott, Ann, Ian, Mark, Paul, Tom, IJ, Steven, Chris, 

Recording:
Minutes:
  1. Announcements
  2. InC counsel review - no news
  3. Tom's document on eduGAIN metadata aggregation
    1. Written for quilt project colleagues.
    2. Tom asks for input on "preview aggregate" stage - there is an automated process and then a manual process. Does it make sense to publish after the automated process as a preview? Scott didn't expect preview aggregate to be used in this way. He also thinks that having to do this seems onerous. Steven expects that InC will publish multiple aggregates and sites can decide which one they want to use - he sees the whole process as being more general. He expects multiple outputs on the right of the diagram. Mark says this fits what was discussed around the quilt perspective. He thinks it would be interesting to see how it works out as to where and how the manual process fits in. Tom agrees that the preview aggregate has not been viewed in this way before. He points out that if we could automate things sufficiently everyone would be happy to not have a manual step, but he's not sure if we will ever get to that step. He acknowledges that there might be multiple aggregates coming out, but he had not envisioned that. Ian says that the UK approach is to add new feeds to preview aggregate before going into the final aggregate, but the steps between preview and production is automated. Differs slightly between, say, eduGAIN and InCommon feeds. Ian doesn't think manually vetting is feasible, for example the French are considering adding all IdPs. If one has to check every time metadata changes it doesn't scale - for example the Polish metadata hash changes daily. Chris agrees that manually filtering should be avoided, and the goal to have automated filters that do what you need. He thinks that the key for distributing metadata is understanding what SPs are asking for in their discovery services. So, when they run discovery, what aggregate are they going to want - just regional, all R&S, etc. He wonders what InCommon sees from it's SPs. Tom thinks he can separate entity categories by tags so that the discovery service can use those tags to build custom discovery services. Scott agrees that aggregates are not the right way to configure discovery. He favors consistency and would like the interfederation case follow the federation case as closely as possible. He thinks fragmentation will hinder adoption. He would like to separate aggregation from discovery - he sees controlling the entities sucked into aggregates as a short-term strategy. Mark thinks discovery should be a key focus - in thinking about regional sub-federations, there will be entities that are not education based. For instance, there will be health services, etc that need to be accessed by education. The metadata won't follow the InC model necessarily and would be more easily presented as a separate aggregate. Chris agrees with Scott in that an international aggregate should be presented as a set of trusted entities in a clean way, but on the ground there are questions about how this affects discovery. Scott says this is why it's important to get out front, and if you choose to use the InCommon discovery service then you are implicitly supporting the large number of IdPs involved. If that's not what you want then you are using the wrong discovery service. Metadata aggregates should be like DNS, it presents what is available. Steven asks what kind of tools are available to people without a Shib SP for parsing. Scott mentions whitelist and blacklist which are coarse, but since it is xml you can write pretty much whatever you want. Tom says that there are not many software packages that can consume InC metadata at all, let alone filter it. Steven asks if simpleSAML can filter? Tom says not very well. Scott asks if we are talking about filtering or trust? Steven is thinking more about trust. Scott says either you're doing shib or you will have to write tools. Scott thinks that PING could be brought into use cases. Chris agrees that there are a limited number of tools, but since the data has a well defined format and structure, people can do what they want. He thinks the more interesting question is of entity categories. For instance, what happens if you get an entity with the R&S category, does it get pulled off with the filter? Steven says that the issue was raised for him by consulting with a school that is using ADFS - they will not have the skill needed to write their own filters for discovery. So if we don't have multiple aggregates, we at least need to give tools that provide a reasonable chance of success with the skills that exist. Scott points out custom aggregates idea from other conversations. If you want on demand, then really Shib is the only choice at the moment. Steven just thinks we need to have some strategy - might not be more than point ADFS users to Roland's tool.
  4. John's notes on eduGAIN policy framework - No update without John.
  5. International R&S entity category - Tom wants to review, but is considering operational questions of how to represent this and InC R&S at the same time.
  6. AOB - none.