This is a list of requirements that we have developed for the initiative to bring Wave to the US Federal Government (Federal Wave- FedWave). If they could be incorporated into the Wave In A Box software, that would be great. They address underlying technology items, not the user functionality per se. This is a fairly basic non-detailed low-tech list, hopefully enough to at least start a discussion.
1. CAC enabled (Government Smart Card w/ Certificates): This is where the certificates on the card are read and used to authenticate users. It is related to the next requirement in that it uses a physical medium instead of username and password. 2. Army Knowledge Online (AKO) and Active Directory authentication: AKO is an Open LDAP directory that has a specific API that can be used by third party applications (especially websites) on Government networks. Microsoft Active Directory is used extensively across the Federal Government and would be another existing authentication system that could be leveraged. 3. Usable with mobile clients (iPad, iPhone, Android) This would allow for mobile users to access WIAB in a reduced functionality client or web browser interface. This functionality is not currently available in any form for the FedOne system. 4. Automated installation/ Operation on Windows and Linux Servers: A "hands-free" installation experience is important, and having all the required software and systems (XMPP server, etc.) in one package would be optimal. However, some configuration would be required once the basic software in installed- authentication source, certificate installation, URL/ IP Address/ Network information, etc. 5. Security/ Standards: a. Encryption: Client-Server (SSL) and Server-Server (PKI): The ability to protect data in transit is important. b. Authorization: once authenticated, users should only be able to access authorized waves/wavelets/blips. This would probably be done using the authentication system in some manner. c. No use of Google Web Tools (GWT)or other unapproved code: Don't take this the wrong way, but many of the Government security types are totally set against anything that uses GWT. They contend it obfuscates the underlying code and could be an attack vector into the system. d. Servers with full STIG (Security Technical Implementation Guides): STIGs are just settings on the server that lock down specific ports, protocols, and portions of the system in question for maximum security. They can cause things to not work, but have to be followed as much as possible or exceptions must be sought. e. Use approved Federal Government XMPP: One of the advantages of Wave is that it is built on top of the US Federal Government standard for Chat/ Presence/ Awareness. This needs to be continued if at all possible. 6. Full code review/ test throughout development: This is more of a going-forward concept, but it is important from a security standpoint to make sure no "sleeper" code gets onto Government networks. 7. Full Presence/ Awareness (XMPP): This is just the ability of users to see the status of other users, and to publish their status as well. The XMPP model for this would work well. 8. Email integration (in and out): The ability to be notified by email of changes in a wave is important, and the ability to send things to a Wave server and have them post to a wave would be useful. 9. Embed waves in portal pages: This is an existing extension in wave.google.com, and it would be great to have this as part of WIAB. 10. Robust Search: The ability to search through waves and across federated servers for keywords and tags is important. 11. Archive/ persistence of waves: Having persistence is important to Government users, as much of what they do is a matter of public record, and thus must be preserved. Being able to search and retrieve the waves is part of this requirement. I understand some of these might not be exactly clear to non-Government types, and I would be happy to elaborate as necessary. I totally understand many of these are way past what the existing team is geared up to accomplish. Perhaps the community could take some of this on, and if we can get support and funding, the FedWave team would be on point to get much of this work done. Please contact me with specific questions or for more information. Thanks, Mark -- Mark R. Kovacevich Email: [email protected] Wave: [email protected] -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
