>>>>> "Gabriel" == Gabriel López <[log in to unmask]> writes:
Gabriel> Hi Sam,
Gabriel> El 06/07/11 22:21, Sam Hartman escribió:
>>
>> It plays the role of SAML metadata in our system.
Gabriel> ok, although it runs federation routing and topology information, and
Gabriel> forwards eap authentications. It plays a lot of roles :)
The trust router does *not* forward eap authentications to the end
service or user's IDP, no. A trust router will act as a service and in
that role may handle authentications the same as any other service.
>> However it is not required that every institution needs to deploy a trust router.
>>
Gabriel> ok
Gabriel> - Does the term Trust Path refer to the AAA path/TRs path/mixed?
>>
>> Your AAA message goes from something near the RP to the radsec server
>> near or at the IDP assuming you're actually using RADSEC.
>> However other realms help set up the technical and policy trust required
>> to send that message.
Gabriel> I can understand the AAA path in this case, but l think this mixed path
Gabriel> is very complicated. If every realm implements this functionality like a
Gabriel> AAA server it would be more interesting.
It would have significantly worse privacy and performance characteristics.
Gabriel> Have you analysed how this process (I count 18 messages for 4 realms
Gabriel> without routing and attribute request exchanges) could affect specific
Gabriel> services like SIP?
So, currently ABFAB does not target SIP.
In general I'd expect you to use the same SIP registration server
regardless of your current location.
However if we did target SIP and you did happen to use a registration
server far away from your IDP, it would mean that you'd need 18 messages
and introduce some delay for your first registration. In most sip
deployments beyond that, the number of messages would be the same as it
is with some central authentication server after that because the
registration would be cached.
so, it might take a couple of seconds longer the first time your phone
boots in the morning.
