Metadata support: EntitiesDescriptor/@Name handling

[Ian Young]

On 16 Aug 2013, at 19:07, Brent Putman <putmanb at georgetown.edu> wrote:

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

When you're talking about a metadata query service, you're in a different position than you are inside an application like the IdP, because the wire representation is restricted to be conventionally valid SAML metadata.

The simple answer to your question is obviously that everything that comes out of such a service has to be SAML metadata; I think it's the wrong question, though.

EntitiesDescriptor/@Name and EntitiesDescriptor/Extensions/* are not things that you should be thinking of representing within single-entity EntityDescriptor metadata returned by a query service.  They are themselves representations of underlying concepts, and the question for a metadata query service becomes how you represent those concepts in the metadata, if indeed you decide that you need or want to do so.  Put another way, in a metadata query service, there is no EntitiesDescriptor/@Name to be represented, but there may be groups that entities are members of.

In the case of the trust root extension, for example, someone who is far enough down the line to want to serve up per-entity metadata is probably past the point where trust roots make sense.  You pretty much need to dump all of that to make interfederation work plausibly, so it's becoming much less common already.

That may or may not also be the case for the grouping concept that lies behind EntitiesDescriptor/@Name.  It's not a very useful grouping concept at large scale, and in the long run it's probably going to be replaced by a combination of entity categories and registrationAuthority.

As I say, you have more flexible ways of passing information round if you're building an API where the SAML metadata element tree isn't the only channel of communication (because you have object metadata too).  You can afford to take @Name and EntitiesDescriptor extensions and turn them into representations of the concepts behind them.  These don't have to behave like their current SAML representations, and there's no real benefit to finding new SAML representations for them for internal use.  For example, rather than turning something like @Name into faked-up SAML metadata entity attributes, I'd favour essentially the opposite: have an *object* metadata representation of the grouping concept, prime it with the @Name hierarchy and provide a filter that extracts *that* from user-specified *SAML* metadata entity attributes.

In passing, I'd note that this kind of approach allows you to have match functors for grouping which are independent of the kind of metadata you're processing.  I realise that's not totally on point in this discussion, but it was an important part of the way we were thinking about how the MDA framework operated.  In the current MDA codebase, for example, entityID tends to be extracted into item metadata early in a pipeline so that entity name matching later in the pipeline isn't SAML-dependent at all.

	-- 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/1fcd934f/attachment.bin