Hi, Rhys Thanks for your comments. Clarifications are inline.
Hopefully, we can reach consensus on this use case. Rhys Smith <[email protected]> 发件人: [email protected] 2011/10/23 03:51 收件人 [email protected] 抄送 [email protected], [email protected], [email protected], [email protected] 主题 Re: Please review the use case "4.x Federated Cross-Layer Access" Hi Yinxing, (cc:ed to abfab list for discussion). I'm just looking at making the next version of the use case document for ABFAB, and so I've been looking at the use case you suggested (below, if you don't have a copy of the original message sent to the abfab list). Basically, I've reviewed the suggestion and I'm not quite sure what the use case actually is? First, it seems as though most all of the content in the text you've submitted simply describes why federated authentication in general is a good thing - user registration at the user's "home" identity provider, better user experience, etc. In your case, the mobile network operator is the IdP, but they would be a home organisation to some users and consequently an IdP, just like any other organisation performing the same task. I'm not arguing that you're not right about federated authentication being a good thing - but that's not the purpose of this document. Yinxing#1> For the text "but they would be a home organisation to some users and consequently an IdP, just like any other organisation performing the same task.". I could not understand it well. How does it relate to the use case? For the text "but that's not the purpose of this document", the clarification is as follows: (1), Federated identity is in the scope of abfab wg,and the case also supports non-web application. (2), in the section 3. Context of Use Cases in this document (draft-ietf-usecases-01), it says: In the interest of promoting the development of technology of broad applicability, the present authors welcome use cases and requirements from other sectors and communities. This is my consideration for the use case of "Federated Cross-Layer Access". Second, the one thing that seems like it could be different at first glance in your use case is that you have a layered architecture where users are using mobile devices, attaching to the network using standard means, and then performing federated authentication from their devices. However, I don't see how this is different at all - applications that users on their mobile devices are using contact the home IdP (in this case it so happens their home IdP is run by the network provider) and authenticate the user based upon that. That's standard federated authentication, just from a mobile device instead of, say, a desktop or laptop. Yinxing#2>The point is that the mobile network infrastructure has already had security capabilities (e.g. authentication, integrity and confidentiality ) which is mandatory for user equipment attacked to network. Application can make use of this capability without duplicating the similar task done in network layer. As to desktop or laptop, when they connect to the network, the authentication is performed in other way provided by network operators. I think there's a good argument in there that mobile telecoms providers might make a good class of IdP, but unfortunately that's not applicable to this document, I don't think. Yinxing#3>refer to the reply in Yinxing#1> The key thing is that I don't see any new particular applications or use cases for federated authentication in your text, just a so I'm struggling to see how, or if, it fits into the use case document. Yinxing - If you think I'm misunderstanding your use case, please do get back in touch and we can try to figure out what it is and how it fits into the document. Everyone else - If anyone disagrees with this (if I'm missing something obvious here), then please let me know where I'm going wrong... R. -- Dr Rhys Smith: Identity, Access, and Middleware Specialist Cardiff University & JANET(UK) email: [email protected] / [email protected] GPG: 0xDE2F024C On 2 Aug 2011, at 20:53, [email protected] wrote: Dear Rhys Smith, According to the action in IETF#81, I summarized the use case in draft-wei-abfab-fcla-00 as an input to draft-ietf-abfab-usecases-01. Please review it. Thanks! 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. The brief steps are as follows: 1. When UE attaches the Network, mutual authentication is performed master session key is created between them. 2. UE visits non-Web Application, e.g Messaging service, VoIP service, or Email service. 3. Application has no information about the UE. The Application contacts Network to validate the authentication result in the network stratum. Application can find Network according to the configuration or dynamical discovery protocol. 4. Network responds to Application with authentication result. 5. UE is authorized to access the 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------------------------------------------------- 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. -------------------------------------------------------- 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
