[mdx] [gn3-jra3-t2] Querying a list of Identity Providers from the Metadata Aggregator

Chad La Joie lajoie at itumi.biz
Mon Jul 26 08:25:03 PDT 2010



On 7/26/10 10:46 AM, Andreas Åkre Solberg wrote:
> 1) Scalability in the sense of the large bulk signed XML message sent
> back and forth.

Yes, that's what MDX is meant to address.

> 2) The fact that the whole architecture depends on a "central"
> point.

That isn't a topic for this list.  If you don't want to deploy your
system in that way then don't.

> [1] All entities share metadata through a central aggregator.

Only if you choose to deploy that way.

> This lead me to think about alternatives to how the DS can get the
> information it needs from the aggregator.
>
> I also think the saml metadata document, in the currently used form,
> is not suited for transporting the information that the DS typically
> need. Basically the info that the DS need is to a large degree what
> is defined in [2].
>
> And if we are looking for ways to minimize the bulk sent from
> aggregator to DS, then I am thinking it would be reasonable to look
> at a more compact representation of [2], avoiding to use the metadata
> format (at least removing out all the keydescriptor and endpoint
> information). If the DS implementations are going to use JSON anyway,
> it is reasonable to try to standardize a JSON mapping of [2]. Then I
> would say this JSON is a good candidate for transport between the
> aggregator and the DS as well, in order to save some bandwith. One
> argument against, might be the integrity protection provided by DSIG,
> but that might have been given up already if I understand correctly
> that DS deployers already have accepted to use an embedded<Script>
> element.

You're making a number of assumptions that aren't, or don't need to be, 
true.  First, as has been said in numerous other forums, the best spot 
for the discovery process (assuming the browser/OS can't do it) is the 
service.  In almost all cases today it already knows which IdPs it will 
allow in and could ask for metadata only for those.  Second, the query 
responder has no way of knowing what metadata is, or is not, important 
to a discovery service, that's why the transformation from a standard 
format to an internal one has to happen there.  Lastly, in terms of 
bandwidth, if you're worried about it, use gzip compression.

-- 
Chad La Joie
http://itumi.biz
trusted identities, delivered



More information about the mdx mailing list