Hi, Sam
Thanks for your comments! I agree with your points that use case
document
should avoid introducing solution details.
The reason to provide a few details in the previous use case document is
just to make it clear and understandable. According to your suggestion, I
revised
the text shown as below in order to make it suitable in the current use
case document.
I hope it is acceptable now.
Any comments are welcome!
Yinxing Wei!
------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4.x. Federated Cross-Layer Access
Telecom operators have a communication network infrastructures to
provider users with a wealthy of access methods. Telecom operators
have a huge number of registered users, and they can provide trusted
identity and higher security. Therefore they have a natural advantage
to act as an Identity Provider (IdP) to serve for service providers.
On the contrary most service providers on the Internet have limited
amount of users and can not assure the security of user identity, but
they can provide abundant kinds of service. Furthermore, user is
reluctant to register too many accounts because it is inconvenient to
remember dozens of passwords.
Telecom network supports Web or non-Web application. In some cases
user prefers to choose non-Web application, e.g. Messaging service,
VoIP, EMail service, etc. Based on the result of network stratum
authentication and authorization, User equipment (UE) can access
applications without doing another authentication and authorization
procedure. In this way, the system can implement federated cross-layer
access. Firstly mutual authentication is performed between UE and
Network, secondly UE accesses Application based on the result of
network stratum's authentication. In this case, a federation is formed
between Network and Application.
For federated cross-layer access, Network can assure the Application
of the authenticity of user's identity, share some of use profile
with Application. These can bring some benefits to stakeholders:
o For telecom operators, they can provide identity service, trusted
security service, mobile payment service and sharing some user
profiles according user's preferences. Telecom operators is not
just providing pipeline for communication, but also become a part of
service value chain as an Identity Provider.
o For service providers, they can focus on core business and reuse
capabilities provided by telecom operators without worrying about
sources of users.
o For end users, they can enjoy seamless service experiences and
improve security and privacy.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Hartman <[email protected]>
2011-08-03 21:34
收件人
[email protected]
抄送
[email protected]
主题
Re: Please review the use case "4.x Federated Cross-Layer Access"
I think this text goes way too much into solution territory rather than
just focusing on the use case.
for example, the following all seem to be solution details:
1) There is an initial authentication with the network provider
2) An MSK is established with the network provider
3) The service provider finds the network provider based on
configuration or discovery protocol.
These details also go against the current ABFAB architecture.
As best I can tell, the current abfab architecture does support the
network provider leveraging their identities and the service provider
using their identities. However under that architecture it would look
more like:
1) user goes to service and begins abfab authentication
2) User provides network provider's realm to service
3) User engages in an EAP exchange with the network provider tunneled
through the service and AAA infrastructure
4) If authentication succeeds, a MSK is generated and given to the
service and user.
These details would also be inappropriate to include in the use case
document; I include them in this message only to illustrate how things
differ and why we want to avoid solution focus in use-case text.
If you believe that my proposed flow would not work for your use case,
then let's focus on what the aspects of the use case are that would make
these details inappropriate.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and are
not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
