Scott, Josh and I have been discussing the SAML interactions between the
RADIUS server and IDP.

Josh's idea to get around the RADIUSS MTU issue is to include a
compressed authentication assertion in the RADIUS response and for the
SP to make a SAML attribute query.  The authentication assertion would
effectively serve as a token for the SP to prove it was entitled to
attributes surrounding the subject.

Josh and Scott have been assuming that we would have the same level of
provisioning today for relying parties.
I'm very uncomfortable with that.

In order to support our use cases I think it is critical that SPs should
only need to be provisioned within their own domain, not globally.  For
example, I think we'd want to say something roughly like "Google is
permitted to run mail servers," globally, "Google's mail servers get the
e-mail address of XYZ's users," in XYZ's attribute release policies, but
only Google needs to know what Google's mail servers actually are.

I also don't think it is desirable to couple the Moonshot trust
management tightly enough to the beyond SSO stuff in order to require
the trust management to make this work.

I wonder whether we could provision a key that is conveyed to the IDP in
the subject with the RADIUS exchange.  That way, if the SP didn't have
other credentials to use, it could authenticate as the holder of that
key.  The key could be transported to the SP in a RADIUS attribute, and
transported to the IDP in the subject.

So, under this model, the subject would be very similar to a Kerberos
ticket; in an encrypted structure it would include:
* identifier for subject known to IDP
* identifier for SP 
* Any group information the RADIUS server needs to community to know
what attribute release policy the subject is in
* Key that has been shared with the SP
* Expiration time


--Sam