Metadata Distribution Subcommittee of TAC

[John Krienke <>]

Feel free to add/modify here:
https://spaces.internet2.edu/x/_ICDAg



Present: Tom Scavo, John Bradley, Harry Nicholos, Don Faulkner, Ian Young, 
Scott Cantor, Mark Scheible, Paul Caskey, Nate Klingenstein, John Krienke

Phase 1 Discussions
Expired certificates in MD: This is a parallel communication effort that we 
may not want to 
conflate with communication about the signing key issues.  Note: CA 
siteminder and ADFS may also not like expired certs. AI Ops will follow up on 
expired certs after we communicate about the signing key and CA.


Phase 2 Discussions.

Medium Term Issue. Local Metadata Aggregates.
---------------------------------------------

UARK maintains a local metadata aggregate (MDA) today, and wants to federate 
services within a state network and looking at how to tier it, for locally, 
regionally, nationally distributed MD. Many SPs for local-only use but don't 
want to advertise their existence in the public InCommon MDA. Similar to work 
InCommon is piloting with CMU on producing local-only MDA for participants.

How would we know which IdPs or SPs we should trust? One option would be 
Entity Categories like R&S. Tag the interested IdPs and SPs as category tags.

What is the value of a local MDA? Discussion revolved around not so much 
confidentiality as maintenance and distribution. Shouldn't have to publish 
every entity into the InC Federation. But the more alike the processes are, 
the more manageable they become.

Is goal to hide an entity via local MA, or to simply not include in the big 
public MDA? Two different goals. Entity MD solves this. Batch case solves 
this by customized local MDAs. To lock down the MDA is harder (presumably by 
encryption, and this is not the use case of concern voiced by anyone on the 
call).

How do you move an entity from local, to regional, to national MDA? MDX is 
supposed to solve this use case. MDX addresses requirement of not having to 
fetch MD that you don't need. You never need to fetch what you don't need.

There are people who are concerned about hiding things. Need to make it clear 
and frame and clarify that local MDA is not true hiding (i.e., 
confidentiality) but is more 
management related. Not confidential, but rather local. Secrecy is not high 
on the list of priorities in MDX as written; however, filtering is more the 
focus.

Consuming Multiple MDAs or a Single MDA:
From the Shib perspective, no intrinsic distinction/preference. Only an 
operational question. 
Probably more convenient as you diverge from Shib to consume 1 rather than 2 
MDAs. Paul follows single MDA but no compelling preference. OSU consumes 
multiple (InCommon + local).

More interesting to think about online use cases. When does signing 
occur and how often? Campuses currently have next day delays. OSU signs their 
local MDA on the fly all the time. Hassle to wait a day for InCommon. OSU 
doesn't sign, just pushes using rsync. Paul & Harry both publish once daily, 
with occasional out of cycle, similar to InCommon. Don publishes every 15 
minutes with automated signatures (due to fast growth). Local test IdP for 
testing, production IdP. Both consume the local MDA. Files end up on a web 
server, pulled down similar to InCommon MDA. OSU has two separate MDAs for 
non-campus and campus. 


Per Entity MD and Online/Offline Signing
------------------------------------------------
How to shape the discussion. 

MDX and per entity MD publishing don't necessarily imply online signing. MDX 
can be seen as an addressing scheme. Per entity could be published once a 
day, addressed by MDX. Can still do these things w/o dynamic online signing.

Scott mentions performance issues, a good question. 
Java based signing program for Shib project -- overhead spinning up a JVM 
every time 
you do a signature. Not good performance. But doesn't relate to architecture. 
MDX 
designed to do things that are not compatible with online signing. Like 
custom 
aggregates on demand with query parameters. Interfed not moving in this 
direction with custom queries.

Also there is a Jira request on the Shib MDA code to sign a pile of 
things and push them into separate files (rather than signing the MDA). Not 
difficult.

Use entity categories as filters for MDA. Create the aggregates offline then 
sign. Have to know ahead of time what people want to query against. R&S 
discovery is a reasonable support query as offline signing but not on demand 
queries as DOS attack (i.e., arbitrary queries -- which can be used as 
unbounded resource requests).

Next up for conversation:
SOFTWARE requirements for per entity MD requirements. 


One Action to add to our list:
-----------------------------------------------

AI Ops will communicate about the expired InCommon certs in md in a separate 
email communication after we communicate about the signing key and CA trust 
anchor.