[mdx] Small change proposed to draft-young-md-query-saml-07

[Tom Scavo]

On Thu, Nov 9, 2017 at 9:42 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
>> That is a far-fetched example but even so the MDQ spec is (or should
>> be) very clear about what happens in this edge case.
>
> I don't know that it *can* be, it still exists at a layer that's divorced from the actual management of systems.

Your reference to "ham sandwich" on the dev list made me realize that
if we profile the use of an auxiliary list of transformed identifiers
(or whatever you want to call them), then an MDQ server implementation
can support *all* artifact types, including Type 2 artifacts, without
violating the spec. That just seems wrong.

This seems like a reasonable goal: An SP that relies on an aggregate
from publisher X should have exactly the same experience if (and when)
the SP migrates to an MDQ server run by publisher X. That is,
migration to MDQ should be seamless. In that case, an MDQ server
implementation should be strict in its handling of transformed
identifiers since this mimics the experience of an SP that relies on
aggregate metadata.

Consequently the MDQ spec should be strict as well: If the transformed
identifier is not on the list of hashed entityIDs, the responder MUST
return an HTTP 404 response.

This assumes there are no <SourceID> elements in metadata. If there
are, an MDQ server implementation should take them into account in the
same way an SP that relies on aggregate metadata handles <SourceID>
elements. (I don't know if your SP does or not, I'm just saying.)

Tom