Talk:Smart Wireless Authentication

1.	What it is What is your tool/technology about? What does your tool/technology and/or its parts bring to the DeveloperSpace?
Providing seamless wireless network service is not only about network quality but also about user experience and ease of access has become an important factor for quality of life. Adding an extra burden on users – particularly technically non-literate users or ones with special needs – actually excludes many people from access, especially when using complicated username:password schemes with media breaks. As a step towards the proliferation of accessible networks, this work the usability of ways for associating handheld and personal devices to Wi-Fi networks or other infrastructures using out of band methods (such as barcodes, RF beacons, RF surfaces, gestures/movements, audio fingerprint). The system does that do not identify the user but proves his presence in an authorized area and reduces the problem from access to another better understood area of accessibility.
2.	Its value as a whole (to developers) Who are the target users of your tool/technology? What value would these developers see in using this tool/these components? (e.g. how is it better than what they might have currently – or could develop.) You can illustrate the specific value by describing a target use case.
The system is intergrated with a captive portal running on a standard OpenWRT based router and can be used as an appliance for any entity that wants to offer internet access but also access to any type of smart or e-inclusive environment via WiFi. A typical use case can be e.g. a shop/restaurant  that wants to offer accessible search of their catalogue/menu via a personalized device, however wants to restrict internet access to the shop area. By offering alternative methods of access in parallel, the customer can choose which mode works best for him. The system requires no further integration. We are currently evaluating the use of a system eg. with a vendor for tablet PC based menus for cafes and bars. One new application we are considering is the kiosk use case in combination with a mobile personalized device. In many setting the user will already carry a device equipped with a lot of AT with him, a wearable or smartphone. If he wants to take control over a kiosk or any other kind of public interface with his personalized interface, we do not need to identify the user or load settings. The only protection in terms of personalization or manipulation of the interface is typically the queue in front of the device that ensures that only people in the correct spatial context will be able to take over control. Instead of having to search for a USB slot or a NFC reader, the offered component can actually mirror the problem towards the already personalized device (the smart phone). This also removes the need from the vendor to offer any physically accessible interfaces (like slots or readers).
3.	'Value of parts 'of it In addition to using it as a whole, what parts might also be of use to a developer?
The modules are all developed in pure HTML (with server components in some cases), they can be used as web components for any application that requires authentication of the location context of the user. This includes applications beyond WiFi access. Using e.g. temporary identifiers such as session cookies the system can be also used in the context of room based access control within the same network or within cellular networks.
4.	Support after P4A How would this tool / these components (and those who use them) be supported after the end of this grant?
The system build upon standard technology and will require few maintenance steps, however, it would be essential to include the components for out of band authentication in other component collections to ensure the updating regarding browser technology (the scope is probably to small for a vibrant standalone open source community). KIT will continue development for its own purposes but cannot provide professional support.
5.	Technologies used What technologies are used or will be used in the P4A implementation of your tool/components? (a) On what platforms does it run?  (b) In what programming language is it implemented?  (c) What dependencies does it have on third-party libraries, frameworks, or development tools?  (d) Does it have a user interface?  (e) What other technologies, tools, libraries, or applications is it designed to integrate with, and how?  (f) Are there licenses, duties, or other limitations to use of this?
The code is optimized to run on embedded routers and captive portals. It is written in HTML5 with php server components. See https://github.com/teco-kit/UsableWi-FiAccess/blob/master/legal.txt Only minimalistic components. Theming is necessary. Also basic accessibility improvements/auto-personalization should be considered. It is designed to integrate with PHP-based captive portals (chillispot atm)  but most of the logic is HTML/JS based and can be adapted to other web-based authentication solutions, where user identity is not important. See https://github.com/teco-kit/UsableWi-FiAccess/blob/master/legal.txt
6.	Problems/challenges/risks you anticipate with your project goals What is the current status of your tool/components? What problems do you see taking the tools/components you had and changing them into the best form for developers and the DeveloperSpace? Do you see any problems/challenges/risks in getting broad adoption/use of your work? Please mark any parts of your answers that you don’t want to have on the WIKI or other public sources and deliverables.
Particular in countries like Germany, the law makers have strict requirements on free wifis. The biggest risk for using the components for WiFi access is that they do not fulfil the requirements of liability transfer completely or on the other hand the need for access control on network/infrastructure level is not required at all. In both cases this system makes no sense. One problem in terms of adoption of the components as parts is that a potential implementer needs to become aware of the problem. This is still improbable. Another route would be the inclusion within a captive portal site: however accessibility/usability does not seem a selling point in this area.