InCommon metadata support

[Nick Roy <>]

Hi Tom,

On 7/20/18 1:14 PM, Tom Poage wrote:
> Any update on the production MDQ service? I'm starting to run across
> vendor implementations that want a URL to fetch metadata and, in many
> cases, can't/won't support the size of aggregates. Of course, offering
> these vendors our IdP metadata endpoint is the last solution on the list
> to be offered.
> 

We are getting very close to having an internal test environment using
the components we intend to take to production. Some of the hurdles
along the way included overcoming the Amazon HSM's current inability to
integrate correctly with PKCS#11 in Java applications, and having to
write some Lambda@Edge code to handle the URL rewrites. We are through
most of that, and working on getting everything into deployment
templates so we can automate deployment. We'll then get into internal
testing, figuring out how to do service monitoring and shipping the logs
off to our centrally-managed log aggregation service. We also need to
perform a key generation ceremony which needs to be highly secure, well
documented, and with witnesses present who will attest to the ceremony
being carried out as written. That will take some time to document and
then assemble the needed people and equipment to perform key generation.

I hope to have things in a production mode later this year.

>  
> 
> Speaking of vendors, it's difficult to know for sure if they've
> validated the signature on downloaded metadata (even when asked). Odd
> thought, what if instead of (or in addition to) metadata signature,
> metadata is encrypted by e.g. the MDQ private key? Then vendors etc.
> would be forced to successfully decrypt what they download to make it
> useful (a form of validation). No, it doesn't give the truly lazy an
> out, like now, but seems a significant step toward ensuring that
> downstream consumers have gone through some kind of check on what
> they've fetched.

An intriguing thought, but global metadata is unencrypted by design, so
we have to provide unencrypted metadata to eduGAIN, at a minimum.
eduGAIN then republishes that unencrypted metadata globally. Any time we
raise barriers to entry, we potentially drive people to short-circuit
our otherwise good intentions. Moving all global federations to
encrypted metadata would pose an enormous change management problem for
all federations and their participants.

Best,

Nick

> 
>  
> 
> Thanks.
> 
> Tom.
> 
>  
> 
> *From: 
> *<>
>  on behalf of Nick Roy
> <>
> *Reply-To: 
> *""
>  
> <>
> *Date: *Thursday, March 8, 2018 at 11:13 AM
> *To: 
> *""
>  
> <>
> *Subject: *[Metadata-Support] Re: MDQ status?
> 
>  
> 
> Hi Tom,
> 
>  
> 
> We are working on productionalizing the MDQ service. Because of the need
> for high availability, combined with the need to handle signing keys in
> a very secure way, it is taking some time to do the planning.
> 
>  
> 
> Best,
> 
>  
> 
> Nick
> 
>  
> 
> Nick Roy
> 
> Director of Technology and Strategy, InCommon / Internet2 Trust and
> Identity Services
> 
> ------------------------------------------------------------------------
> 
> *From:*
> <>
>  on behalf of Tom Poage
> <>
> *Sent:* Thursday, March 8, 2018 11:26:58 AM
> *To:* 
> 
> *Subject:* [Metadata-Support] MDQ status?
> 
>  
> 
> I have some SP operators noticing/complaining about the ever increasing
> amount of time to start the SP. I think they're using all the usual
> tricks of e.g. using the IdP-only aggregate, increasing timeouts and the
> like.
> 
> What's the status of the MDQ service? I haven't looked in detail, but do
> see some comments on productionalization from c. September.
> 
> Thanks!
> Tom.
>