Per-Entity Metadata Working Group

[Tom Scavo <>]

On Thu, Oct 13, 2016 at 12:51 PM, Christopher Hubing
<>
 wrote:
>
>
> On Thu, 13 Oct 2016, Tom Scavo wrote:
>
>> On Thu, Oct 13, 2016 at 12:02 PM, Christopher Hubing
>> <>
>>  wrote:
>>>
>>> So, for example, you could hit one of the URLs below and be returned
>>> metadata for that entityid (or insert one of your own entityIDs). It
>>> currently uses a self-signed cert, so ignore any SSL warnings.
>>
>> How does the CDN manage the TLS key?
>
> It's user managed, you configure from the AWS Console or command line for
> each custom domain you wish to serve.

Sorry, I forgot you are new to the group. Patrick and others have
mentioned that some CDNs will retrieve the TLS key via a secure
channel, thereby precluding the need to store the key in the
filesystem.

Does your CDN have this feature? (this is an indispensable feature IMO)

>> The signing will be done (daily) on current infrastructure and the
>> signed entity descriptors will be pushed to the MDQ server. How does
>> your deployment change in that scenario?
>
> Changing from a pull to a push would require some code to run on the server
> that would push these signed entity descriptors out. Right now, this just
> grabs the aggregate from
> http://md.incommon.org/InCommon/InCommon-metadata.xml and pushes it into
> DynamoDB.

Right, let me explain a bit more. The MDQ server doesn't do anything
except serve static files according to the spec (which is pretty much
what Scott was saying). Ops will sign the metadata on current
infrastructure and push the signed files to the MDQ server. In your
case, it seems the files need to be pushed directly into DynamoDB. Can
that be done remotely?

Tom