Re: [credential management] Identity Credentials API Extension

(tl;dr: We have already worked on API convergence for 45 days, and the more
context we get, the less it seems like it is even a good idea, for either
project.)

Adrian, we've now spent 45 days exploring the topic, and the spec editor
has been extremely engaged during that period.

To repeat some of the earlier context - participation in the W3C and
adoption of standards produced by it is voluntary.  It is a venue for
communities of interest to self-assemble under a set of mutually agreed
ground rules.  It is a good thing that we can have different communities
doing different types of projects with different scopes.  A chartered scope
is a critical tool to maintain the viability of each community by being
respectful of the time and energy participants invest, and it is a
necessary precondition of participation for organizations that are making
commitments of intellectual property regarding the deliverables of the
group.

The influence and expertise of the WebAppSec group is nothing more than
what its participants bring to it.  And nothing is stopping any of those
same people from participating in the Credentials CG or a WG chartered out
of it.

While "cross-origin" credentials sounds possibly reasonable in the
abstract, my exact point in this thread is that the more we explore what
that involves for the Credentials CG use cases, the less it seems like a
good fit for this API, even as an extension.  The clients and scenarios for
the use-cases are fundamentally distinct.  The Credentials CG's
"credentials" are not merely "cross-origin", they are multi-origin, and
involve the aggregation of many different types of asynchronous operations,
with a completely different set of inputs and outputs, totally different
error conditions and necessary error handling, much more extensive browser
UI and mediation for things like cryptographic operations, query
resolution, trust chaining, and selective disclosure.  Along the way there
are also fundamentally new security protocols and methods of establishing
trust involved while crossing origin barriers, including information flows
that would break or modify fundamental invariants of the web security model
without radically new user-experiences in the browser to support them.

So, I am simply saying, after taking a considerable amount of time and
effort to explore the possibilities desired at the beginning of this
conversation, namely that "these APIs are trying to do substantially
similar things" and "the Credential Management Level 1 API could also
accommodate the Credential CG use cases with some tweaks to the extension
model", I think that both premises are looking false at a very large and
rising probability.

It seems extremely unlikely that *either* of these very different takes on
"credential management" will be well-served by sharing an API.  I am sorry
if you find this answer disappointing, but I sincerely think it is for the
best for both projects.

Let's continue discussing naming, since that is a concern we may be able to
find a consensus on. (though I still maintain that any significance of
similar names for APIs with such massive differences in fundamental
features and serving different business goals will be less important than
anyone thinks in the long run)

-Brad

On Thu, May 28, 2015 at 3:50 AM Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> Hi Brad,
>
> To be clear, these are my opinions and not a reflection of the Web
> Payments IG or Credentials CG views. I think the chairs of these groups are
> better placed to speak for or on behalf of the groups.
>
> On 27 May 2015 at 19:04, Brad Hill <hillbrad@gmail.com> wrote:
>
>> It seems we are mostly in agreement, then: these are entirely different
>> technologies where only the degenerate use case of "login" is shared.
>> We've done a lot of work to try to harmonize, but in the end these
>> technologies are going to stand or fall on their own merits.  Where I
>> disagree is that I think the concern that that the adoption of the proposed
>> API here will harm the prospects for the Credentials CG's work are
>> unfounded, and disagree that we need to remove features in order to
>> preserve the turf the CG feels it has staked out.
>>
>
> If the Credential Management API is published in it's current form,
> limited to single-origin while attempting to provide a federated login
> solution, it is not only damaging to the plans of the Credentials CG but
> the idea of federated or decentralised identity and the definition of
> credentials in general.
>
> The API advertises itself as a means to help site owners leverage
> federated identities for their users but I will bet 90% of RP sites that
> implement the API will be surprised to discover that their user's still
> need to follow the same flow they do today to select a federated identity
> provider, from a potentially long list, log in and then enroll on the RP
> site using their federated credentials before the API, at some point in the
> future, is able to give the RP site a hint at which provider the user's
> federated identity originated.
>
> The "FederatedCredential" as defined by the API is not a credential, it's
> a hint and I think defining it as a credential is damaging in that it is
> misleading.
>
> What value does this add beyond what is already possible using cookies to
> remember the federated identity provider that a user has used in the past?
>
>
>
>>
>> You have an ambitious proposal that offers fundamentally new
>> possibilities for the Web to both users and application authors, you have
>> an interested community and momentum within that community, I think that
>> you should not worry so much about what we are doing here with this API.
>> If you can succeed in building what you aim to, nobody who is interested in
>> that will consider this any kind of substitute.
>>
>>
> I am not worried. That is a strange (and rather patronizing) choice of
> words.
>
> I am a little disappointed that a group with the influence of WebAppSec, a
> mandate to deal with issues of security on the Web and participants from
> the major browser vendors with the knowledge required to deal with this
> "ambitious" undertaking seems to be hiding behind it's charter in an effort
> to avoid having anything to do with dealing with identity on the Web, a
> topic that is quite obviously a critical component of security.
>
> As you say, the Credentials CG are taking on this "ambitious" project and
> all they have asked of WebAppSec is a concession in this API to allow
> cross-origin credentials. Perhaps I have missed it but I am yet to hear a
> strong argument against at least exploring cross-origin credentials as part
> of this API and yet it seems this is already off the table?
>
>>
>> We can bikeshed a bit longer on the name, but I think we are near or at
>> the end of where further engagement on API convergence is in any way
>> productive.
>>
>>
> This seems the likely, albeit rather disappointing, outcome.
>
>
>> On Wed, May 27, 2015 at 4:37 AM Adrian Hope-Bailie <adrian@hopebailie.com>
>> wrote:
>>
>>> Hi Brad,
>>>
>>> From my reading of the communications to date the primary issue that has
>>> been raised by the Credentials CG is the restriction within the current API
>>> to be same-origin.
>>>
>>> The existing FederatedCredential proposal makes no sense if it is
>>> restricted to same-origin use. Federation is, by definition, cross-origin.
>>>
>>> With the same-origin restriction in place, I am unsure what value the
>>> current proposed API adds or what problem it solves. The use case is so
>>> simple, and so close to the existing password-autocomplete functionality
>>> built into most browsers.
>>>
>>> As a user when I visit a site I have logged into before and have no
>>> current session I see a login form with my username and password already
>>> filled in and have the ability to explicitly re-use those "credentials" to
>>> login again. One click and I have achieved the same outcome as this API AND
>>> had the opportunity to do so explicitly. Is this API potentially making
>>> things worse for the user by hiding their control of the login process
>>> behind configuration screens? Also, given that this is a client side API I
>>> see little utility for server technology vendors who already do complex
>>> session management using existing technology.
>>>
>>> Unless WebAppSec considers cross-origin credentials in it's scope I see
>>> little value in this API. On the contrary, I see an API which will annex
>>> the use of the word "credential" in a very narrow use case which makes a
>>> more broad and valuable use case more challenging to implement in the
>>> future AND an API that purports to support federated login but is unable to
>>> solve the biggest usability issue in federated identity; the ability to
>>> filter the providers offered to the user so they are not presented with a
>>> wall of badges.
>>>
>>> Storing usernames and passwords in a same-origin only system makes
>>> sense. Storing any other credentials under such a restricted system
>>> doesn't. I propose that if the API is to be published it is vastly
>>> simplified to only support username/passwords and is renamed to "Password
>>> API" or "Login API".
>>>
>>> Adrian
>>>
>>>
>>> On 27 May 2015 at 05:20, Brad Hill <hillbrad@gmail.com> wrote:
>>>
>>>> I know Mike has gotten quite in-depth on this, and I'm willing to be
>>>> told I'm wrong, but the more I look at the Credentials CG's use cases as
>>>> presented here, the less I'm convinced they are good fit for the
>>>> "Credential Management API Level 1" spec.  Asynchrony is a nice and broad
>>>> abstraction behind which many things can be hidden. BUT...
>>>>
>>>> If use case #1 is: wait locally on a promise to return some very finite
>>>> set of information (username/password or username/federation provider pair)
>>>> that is stored or hopefully cached locally, with the worst case being the
>>>> user has to re-authenticate one time to their password manager and fetch
>>>> them from the cloud.
>>>>
>>>> And use case #2 is: take as input a "query", assess the satisfiability
>>>> of the query against available credentials and providers and perform an
>>>> unbounded set of recursively defined fetching, aggregation and
>>>> cryptographic operations, including queries to some as-yet-unspecified "new
>>>> mechanism where the URLs refer to decentralized network that holds onto
>>>> documents that include decentralized identifiers and public keys" in order
>>>> to resolve them, including possibly having the user perform authentication
>>>> or add new providers and credentials....
>>>>
>>>> Then I just don't see how it is in any way possible or sane to expect
>>>> the same API shape.  The latter case has so many more potential failure and
>>>> timeout cases and places which may require user interaction and resolution,
>>>> you'll either overcomplicate case #1 or never adequately deal with the
>>>> actual necessary complexity of #2.
>>>>
>>>> Even more so, the vast differences here mean there will never be a
>>>> client to the API that calls it in an abstract function without knowing in
>>>> advance which path they expect to be travelled.  Forcing callers with
>>>> clearly different intents into overly-abstracted APIs when there is no
>>>> driving use-case for the commonality is bad design, even if we can find a
>>>> way to make them fit.
>>>>
>>>> I think in particular the use cases desired by the Credentials CG will
>>>> suffer from further trying to achieve commonality here, because the APIs
>>>> will lack the necessary richness and specificity to purpose that are
>>>> required by the innovative patterns you're contemplating.
>>>> <hat=individual>I also believe it is naive to think you can understand what
>>>> the best API shape will look like until all of these moving parts are
>>>> themselves better defined in their success and failure cases.
>>>> </hat=individual>
>>>>
>>>> Additionally, there are fundamental changes to the web security and
>>>> privacy model which are contemplated by the Credentials CG's proposal which
>>>> should be dealt with independently.  Not using HTTPS and inventing an
>>>> entirely new method to locate and establish trust in keys is a huge thing
>>>> in and of itself, as big a thing as has ever been tried in this space, and
>>>> way too big an elephant to hide under the cafe table of this little API.
>>>>
>>>> My current opinion therefore, as chair, is that the proposals on the
>>>> table in the WebAppSec 2015 charter and from the Credentials CG are quite
>>>> different things, which may share some similarities in common naming and
>>>> broad intent, but which neither will benefit technically from further
>>>> efforts to converge.
>>>>
>>>> -Brad
>>>>
>>>> On Thu, May 21, 2015 at 12:21 PM Manu Sporny <msporny@digitalbazaar.com>
>>>> wrote:
>>>>
>>>>> bcc: Web Payments IG, Web Payments CG, Credentials CG
>>>>>
>>>>> Mike, Brad, Dan, and WebAppSec'ers,
>>>>>
>>>>> As promised on Monday, Dave Longley and I have put together an
>>>>> experimental extension spec for the Identity Credentials API, based on
>>>>> the WebAppSec Credential Management API:
>>>>>
>>>>>
>>>>> https://docs.google.com/document/d/1tI0CJ4wAKKPQacrxOmTtl_GQUBeVtbg8e1ZSXs2SWag/edit?pli=1#
>>>>>
>>>>> We followed Section 8.2 "Extension Points" in the CMAPI spec to do so.
>>>>> The document:
>>>>>
>>>>> 1. Starts out by providing an overview of what the Credentials CG and
>>>>>    Web Payments CG/IG would most likely need for their use cases.
>>>>> 2. We then elaborate on more-or-less how the extension would work in
>>>>>    practice, following the guidance given in section 8.2 on how to
>>>>>    write extensions. We provide all algorithms necessary to do a
>>>>>    simple cross-origin credential storage, request and transmission.
>>>>> 3. We close by listing the problems that we see with the current
>>>>>    specification as well as open questions wrt. browser implementation
>>>>>    concerns.
>>>>>
>>>>> At this point, we ask that:
>>>>>
>>>>> 1. The WebAppSec WG Review the extension specification, and
>>>>> 2. Make comments/suggestions either onlist or in the Google Doc, and
>>>>> 3. that Mike West schedules some time to chat with us to answer any
>>>>>    questions that he may have after reviewing the document.
>>>>>
>>>>> We're happy to jump on the next WebAppSec call and present this work if
>>>>> that's deemed helpful to the group.
>>>>>
>>>>> -- manu
>>>>>
>>>>> --
>>>>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>> blog: Web Payments: The Architect, the Sage, and the Moral Voice
>>>>> https://manu.sporny.org/2015/payments-collaboration/
>>>>>
>>>>>
>>>