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

Andreas Åkre Solberg andreas.solberg at uninett.no
Mon Jul 26 07:46:59 PDT 2010


OK; I see my proposal was moved to this list, so I'll follow up with an introduction.

I see at least two issues with the current inter-federation model [1], that I'd like to see fixed:

1) Scalability in the sense of the large bulk signed XML message sent back and forth.
2) The fact that the whole architecture depends on a "central" point. 

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

I think that MDX is a welcome solution, that partly solves 1). By partly I mean that the SP and the IdP may now only grab one-by-one enitydescriptors; but the DS will still need to bulk download the whole federation. 

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.

[2]: IdP Discovery and Login UI Metadata Extension Profile, https://spaces.internet2.edu/download/attachments/9731/saml_ds_login_ui_02.odt

BTW: I removed the query string parameters at [3]; because I agree with you and it moves the discussion away from the essencial :)

[3]: http://rnd.feide.no/content/querying-list-identity-providers-metadata-aggregator 

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4387 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20100726/77e5c947/attachment-0002.bin>


More information about the mdx mailing list