Per-Entity Metadata Working Group

[Nick Roy <>]

> On Aug 10, 2016, at 10:17 AM, Ian Young 
> <>
>  wrote:
> 
> 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.

If the 'Accept' header were something like samlmetadata/json (just making 
stuff up) could we produce a JSON-rendered SAML metadata document that would 
meet the needs of IdP discovery?

Nick

> ----
> 
> 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
> 
> 
> 
>