[mdx] MDX & expressing communites-of-interest

[Ian Young]

On 15 May 2009, at 15:05, Josh Howlett wrote:

> (Another policy-related post, that attempts to adhere to Chad's T&Cs  
> by
> addressing a technical requirement)

I think it's OK to explore this kind of thing a little as long as we  
don't obsess about them, particularly if it is even loosely connected  
with the technical requirements.  The meeting Ts&Cs were brutal  
because we wanted to get useful work done in a limited time.  If  
people aren't interested in this discussion, they can just hit delete.

> There is a view (and I hope I am summarising it accurately) that since
> these promises are only made to federation operators, member
> organisations should take their own steps to protect themselves if
> entering into any significant relationship (because an aggrieved party
> can't enforce a contract between two other counterparties).

That's certainly the position we've taken in the UK federation since  
the very earliest discussions, and I think that's the way most current  
"infrastructure" federations frame their agreements.  I believe that's  
the right position for an infrastructure federation, but I'd expect  
"leveraged" federations (per Ken's terminology) to take a different  
view.  In my view, they are more *about* behavioural agreements, so  
I'd expect their agreements to be more multi-party and potentially  
more enforceable as a result.  I don't know whether federations like  
UCTrust actually do have such mutually binding agreements today.  I  
guess I could look.

I don't think this is primarily about legal enforceability, though, as  
such a concept only makes sense when you're talking about parties  
which have standing in the legal system.  Many of the parties who will  
want to get together and make behavioural guarantees to each other  
won't have legal capacity; it will be "that bunch of researchers over  
there and their friends in Ohio and the people in Hawaii with the  
telescope".  These people might all be employed by Universities, but  
forcing them to get some high-end University signatory to put pen to  
paper every time they want to collaborate is just too much friction to  
be workable.

Contrariwise, if I'm an astrophysicist I'm actually more likely to  
implicitly trust an entity I know is associated with some people in my  
little informal community than I am to trust one just because it is  
owned by a University but actually run by some student project group  
who hand the root password ("password1") out to all their buddies to  
run Counter-Strike servers.

> Therefore,
> federation metadata (and by extension, MDX) should be considered a
> promise-free zone; the only property of interest is the 'LoA'  
> associated
> with the metadata registration, as this allows you to establish the
> counterparty-to-entity binding.

I'd probably just say that there should be no automatic assumption of  
behavioural promises (or anything else, including "registration LoA")  
from the mere presence of metadata.  You might or might not get some  
evidence about either of these things from knowing the practise  
statement of either the original registrar or your friendly  
neighbourhood aggregator.  Or, you might get it from something  
explicit within the metadata itself *in combination with* said  
practise statements.  It never comes out of thin air, though.

> Nonetheless, situations do exist where people do behave in ways that
> strongly indicate that these types of agreements do instil a level of
> trust between actors in communities, even if they don't formally have
> any legal recourse. A good case of this is eduroam, but there are
> others.

I agree, to an extent.  Although I think people currently (want to)  
read way too much into the power of federation agreements to free them  
from the unfortunate messiness of the real world, I also happen to  
think a lot of people are just happy to know that an entity passes  
some threshold of sanity checking.  It may not solve all of their  
trust problems, but (at present) it filters out the random noise.

> Consequently, I feel that it might be useful for MDX to be able to
> express an association or membership within a particular community(s),
> irrespective of its legal enforcability. It can be treated as evidence
> that a metadata consumer can take or leave.

I agree with this wholeheartedly, although as you can see not for the  
reasons you've stated.

> It is not clear to me how this association/membership of a
> community-of-interest should be expressed; I see the following  
> options:
>
> - tag the EntityDescriptor

Yup.

> - publish the EntitiesDescriptor for a community-of-interest at a Well
> Known Location, that members of that community can fetch it from.

Isn't this just the standard aggregation case, with an aggregation  
practise statement saying that only verified members of that community  
will be included?

I think one problem with this kind of solution is that it doesn't work  
very well if there is more than one community you're interested in.   
Explicit markers do scale in this direction, though.


There are a couple of other variations that could perhaps be added to  
that list.

You could publish a list of entityIDs at a well known location, and  
have end entities consume it, check it when establishing a session and  
signal membership to the application.

You could publish a list of entityIDs at a well known location, and  
have your local aggregator consume it and convert it into a metadata  
representation of some kind on metadata that is flowing past on its  
way somewhere. (after which it behaves like your first option)

As either of the above, but as a "is this entityID a member of that  
group" web service.

As any of the above, but done as a SAML AttributeQuery to an  
authoritative entity.  I think this last is the one we've previously  
called a reputation server, but maybe not.


I think we do need to come up with some kind of approach to this.  I'm  
probably personally most inclined to define an explicit representation  
of community membership in metadata (whether as a SAML entity  
attribute or otherwise) and also augment that by defining some kind of  
reputation service (whether SAML-based or otherwise) so that the  
original registrar isn't always responsible for acquiring the  
membership list in cases where self-assertion isn't going to cut the  
mustard.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20090518/443e2909/attachment-0002.bin>