Re: "Credentials" and consensus

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:20:00 UTC