Metadata support: EntitiesDescriptor/@Name handling

Brent Putman putmanb at georgetown.edu
Fri Aug 16 14:07:55 EDT 2013


On 8/16/13 1:46 PM, Brent Putman wrote:
> Not sure if I completely understand what you mean, but: I think the
> intention was that nothing in v3 that is documented, part of an API,
> etc, should ever be evaluating an EntitiesDescriptor instance, period. 
> For most intents and purposes, we effectively pretend it doesn't exist
> (except in the batch-oriented MetadataResolvers themselves, for obvious
> reasons).  What I heard in Columbus was that that was one of the major
> goals of metadata redesign (I seem to remember an email thread during
> the meeting that Chad was active on, I'll see if I can dredge that up).

I found the thread.  I had forgotten about the comprehensive writeup you
did here:

https://wiki.shibboleth.net/confluence/display/~ian@iay.org.uk/MDA+IdP+V3+Design+Notes

And then what I remembered about Chad was him saying:

> As expected, I'm in agreement with Ian.  He and I have had our heads together on this topic for quite some time now.  For me, the main take aways from the MDA work is:
>
> <snip>
>
> - Use of EntitiesDescriptor within the system is should be a big warning flag and stamped out whenever it shows up.  I think in the grand scheme of things, it would have been much better if the SAML metadata spec simply had an <EntityDescriptors> element and it was basically defined as "just the document element".


Quickly rereading what you said there, I see you basically advocating
for the item/object metadata type of approach for representing the @Name
info, which I had forgotten.

As far as I'm concerned, that's fine, I have no particular vested
interest in using EntityAttributes.

I would like to hear your (or anyone else's) thoughts, if any, about
what a metadata oracle/query service would do (or not) about
representing batch source @Name info (and I guess also
EntitiesDescriptors Extensions?) on the wire for the EntityDescriptors
it returns.





More information about the dev mailing list