Re: [WebCrypto.Next] Any ideas on how to proceed?
On 02/18/2015 08:59 AM, David Leon Gil wrote: W.r.t. WebCrypto-Next: It would be wonderful to see a few useful algorithms added to the spec: - a modern VOF (e.g., SHAKE256) - a fast hash function (e.g., BLAKE2b) - a sequential-hard KDF (e.g., scrypt) - some non-NSA curves New algorithms are definitely within charter for the existing WebCrypto WG. Note that we are aware and have the formal dependencies for the IETF CFRG recommendation in terms of non-NIST curves. For SHAKE256, BLAKE, and scrypt I suggest asking the WebCrypto WG if they have any opinion and if such code can already be accessed via calls to underlying platform (NSS/Windows/etc.) or would new underlying code have to be written and distributed. as well as a slightly higher-level interface that makes it less complicated to do things like (cryptographically sound) ECDH without shooting yourself in the foot repeatedly. (I tried with the current API, and I have fewer toes.) Yes, this is a design goal once we have the supported browser profile properly worked out. I'd love to hear more about your thoughts and experiences on this. There are some other things that would be great to see standardized in this area, but WebCrypto may not be the appropriate WG. I believe there will be a survey shortly - again, this a discussion for general Web Security, so whether or not something goes in WebCrypto or not is not the most important question, the question is whether or not we can get consensus for doing it, and if so, then we can find the most appropriate existing Working Group or create a new one. On Tue, Feb 17, 2015 at 10:30 PM, Anders Rundgren anders.rundgren@gmail.com wrote: As you probably noted, all proposals related to http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/ were shot down. Are we waiting on something, and if so is the case, exactly what? Is the idea of building on an already semi-established solution like Chrome Native Messaging unacceptable? Or should this disparate community rather standardize on U2F? Another solution (IMO workaround) is using local services supplying Security Services through Redirects, XHR or WebSockets. Since the (in)famous plugins were simply removed without any thoughts of the implications, it seems that the browser vendors currently own this question. Anders
Re: Looking for a home for a proposed Credential Management API.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/24/2014 03:57 PM, Mike West wrote: (I'd originally sent this just to the folks on to: and cc:. Art reminded me that public is better, so I'm resending to public-webapps@, and BCCing public-webappsec@ for visibility). Hello, chairs of the WebApps, WebAppSec, and WebCrypto WGs! On Friday, I had an encouraging discussion with Jonas Sicking (CC'd) about the Credential Management API proposed a month or so ago on WebApps ( http://mikewest.github.io/credentialmanagement/spec/). Chrome has started experimenting with an implementation, and though we're nowhere near even considering shipping it, I'd like to make sure that our implementation doesn't get too far out ahead of the spec process. I think it's fair to say that Mozilla is interested in continuing the discussion around the short-term and long-term goals of such an API in an appropriate venue. I'd like your collective opinion about what that venue might be. WebApps seems like the right place just in terms of having the right people involved. It would require a recharter, however, and it's not clear to me that that would be a worthwhile use of folks' time. Both WebCrypto and WebAppSec are in the process of rechartering, which resolves that potential issue, but neither really seems to be appropriate, as they're concerned with aspects other than credentials and authentication. There's a credentials community group that has nothing to do with the proposal, and given the weak IPR protections of a CG, I'd prefer to avoid them in the long run (though they might be the right place for short-term incubation). Brad suggested that an authentication WG might be spun up out of the conversations in the recent WebCrypto workshop. Are there concrete plans for such a group? We've just started those discussions. A high-level authentication API was brought up as a possible deliverable and this looks on the right level. Whether or not it goes in WebAppSec or WebCrypto or a new WG is up in the air - the discussion *just* started. The Google folks there also wanted to make sure this dovetailed with their work on U2F in FIDO and of course later work in UAF, so we were kinda waiting for them to make that public. Thanks! -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJUIs6BAAoJEPgwUoSfMzqcmLsQALcM8k3KX+eB04aHTBH+7+UY jjDYIxs8mVEJIHj3CYRyz+n4s5w9Zck2FaPbrR37Qanb8Cx+rInOqh25U3n7Hnaq cV9h81yJM9W6XG/HpeF7iBpmpIIfvBcmOXFRTklOwgrdQE8Lg5UmdesKJ5fkjZBh LIL6tKM3j5Plze8ThJEO6cisSF1uu+x143Ue8e1SCyeB8PgYnUCrfNZoiHbTkXvN d7s0oAjLqU1kvHXP6u5HNCUkNB9TlbBTXS8+Szswy3pfLf22+YPy6eotODyEqvRn lPbQ4nrr/sYz6k5r9/vGDp3wX3tkPfWLEPFf1o/ljvXASYT0xiy3FVub/9862fT7 Hoff/Kzp8Gq6Urh9rJaJ6azmxwpUcur1LmASxBsJ8It5sBHk5FoxdAbJ8Keic/wt 7QFYnUQlPShyyfSZz43MWuRyl41TBxwZdhlZztGr8QppuaiH+AyWj5RCuwblBvaq rt6sNOpOONKD5z2tWJkFQrKm6FEgob3jCECEulNdVr8smmIEVqJquLOqYayLIqvn Sw2QTkhxEht5gMg+Udgfl+jb+/bSq6YYo13zDNVVVmiD/ldcKMvzxVeaxBXf28rs jy0Yde0PCybMxSZ3RHLs8j8r7zV3PkW0icLHPS4YPt0U+eJ7lNjUzCG9YaItcqtI rcIEnvSLfuMJBaczdJc0 =iM70 -END PGP SIGNATURE-
Re: Social APIs (was: Rechartering WebApp WG)
On Sat, Feb 13, 2010 at 8:52 PM, Doug Schepers schep...@w3.org wrote: Hi, Scott- This is certainly a valid aspect of Widgets... as a platform for a specific kind of Web application: a collaboration/discussion/sharing app. But it seems to me that this is conflating two orthogonal things: an application host environment, and a collaboration platform. Widgets can host the full range of Web apps; and a collaboration platform shouldn't be confined to Widgets. The context for a Widget, in my opinion, shouldn't inherently contain the users of that Widget; that is functionality that should be specific to collaboration apps. As an analogy, think of the Geolocation API. A recipe widget which finds recipes based on a list of available ingredients has no use for that API, but a shopping widget might; traditional web sites built to do those things would have the same needs. So, the Geolocation API is much better off as a standalone API that is available when needed, and not imposed when not needed, as general functionality, not just for Widgets. It also seems that it would require more than just an API... it needs an infrastructure from which to draw the relationship data, and security considerations. Like the Geolocation API encapsulates underlying device/service functionality (GPS, cell/wifi triangulation, logged IP locations, etc.), and the Widget Interface's Storage API uses functionality defined elsewhere (LocalStorage, SessionStorage, IndexedDB, WebDB, remote web service), a Social API would have to rely upon some source of data, which is not inherent in the device or a single established web service, so that would need to be defined. I don't think the WebApps WG is the right place to work on a Social API; I don't think it would get the specific interest such an API would require to do it right, with the current participants of this group (though others in the group should correct me if I'm wrong). Also, the WebApps WG has an urgent need to renew its charter to bring in deliverables we've already agreed are in scope, so I would be extremely reluctant to bring in a deliverable at this stage that has as broad a scope as a Social API. That's not to say a Social API is not useful or desirable. I'd love to see this done at W3C, and I think it's important to make sure it works well in both web sites and widgets. So, my counterproposal is to suggest that you work with Harry Halpin to propose a new Social API WG (maybe under Interaction Domain, but more fittingly under the Technology and Society Domain), and bring in the Google Wave and Open Social folks (since Google is already a W3C member), and find other stakeholders (Facebook?) who might also be interested, to help standardize what they have all already done. Harry and I have talked a bit before about next steps for the Social Web, and this strikes me as a logical and pragmatic next step. I will be happy to do what I can to help set this up, and to ensure good communication between our groups, and to make sure that it works well with Widgets. Yes, we over in the Social Web XG would be happy to provide some space where efforts like this one can be done, in particular a Social API requirements telecon and e-mail discussion with WebApps would be great. Looking at the list made earlier: * access to contacts on a specific device: Contacts API (DAP WG) [4] This is obvious an important point, but we need to make sure that Contacts API is compatible with PortableContacts/vCard, and maybe even look at FOAF. * access to relationships between contacts, etc.: no current work, but possible as an online service (XHR), or locally through markup like RDFa or microdata - I think this could be covered by some new API. Agreed, and we could also make sure that those in RDF have a declarative metadata approach that is compatible with some new API, but that users of such a API would not have to know about or use, i.e. compatible but orthogonal. Personally, I believe that if the relevant stake-holders can be brought on board, this would be a very worthy area for future standardization and will do everything I can to help. Looking at our schedule, we were hoping to have a call on this topic (i.e. W3C Widgets and OpenSocial), March 10th (5 PM GMT) still works [1]. For a general update on our work, take a look at our minutes [2] and wiki [3]. We'll have a draft final report out by end of March, but expect the XG to be extended by 3-6 months as we are still in the middle of a number of conversations. -harry [1]http://www.w3.org/2005/Incubator/socialweb/wiki/Schedule [2]http://www.w3.org/2005/Incubator/socialweb/ [3]http://www.w3.org/2005/Incubator/socialweb/wiki/ Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Scott Wilson wrote (on 2/13/10 5:21 AM): Hi Doug, I'm not adamant that these requirements are met specifically just for Widgets, just that these are where the current use-cases come
