Re: [Secauth] secauth use case - What is next?

["Hosnieh Rafiee" <[e-mail]>]

Hi Rafa,

Thanks  a lot for sharing your comments.

> I agree with Alan's points here. The usage of EAP/AAA is important because
> typical access points already provide that feature. Also AAA is used for
cross-
> domain authentication. As University we are used to the case where
students
> coming from other Universities can access our APs with his credentials in
their
> home institution. Eduroam and AAA-based federation make this possible.

I do not ignore the usefulness of such approaches, but the problem is that I
am not quite sure about this communication between controller and then
resources. In other words, it is no longer direct access to some
authentication server since hotspot is no longer the decision maker  but
there are some other components that might break this communication and
therefore, the current standards might need some changes to fit to such
scenario.

> Having said that, regarding the problem statement, if we want the user to
> access ISP1 and ISP2 , then there must be at some point some source of
> common trust (e.g. some IdP or entity that ISP1 and ISP2 both trust). For
> example, ISP1 and ISP2 may belong to a federation though they do not have
> direct SLAs.

Yes true. This is done via either using a shared apps provided by SDN
provider or the third party apps provided by third party company that
followed the standards and can run on different controllers from different
industries. In former case, there needs to be a SLA among SDN providers. In
latter case, SDN providers only need so follow the same common standards so
that the apps can use a common standard plugin to access and run on them.
This app can by default use a resource server. So there might be a third
party companies who provide this trust by producing apps and follow some
standards. 
Secuath role in former case might be exchanging this SLAs 
Secauth role in latter case might be a standard for the communication of
this special app to controller including authentication and authorization of
this app and all the communication of this app to controller. In this case,
the communication can be based on one of common approaches like Openstack
and secauth can provide plugin for openstak and controller to support this
shared resources.

> In fact, what I understand from slide 5 is that, somehow, that trust is
defined
> above southbound API with relationships that allow a user moving from
Hotel
> A to Hotel B.
> 
True.

Thanks,
Best,
Hosnieh