Metadata Distribution Subcommittee of TAC

[Ian Young <>]

On 16 Aug 2013, at 13:56, Tom Scavo 
<>
 wrote:

> (Related to this, I suspect eduGAIN is a disaster waiting to happen.)

I think that's probably a bit harsh.  The original eduGAIN implementation was 
a bit naive (they were computing and signing the aggregate on every request) 
but my understanding is that they haven't done that for a while now.  They 
also have some pretty simple ways to control the obvious kinds of DDoS 
scenario going forward because there are so few intended consumers (just 
throttle everyone who's not on an IP whitelist, for example).

So I don't think eduGAIN is necessarily in a worse position than any other 
public-facing service.

> The MDX syntax
> is easily extended to entity attributes, so it shouldn't be too hard
> to let users create entity attributes and thereby pre-register their
> queries (so that the target aggregate can be pre-computed).

We could probably have a discussion about whether that first statement (that 
such an extension is "easy") is really true.  There have been a couple of 
proposals for this, but I've pushed back on them for a couple of reasons.  
One of those is that entity attributes are only a SAML metadata concept right 
now, and the intention is not to tie the metadata query protocol to SAML.

The more important reason to push back, though, is that turning everything 
into entity attribute algebra is probably not what you want to do anyway.  If 
what you want to do is offer your users the ability to determine a collection 
of entities specific to them, I believe you're much better off in most cases 
abstracting all the details of the selection criteria out of the interface by 
which that collection is requested.  This also means that your selection 
mechanism doesn't have to be limited to something that can be expressed in 
terms of entity attributes.

Maybe the spec doesn't make this clear enough: the identifier you are 
querying for is not necessarily an entityID, but can be anything at all.  
That's the only reason it makes sense to combine them.  So if one of your 
customers (say, Carol) designates some arbitrary collection of things in your 
management interface there's nothing to stop you delivering that as  
.../entities/Carol

Obviously in the back end, that's really easy to implement.  You just make 
sure that Carol's entities are put in a file named after the hash of "Carol". 
 This is a whole lot simpler than trying to express the attribute algebra 
underlying the "Carol" set in some (probably rather verbose) language and 
then making sure both your management interface and the client system use 
exactly the same complicated thing.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature