[mdx] MDX & expressing communites-of-interest

[Ian Young]

On 18 May 2009, at 18:14, Scott Cantor wrote:

> Ian Young wrote on 2009-05-18:
>> There are a couple of other variations that could perhaps be added to
>> that list.
>
> There's still another one, which is a SAML "affiliation", which has  
> metadata
> support already (though not in the sense that we've implemented  
> anything
> based on it).

I had for some reason completely forgotten about this.  I should have  
a repeating to-do list entry to re-read all of the SAML specs every  
six months, or something.

This does seem to me like the best way of expressing the community  
membership issue; no need to invent new formats plus the potential of  
doing metadata exchange of this kind of entity descriptor using the  
same rules we use for IdP and SP entities.  This is a huge plus, I  
think, as it means that community membership is in no way tied to the  
same registrar or registrars as are used to register the community  
members.

This means that we can almost immediately move away from the idea that  
community membership is self-asserted by the member to one in which  
community membership is defined by the person who registers the entity  
representing the community.  In other words, we get many of our third- 
party reputation effects for free with this.

As an example of somewhere we crashed into a brick wall in the UK, we  
have had multiple requests from people wanting there to be a label on  
entities that classified entities by educational sector.  The  
definition of such things is quite tricky, but in the end people here  
balked because we'd be responsible for errors and omissions if we as  
the federation just labelled things like this.  If on the other hand  
someone like Becta were to register an entity which was a list of  
"schools IdPs" defined however *they* defined it, the responsible  
party would be pretty clearly identified as not-us, and I suspect  
objections would largely subside.

Of course, until end entities can understand this, a metadata  
publisher might need to transform such things into something that  
would work for their subscribers by, for example, turning them into  
some kind of tag on the individual entities.  We could probably get  
away without that in a fair number of cases, though, as quite often  
what people do with those tags today is just use them to make up a  
Set<entityID> anyway.

> I was considering that, though, and then extending the group-based  
> policy
> stuff in the SP to allow for Affiliation membership in addition to  
> just the
> containment model.

Yes.  I don't know that you'd even need any additional configuration;  
just treating an entity's mention in such an affiliation entity as  
equivalent to its definition in a same-named EntitiesDescriptor would  
seem to pretty much cover what we want.

> I started to think that affiliations might be a way to get the  
> notion of a
> "self-defined" group into the metadata layer. Today you can't easily  
> create
> RelyingParty settings based on groups that you manage yourself.

It's very attractive to me that these affiliations would be able to  
move around the metadata layer independently of the entities which  
they describe.  The same trust models would apply, I think.

They might also be useful in other scenarios, too.  One thing that  
occurred to me during a conversation with Rod today was that you might  
use something like this if you wanted to do centralised but  
constrained cross-federation discovery.

SP says:  I am entityA.  Please perform discovery within the community  
described by entityB.

DS looks up entityB to get list of entities, then dereferences each of  
those to build the UI for discovery within the appropriate community  
*without needing to know anything about the "federations" involved*.

All seems like win/win/win to me.  Except maybe that last part, which  
I just made up.

	-- 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/20090520/e5605a8a/attachment-0002.bin>