Per-Entity Metadata Working Group

[Ian Young <>]

I've been rather busy, so it is taking me a while to get back to some of the 
less urgent stuff.


> On 27 Jul 2016, at 16:39, Tom Scavo 
> <>
>  wrote:
> 
> Okay, so the current MDQ protocol spec mandates (I believe) that an
> MDQ server MUST serve up an "all entities" aggregate at a pre-defined
> endpoint.

Well, what the current draft says is:

----
A metadata query request for all entities known to the responder is
performed by issuing an HTTP GET request to a URL constructed as the
concatenation of the following components:

   o  The responder's base URL.

   o  The string "entities".
----

So the main intention here is to say how you'd make such a request, not 
whether the server is obligated to respond with one. In fact, you may recall 
that we decided not to respond with such an aggregate in the case where the 
query was not explicitly requesting SAML metadata, so that someone who 
pointed a browser at the location by accident would just get a summary. For 
example:

        http://mdq-beta.incommon.org/global/entities

Having said which, the current draft also says (in 3.2.3):

----
The response to a metadata query request MUST be a document that
provides metadata for the given request in the format described by
the request's Accept header.
----

That's obviously inconsistent with the current behaviour, and I remember 
intending to change it to give an implementation permission to say "no" if it 
wanted. It's also obviously not something an implementation can comply with 
if it doesn't have metadata responsive to the query, so the text needs to 
change in some way anyway.


> On 27 Jul 2016, at 18:07, Tom Scavo 
> <>
>  wrote:
> 
> I don't expect Ian to run off and change the spec, however ;-)

I'm not in favour of throwing the baby out with the bathwater, certainly. I 
think the spec needs a way of saying "all of them", but by the same token I 
am not opposed to some change in the wording giving an implementation more 
leeway in its response.

If people have suggested revisions to the text, let me know. I am overdue in 
pushing a new rev of the draft to the IETF anyway, I mainly haven't bothered 
because there were no useful changes. If we have some, I can do that fairly 
quickly.

    -- Ian

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