Re: [credential management] Identity Credentials API Extension

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/
>
>