Dear Sam, Josh and Scott,

thank you very much for sharing this interesting discussion. As you know 
(I'm not sure if Scott too) we (in UMU) are working on the design of a 
Moonshot-like scenario based on Kerberos (we sent the slides some days 
ago).

Although it is a bit difficult to extract your off-line conversations 
from the emails ( :) ), I think I have get some interesting points I 
would like to discuss. I will try to summarize some of the ideas I have 
understood from your messages. Please, correct me if I'm wrong :)

Sam: "

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."


So I understand that your idea is to sent back from the idP to the SP 
the AuthSt through the AAA infrastructure.
Do you think it is feasible to encapsulate a compressed SAML assertion 
in a new RADIUS (TLV-like) attribute? by size I meant
I know people from SAML team are not very comfortable with the use of 
"artifact" but other solution could be to send some kind of 
artifact/handle in the RADIUS response and then the SP can make use of 
this to request the SAML assertion to the home idP (SOAP binding). I 
think this solution was proposed by Josh in the TNC working group, or 
maybe i'm wrong?

The drawback is that you have to add a new inter-domain exchange, but if 
the SP wants to make an end user attribute query, we can take advantage 
of this query to send the "artifact" in the request and to make use of 
it like an authentication evidence

Sam:
"

  The authentication assertion would
effectively serve as a token for the SP to prove it was entitled to
attributes surrounding the subject."

I also understand that the main discussion is how to authenticate the SP 
in order to be able to request end user attributes from her home domain. 
I assume that if both SP and idP belongs to the same "federation" there 
should not be any problem, because they can make use of the trust 
mechanism established by the federation, usually a PKI-based hierarchy 
or trust-anchor infrastructure. So, do you have in mind to describe a 
solution outside the "federation" scenario?


Scott:

"

That's a bit of a complex approach and requires implementing
WS-Security-based SOAP queries, which is not something I'd take on without a
really good reason."


Dear Scott, like one of the main experts in SAML you are, I would 
appreciate to know a bit more about the reasons about this reticence to 
allow SPs to make use of WS-security soap queries to idPs. We (here in 
UMU) are working on other scenarios with SAML and we make use of this 
approach.

Scott:

"

My suggestion is to avoid bringing the end to end vs. gateway discussion
into the architecture. If people want gateways, they can proxy the
interactions as they choose."

I totally agree.

Thanks and best regards, Gabi.

-- 
----------------------------------------------------------------
Gabriel López Millán
Departamento de IngenierÌa de la InformaciÛn y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [log in to unmask]