[mdx] MDX & expressing communites-of-interest

Scott Cantor cantor.2 at osu.edu
Tue May 19 09:05:20 PDT 2009


Josh Howlett wrote on 2009-05-19:
> 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'm not sure how that coincides. Without knowing the specific use cases you
have in mind for identifying membership in a community, I can't say what
particular implementations would or wouldn't support, but it's definitely
not the case that either of those methods is supported today by Shibboleth
at least.

In fact, one of the key tenets of the metadata API we use is that the data
is self-contained such that only the metadata itself communicates anything
to the system, not the implementation details involved with acquiring it.

Or perhaps you meant that applications would be writing code to make these
checks, but in my experience most applications don't "get" these concepts or
want to write code to deal with them. When you have concepts that are unique
to federated identity, you rarely see applications building them in, and I'm
not sure we'd want them to.

-- Scott





More information about the mdx mailing list