Page tree
Skip to end of metadata
Go to start of metadata

Per-Entity Metadata Working Group - 2016-07-27
Agenda and Notes

[EtherPad used to create these notes:  Agenda_and_Notes_-_2016-07-27.etherpad]

Dial in from a Phone:
 Dial one of the following numbers:
 331718470 #
 Meeting URL (for VOIP and video): 
 Wiki space:


  • Nick Roy
  • David Walker, Internet2
  • Michael Domingues, University of Iowa
  • Tom Mitchell, GENI
  • Walter Hoehn, Memphis
  • Scott Koranda
  • Tom Scavo, InCommon/Internet2
  • Phil Pishioneri, Penn State
  • John Kazmerzak, University of Iowa
  • Ian Young
  • Scott Cantor, tOSU
  • Tommy Doan, Southern Methodist University
  • Rhys Smith, Jisc
  • Paul Caskey, 
  • Paul Engle

Agenda and Notes

  1. NOTE WELL: All Internet2 Activities are governed by the Internet2 Intellectual Property Framework. -
  2. NOTE WELL: The call may be recorded.
  3. Agenda bash
  4. Rhys Smith will present on his MDQ work for UK fed
    1. Planning to deploy an instance of mdq-server starting in August
      1. The mdq-server instance will run behind the firewall
      2. Signed per-entity metadata will then be pushed to a standalone apache server (possibly with a static cache)
      3. Every time new aggregates are created, the per-entity static cache is recreated
    2. Introduce a new signing key with HSM (Thales) on mdq-server (old key is 10 years old)
      1. Want to use a key that's never been anywhere but the HSM.
      2. No decision to migrate the aggregate's key at this time.  Could be done in the future, although it would be a good amount of work.
      3. HSMs can be expensive. Amazon's solution (buy one for you and rack it up) is "pretty eye watering" (Ian)
    3. Will implement a push model via github to distribute static signed per-entity metadata to cloud-based servers that are queried by IdPs and SP.
    4. A few months of pilot with selected customers
    5. Does it make sense to consider outsourcing of MDQ service?
      1. Yes, assuming the service is sufficiently secure, highly available, and not horrendously expensive.
      2. Our group should think about describing requirements for InCommon's MDQ service in a way that could be put into an RFP or SLA without too much effort.
  5. Begin in depth discussion: What are the risks for a per-entity metadata service and the possible mitigations
    1. Availability
      1. Need 100% availability, not even "5 9's"
      2. Internet2 would need to develop such a capability.
      3. This points to using a cloud infrastructure
      4. The model of pushing static files to a highly-available web service should enhance this.
      5. A there are things clients could do to mitigate this?
        1. Failure mode is the same as if the entity were not in an aggregate, if the entity is not already in the cache.
        2. Shib will cache entities until they are no longer valid.
      6. This is, by the way, how OIDC works
      7. What's important here is availability of the query service for IdPs and SPs
      8. Need to keep in mind not only failures of the actual service but locally inflicted problems that prevent consumers from getting to the service. How do they respond to a network outage that endures? What can a campus expect in that instance?
    2. Security
      1. Signing key
  6. Next call is August 3, 2016 @ 10:00 AM (America/New York)
    1. Scott K. will be out for this call
  • No labels