Metadata support: EntitiesDescriptor/@Name handling

[Brent Putman]

On 8/16/13 12:28 PM, Ian Young wrote:
> Separate to my response to what to do if this is case, can I step back a little and ask whether you mean that you're proposing "pushing down" EntitiesDescriptor/@Name values from higher in the EntitiesDescriptor tree and having them appear as part of the actual object tree for leaf entities, as if entity attribute values had appeared in the leaf entity DOM?

Basically yes.  Since we (apparently) no longer expose or want explicit
usage of EntitiesDescriptor, we have to represent the notion of "entity
group" (actually groups, since not singular) to which an entity belongs
directly on the EntityDescriptor itself.


>
> My assumption when we were talking about this before is that it wouldn't work like that, but appear in what I guess we're calling object metadata (the terminology here is hard) as some custom class representing presence in that specific kind of group.  Of course, there might be more than one and the multimap behaviour would allow for that.

EntityAttributes and XMLObject "object metadata" are the two obvious
candidates, yes.    I thought I had a vague recollection that we had
sometime somewhere discussed it probably being entity attributes.  Or
maybe it was something that Chad suggested at some point, perhaps not in
a wider forum.  But which approach to use is really the question at hand
and that's what I was asking.

I'm somewhat neutral on the choice.  The main difference I see is that
using "object metadata" is basically an internal API mechanism.  Using
EntityAttributes is a more general approach that could conceivably be
standardized.

On the latter, for example, I'm imagining that a metadata oracle (as we
were discussing on the call today) responding to the metadata query
protocol might apply "entity group" info to an EntityDescriptor that it
is returning, where that EntityDescriptor originally came from consuming
a batch of metadata that contained EntitiesDescriptors.  Basically, if
it doesn't have any way to represent that on the EntityDescriptor it
returns, then what it returns is lossy.

And so, to simply things like functors, etc, it makes sense for the
OpenSAML/IdP code to assume that same approach, since otherwise we'd
have to have 2 different sets of functors: one which looks at
EntityAttributes, and another which looks at internal object metadata.


>
> I know that conversations I had with Chad about this were around separating the match functor that matched on (hierarchical) EntitiesDescriptor/@Name values from anything else to avoid confusion.  Turning EntitiesDescriptor/@Name values into something that would mimic some other mechanism wouldn't have that effect.

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

So assuming that's all correct, there has to be an alternative means of
representing the parent @Name info directly on the EntityDescriptor.

One obvious primary case is the attribute filtering functors.  IIUC
those shouldn't be looking at an EntitiesDescriptor any more; in fact,
they can't since nothing is guaranteed to return or expose one.  (Also,
even in v2, those functors have names like *EntityGroup*, so there's not
an implicit connection to EntitiesDescritpors )

(As an aside, I'll mention that in the interests of time, etc, I'm not
currently planning to go to any great lengths in the resolvers to hide
and wipe away the existence of EntitiesDescriptors.  E.g. I may not
destroy the original metadata object tree, cause
EntityDescriptor#getParent() to always return null, etc.  It's an impl
detail, and there should probably be a note in the resovler Javadocs
that the EntityDescriptor#getParent() behavior is undefined and should
not be relied upon).

>
> That's not to say that it would not be a good idea to standardise an entity attribute with the explicit intention of having the same semantics as EntitiesDescriptor/@Name, but that's a different question than saying that our software should be turning one into the other internally by default.

Assuming that what I've understood about the proposed non-use of
EntitiesDescriptors is correct, I think they might have to be the same. 
Otherwise code that does "entity group" evaluation needs to be split
into 2 sets and/or needs to know which approach was taken on the
metadata it's consuming.

I suppose we could ignore the potential future standardization case, and
just treat it all as internal for now, and use object metadata.  That
choice is essentially my question.