Per-Entity Metadata Working Group

[Ian Young <>]

> On 14 Sep 2016, at 17:41, Nick Roy 
> <>
>  wrote:
> 
> Just my personal opinions, take with appropriate grain(s) of salt.

[...]

>> 2) Does the server need to support HTTP Conditional GET?
> 
> I don't see why - any change to a _signed_ entity descriptor would probably 
> mean the entire signed entity descriptor needs to get completely 
> re-retrieved.

Yes, by definition, if something changes then you need to fetch it again; 
there's no provision for retrieval of partial documents in the specs.

It's possible that you mean that any change to the aggregate probably means 
all the per-entity metadata needs to be re-signed and that will result in a 
need to re-retrieve any per-entity metadata. That's pretty much true with the 
current production implementation, but it isn't necessarily a permanent 
characteristic. There is nothing that says that the validUntil has to be the 
same for all entities at any given instant, so the MDQ server (or batch 
signer) could in principle retain older signed metadata for individual 
entities through signing events. Whether that's worth doing would need some 
thought, but there is implementation flexibility here (server-side or as part 
of the tooling) if it looks like a worthwhile optimisation at some point in 
the future.

[...]

>> 4) Is there a cacheDuration on each entity descriptor, and if so, what
>> is its value?
> 
> I think the answer to this depends on how frequently we intend to publish 
> new signed metadata, so currently, maybe put it at 2 hours to ensure 
> changes are picked up in a relatively timely fashion, but we aren't 
> hammering the servers too hard.

If you want to push down the value of cacheDuration for whatever reason, the 
ability to support conditional GET at the server end becomes more important 
because the likelihood that the GET will be satisfied by what the client 
already has becomes higher. As Scott points out, you're not only re-fetching 
the document (with bandwidth implications, but also with latency implications 
for the client if you're not hiding that latency in a background pre-fetch 
thread, which at present we don't), but you're probably doing other work on 
receipt as well.

Conditional GET is simple to support, and I can't think of any reasons not to 
do so in practice. The MDQ spec requires responders to pass out the 
appropriate headers, and requires clients to make use of conditional GET for 
requests "to the same URL", but in practice the server could ignore that.

    -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature