InCommon metadata support

[Tom Poage <>]

Two part question:

The MDQ beta server doesn't look to support conditional GET. Are there plans 
to do so? Does it make sense to do so? Cf.

https://github.com/iay/md-query/blob/master/draft-young-md-query.txt

> 4.1.  Conditional Retrieval
> 
>    Upon a successful response the responder MUST return an ETag header
>    and MAY return a Last-Modified header as well.  Requesters SHOULD use
>    either or both, with the ETag being preferred, in any subsequent
>    requests for the same resource.  In the event that a resource has not
>    changed since the previous request, the requester will receive a 304
>    (Not Modified) status code as a response.


mdq-beta does return an ETag:

X-Application-Context: application:sign:80
Content-Language: en
Content-Type: application/samlmetadata+xml; charset=UTF-8
ETag: "fac6ce52527791497340696ca2927bdf8e618360"
Content-Length: 9453
Server: Jetty(9.2.15.v20160210)

If I try a modified procedure listed for the aggregate server:

https://spaces.internet2.edu/display/InCFederation/HTTP+Conditional+GET

E.g.

curl -D- -o foo.xml --header 'ETag: 
"fac6ce52527791497340696ca2927bdf8e618360"' 
http://mdq-beta.incommon.org/global/entities/urn%3Amace%3Aincommon%3Aucdavis.edu

It downloads the file instead of returning a 304.

So here's where I'm headed:

A vendor insists on fetching only our IdP metadata (no aggregates), and 
started off (against our advice) using /idp/shibboleth. Yes, self-asserted 
metadata again.

I could point them to mdq-beta, though I expect this host will change some 
day and, if we're not paying attention, it could break one or more apps.

I could 'poison' /idp/shibboleth, replacing the XML with a warning message. 
;-)

So I thought I'd try an experiment: consider inserting the signed 
MDQ-provided XML in place of our idp-metadata.xml (or whatever the 
idp.entityID.metadataFile property references). Of course, the remaining 
trick is to get said vendor(s) to validate the signature (until other ways of 
doing this become available).

The following looks to (1) cache metadata to the file system and (2) (I 
think) _not_ load it into the IdP:

    <MetadataProvider id="InCommon MDQ UCDavis"
                      xsi:type="FileBackedHTTPMetadataProvider"
                      
metadataURL="http://mdq-beta.incommon.org/global/entities/urn%3Amace%3Aincommon%3Aucdavis.edu";
                      backingFile="%{idp.home}/metadata/idp-metadata.xml"
                      maxRefreshDelay="PT6H">
         <MetadataFilter xsi:type="SignatureValidation"
                         requireSignedRoot="true"
                         
certificateFile="%{idp.home}/credentials/mdq-beta-cert.pem" />
         <MetadataFilter xsi:type="RequiredValidUntil" 
maxValidityInterval="P14D"/>
         <MetadataFilter xsi:type="EntityRoleWhiteList">
             <!-- empty -->
         </MetadataFilter>
     </MetadataProvider>

An IdP's metadata is unlikely to change very often, so maybe updating every 6 
hours (cf. cacheDuration="P0Y0M0DT6H0M0.000S" in the content) in the absence 
of conditional GET is overkill.

I'm trying to figure out if this reassertion of the MDQ XML provides any 
benefit vs. simply pointing the vendor(s) at mdq-beta (and keeping an eye on 
developments here) vs. the same old ways of transferring the XML through some 
other semi-trusted means (box.com/O365/Google folder, type it out on a slip 
of paper ;-) ...).

Thoughts?

Thanks.
Tom.