[mdx] MDX & expressing communites-of-interest

[Josh Howlett]

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

Yup.

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

Agreed.

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

I would prefer to avoid modifications to end entities.

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

I guess you could use the AffiliationDescriptor, as suggested by Scott,
to enumerate the list of entityIDs.

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

Again, I would prefer to avoid modifications to end entities for MDX
v1.0.

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

Agreed.

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

Yes, we need a seperation of concerns between expression of
'registration' and 'community'.

I would be content for the aggregator to mung these together for the
benefit of 'dumb' entities, either on the basis of information provided
by the community at a Well-Known Location or using an AttributeQuery.

To summarise, I think we have three different approaches on the tables:

 1) community membership asserted by original registrar, expressed using
an inline metadata element of some type.
 2) community membership asserted by aggregator, on the basis of
information provided by the community (derived either from a document at
a WKL or a 'reputation service'), expressed using an inline metadata
element of some type.
 3) community membership asserted by 'reputation service' directly to
end entity.

The inline metadata elements mentioned in (1) and (2) could be
represented as either:

 - Entity labels (similar to UK federation's labels) given as elements
in a namespace managed by the community in question.
 - Inline attribute assertions.

The 'information provided by the community' mentioned in (2) could be
represented as

 - AffiliationDescriptor
 - some other structured document?

I don't consider approach (3) to be a feasible short-term approach,
although I think it's a reasonable long-term goal.

Is this summary complete?

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG