[mdx] MDX & expressing communites-of-interest

Josh Howlett Josh.Howlett at ja.net
Tue May 19 06:23:13 PDT 2009


Responding to my own post, because I thought of another angle...

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

I think any of these approaches are broadly acceptable for
registrar-to-aggregator and aggregator-to-aggregator flows, because
these are elements that we can reasonably expect to modify.

However, for aggregator-to-end-entity flows I think it will be necessary
to adopt whatever approach will work best (or, at least, require the
least modifications to) existing end entity implementations.

I am therefore inclined to think that an aggregator should publish
communities to end-entities at URIs that are either Well Known Locations
(for RESTian methods) or service endpoints (for SOAP methods).

I'll try to summarise the options again:

--> For registrar-to-aggregator or aggregator-to-aggregator flows:

 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.

I'm inclined to think that (1) will be Good Enough for an initial MDX
deployment. 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?

--> For the aggregator-to-end-entity flow:

 3) community membership implied by the Well Known Location (or service
endpoint) that the metadata was consumed from.

 4) community membership asserted by 'reputation service' directly to
end entity.

As concerns (3): it doesn't matter whether the aggregation system is
using (1) or (2) (or both?)

As concerns (4): it is my opinion this is likely to be too ambitious for
an initial MDX deployment.

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




More information about the mdx mailing list