Metadata support: EntitiesDescriptor/@Name handling

[Ian Young]

On 15 Aug 2013, at 23:50, Brent Putman <putmanb at georgetown.edu> wrote:

> Did we have a specific strategy for how to represent an
> EntitiesDescriptor/@Name on the descendent child EntityDescriptors?  If
> we've discussed this in detail, I must have brain block, so apologies.
> 
> My intuition is that it's probably an extensions entity attribute,
> correct?

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?

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.

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.

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.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20130816/af9acca6/attachment.bin