MDQ

[Ian Young]

> On 2021-02-03, at 20:23, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> On 2/3/21, 3:16 PM, "users on behalf of Christopher Bongaarts via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:
> 
>>   I think this may reflect some terminological confusion of what "MDQ service" means.
> 
> It's more fuzzy than that, MDQ as a spec does explicitly require (I think) exposing the /entities path.

Yes, the spec says what the /entities path means. The current text doesn't say anything much about being obligated to respond to that path. There have been some concerns that a federation operator might not want to do that for whatever reason, and if that ever becomes a real issue it might be made clear that you can refuse service (we'd probably have to extend the list of status codes).

Historically, this came about from the conception of the paths being in the RESTian mould, with the per-entity metadata being under the collection of entities.

Of course, if it was _really_ RESTian, the /entities path would probably be specified to return a list of pointers to all the entities, not the collection of them. It was an imprecise analogy, and in the end the way we specified this has probably caused more confusion than it's been worth. Hindsight, as they say, is 20/20.

If you're using the /entities path for an MDQ responder representing a whole federation (or, these days, essentially the whole R&E world) then it makes sense to use the FileBackedHTTPMetadataProvider because it does what you want for a big aggregate. It's just the same as pulling an aggregate from any other URL, and in practice it's probably implemented the same way too. As a client, you don't care about the implementation details on the server side.

The per-entity paths are just paths too, of course, which means that although if you're doing dynamic per-entity queries you need to use the DynamicHTTPMetadataProvider, if for some reason you have a need for per-entity metadata for a small static set of entities, you could also configure those using the FileBackedHTTPMetadataProvider with appropriately encoded paths. The Dynamic provider is clever enough for that to be an extremely niche use case, though, at least with Shibboleth.


    -- Ian




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210204/e1569c96/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3883 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20210204/e1569c96/attachment.p7s>