- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Wed, 15 Apr 2015 18:19:34 -0400
- To: Brad Hill <hillbrad@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 04/15/2015 04:16 PM, Brad Hill wrote: > 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. Thank you for your time and for giving us some more time to work things out. > > 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 agree completely. I don't believe anyone chiming in from the Credentials CG, myself included, have intended to indicate that we want any Recommendation track spec to have normative references to specifications that aren't standards. Our main desire is for our voices to be heard and that consensus be reached before FPWD. > > I'll also note, again, the difference in the speculative > future-building mode of a CG vs. the implementation-driven mode of a WG. And this difference, coupled with the short time frame to respond, has made pinning down where our technical issues are with the spec is a bit more difficult. Since a Credentials WG has not yet been created, we've postponed making a certain number of highly detailed technical decisions thus far. Despite this, we have done enough work to see that there are some basic modeling conflicts with what our use cases require and the Credential Management API in its current form. Specifically, these conflicts have to do with the basic meaning of a credential and the extension mechanism in the current design. I think these conflicts can be overcome and some recommendations have been made via the github issue tracker. It's also worth mentioning that we do think we'll be able to have a WG created before the Credential Management API goes to REC. We have a charter and will be looking to create a WG hopefully before TPAC of this year. The point is that the future building this particular CG has been working on could be transitioning to a WG very soon. > 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. I do think this is well-understood by the Credentials CG. We don't want to put anything elaborate into the Credential Management API spec. We just want to ensure it will be compatible (and in an elegant way) with future work in the credentials space. We may have been inarticulate in our attempts to communicate this. The spec references a desire to be extensible for future work and we expect to transition some of that future work from the Credentials CG to a WG later this year. > > 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. I agree with this approach and think it's something we should all follow. I think I can speak for a number of Credentials CG members when I say that we also understand the notion that designing, editing, and implementing these specs is often done entirely on a volunteer basis and that we empathize completely with the fact that it can sometimes be a thankless experience. Any messages we've sent to the contrary were probably due to our own inelegance. -- Dave Longley CTO Digital Bazaar, Inc.
Received on Wednesday, 15 April 2015 22:19:59 UTC