Metadata support: Extensions handling

[Ian Young]

On 13 Aug 2013, at 00:59, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> That was the main concern I had with this idea. I thought when we
> discussed this, we were thinking of having cached extensions that we would
> reference in the lower-down objects but not explicitly copy them.
> Basically turn them into objects we would attach as annotations, not as
> actual XMLObjects. I don't know how well that would work.

This is more or less how I recall the discussion.  Definitely not copying, but reference; and probably processed information rather than XMLObjects although if you're not copying I think that's an independent axis.

EntitiesDescriptors structures tend to be shallow (usually just one document-level EntitiesDescriptor), only have any Extensions at all in one place (at the root), and have very few different Extensions (really, just a KeyAuthority with some trust roots in it; although some federations are also putting in PublicationInfo I can't think of much in the way of use cases for that in the IdP not already covered by per-entity metadata like RegistrationInfo).

So it makes sense to handle these like you'd handle declarations in a programming language: maintain a context object which is passed down the tree and provided to leaf EntityDescriptors by reference.  At the root, start with an empty context; at an EntitiesDescriptor which has Extensions, mutate the context to incorporate the Extensions at that level.  You'd probably want that mutation to be be extension-specific although there really isn't a lot of mileage in that with what people are putting in these structures today, and I'd want to prescribe medication for anyone who invents new things that depend on EntitiesDescriptor hierarchies at this point.

In most cases, that would mean you'd have an initial empty context mutated into one that includes a bunch of trust roots when the document-level EntitiesDescriptor was processed, and that mutated context would be available to all descendant EntitiesDescriptors as well as all EntityDescriptors.  No copying.

I say context here deliberately because it does seem reasonable for generality for that to be the sort of class-indexed map style of object we're using elsewhere in the IdP.  That way mutating the context becomes a copy of the values in that map filtered through per-class handlers which can mutate their partial state depending on the presence of the extension they handle.  For KeyAuthority, that's probably just adding to a collection but it might be different for other extensions.  It seems to me that this design would handle any hierarchical extension semantics you could come up with, although as observed above we're really just talking about a couple of known things in practice, only one of which (KeyAuthority) we really care about.

	-- 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/20130813/7b76ef56/attachment-0001.bin