"Credentials" and consensus

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