- From: Brad Hill <hillbrad@gmail.com>
- Date: Wed, 15 Apr 2015 20:16:12 +0000
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAEeYn8i3iEH6W+JNoJC+0zOG5RYBjhZA8d1p3tyqV662cpH78Q@mail.gmail.com>
As our discussions progress, I have a few points I'd like to make here in my role as Chair of WebAppSec: Firstly, thank you, everyone, for the generally civil, cooperative and collaborative tone. I'm very happy to see that there seems to be some progress being made. As these discussions arose in response to a Call for Consensus, and we clearly have not yet reached one, it seems reasonable to extend it a few days, so long as we are making progress - either to prove out the intuition of some that the proposed API can be modified to a pattern that is compatible with a broader set of future credential possibilities, or to determine that we are actually dealing with two different concepts here. With those positive thoughts in mind, I would like to address a few issues of tone and substance. I think it is reasonable to explain a new credential pattern (e.g. LinkedData as a credential) and ask or suggest how an API shape could accommodate it. I don't think it is reasonable to open the conversation, as it were, with a demand that the entire API be restructured to make this the central model for the implementation ,when nobody is using it today and the data the spec is chartered to work with is nowhere structured this way. Likewise for locally stored vs. network credentials / claims / etc. More generally, it is reasonable to look for patterns to accomplish broader possibilities for an extensible future, but it's not reasonable to insist on new normative references as the heart of a specification on Recommendation track which are themselves not standards. (or in some cases even drafts!) For example, LinkedData is a standard, but LinkedData as a credential/identity is not, nor how to fetch and operate over credentials defined as such. I'll also note, again, the difference in the speculative future-building mode of a CG vs. the implementation-driven mode of a WG. Our charter specifies that our specifications must have two independent implementations to advance to Recommendation. As such, a big part of our consensus process for drawing up our charter was making sure that we have interest, or at least no objection, by multiple browser vendors in building everything we undertake, and that people are "signed up" for the work. If we make the blueprints too elaborate for the foundations we have, nobody will build it, and we will all have wasted our time. Most generally, it is just a matter of common courtesy to be respectful of the time and effort of others, and to be humble in how you propose to spend it and what you ask for. The meaningful work of this group exists in large part due to the generosity and efforts of our Editors and implementers. If we demand beyond what is possible for them to accomplish and the scope of what they've volunteered to do, we end up just building castles in the air. So, please, ask, do not demand. Find room for your visions of the future, but do not expect everyone else to immediately accept it. Plan to reinvent the world, but plan to get there by incremental steps taken on solid foundations. thank you, Brad Hill
Received on Wednesday, 15 April 2015 20:17:09 UTC