Re: Technical Review of WebAppSec Credential Management API [2/3] (was Re: Overlap with Credentials/Web Payments CG)

Hi Manu, Mike,

It appears that on the one hand Manu is asserting that the current design
of the API is restrictive and on the other Mike is asserting that it is
extensible and therefore future use cases are possible through extension of
this API.
You are both looking at the same evidence and drawing directly
contradictory conclusions.

May I suggest that the best way to resolve this is to test these directly.
Can the publishing of the spec be held back for an agreed period to allow
the Credentials CG to attempt to POC it's extensive use case list against
this API.
Bugs can be logged via Github and discussed on this list with a view to
reaching a deadline in the future when all use cases have been tested
against the API.

At this time I would expect to a have a more usable issue list that can
form the basis of further debate as it seems this is all very theoretical
at this stage and the result is two camps making directly contradictory
assertions.
Perhaps through the miracles of collaboration we may have an updated API
spec that does not cater for all of the Credentials CG and Web Payments IG
requirements but is accepted by all as sufficiently open to be extensible
to do so in future.

>From a technical perspective I see two issues with the API which I believe
are the areas of most friction.
The Credentials CG, and Web Payments IG are advocating a design whereby:
1. Credentials are stored and distributed in the form of linked-data
documents.
2. Are portable between IdPs and the agent that shares them from the IdP to
the RP does some form of blinding to prevent the IdP from tracking where
the credential is used.

As such different credential "types" take the same form (a common JSON data
structure) but have different identifiers, types (expressed as a URI),
issuers and signers and it is the interpretation of all of these that
separates a drivers license, from a login credential from a government
issued identity. Mike's assertion that different credentials can simply be
accommodated by sub-classing the base Credential class is not obviously
compatible.

Without having tried it myself I'd suggest that two minor modification to
the API may accommodate the requirements of the Credentials CG and Web
Payments IG:

1. Allow the browser to act as an agent between an IdP and RP rather than
always assuming the role of IdP (although this should also be in
scope/possible) as suggested previously by Dave Longley in Manu's last email
2. The definition of a credential object could more closely match the
proposal in the latest Credentials CG spec:
http://opencreds.org/specs/source/identity-credentials/#a-typical-identity
(i.e Properties such as expiry, id, type, signature should exist on the
base Credential class)

If this API were designed well it may even abstract away complexities such
as signature verification so that the calling code can simply see which
credentials have been signed, issuer verified etc.

Happy to help with this effort.

Adrian

On 14 April 2015 at 01:30, Mike West <mkwst@google.com> wrote:

> Hi Manu! Thanks for adding detail to your initial email. I didn't catch
> the "[1/3]" part of the subject line, so I fear that this conversation
> could become a bit confusing as it shards across multiple threads. I'll try
> to respond inline below, but I suspect we're going to be a bit confused.
> Perhaps we could just stay in this thread rather than further sharding the
> conversation with a "3/3"?
>
> I've cut out some bits that seemed repetitive (and I'd like to defer
> discussion of the list of details at the bottom of your mail either to
> explicit issues on GitHub, or a future thread), but this is still a huge
> email. Apologies for that. I hope we can condense it down to some central
> issues going forward.
>
> On Tue, Apr 14, 2015 at 7:20 AM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> A person uses Google Chrome on their laptop and Safari on their iPhone.
>> Assuming the success of this spec, how is that ecosystem supported?
>>
>
> This isn't a problem unique to the features this spec proposes. That is,
> both of these browsers already have password managers, which are de facto
> isolated sets of credentials, collected by isolated sets of proprietary
> heuristics. Insofar as it's a problem, it's a problem that this spec
> neither creates nor attempts to solve.
>
> I think your claim is that this spec would make the problem worse by
> encouraging websites to actively interact with the password manager,
> thereby shutting extensions out? I can't speak for any vendor other than
> Chrome, but in Chrome, extensions can already disable the embedded password
> manager (via `chrome.privacy.settings.passwordSavingEnabled`), and can
> already inject JavaScript that overwrites native implementations of DOM
> methods. I fully expect extensions like LastPass, 1Password, etc to do both.
>
>
>> I assert that without some sort of server-side component or export
>> feature, it'll be harder to switch from one browser to another because
>> all of your 20+ random character passwords will be locked into Google
>> Chrome, forcing you to use Google Chrome across all of your devices.
>>
>
> 1. De facto, every browser and password manager I've used has the ability
> to forcibly import credentials from other browsers in the status quo. It's
> not clear that a de jure standard is necessary, though I agree that it
> would be nice to have.
>
> 2. It would, indeed, be good for browser vendors to offer explicit import
> and export functionality. Again, that seems like a nice thing to do, but
> not a necessary precondition for introducing an imperative API.
>
>
>> A potential solution to this problem is to enable export or storage of
>> credentials to a server-based component that allows credentials to be
>> transported easily from one browser brand to another.
>>
>
> That is a potential solution. LastPass and others seem to be doing it
> pretty well today, in fact.
>
>
>> Does the spec provide a suggestion on allowing browser extensions to
>> override navigator.credentials? If it does, are the security
>> ramifications of doing so detailed anywhere? If it doesn't, isn't it
>> making the state of the art worse by removing the ability to share
>> credentials across multiple browser brands?
>>
>
> That's not a requirement the specification can make, however, as
> proprietary extension platforms aren't part of the web. As noted above,
> this is certainly what Chrome will do; other vendors will make their own
> decisions.
>
>
>> A potential solution to this problem is to spec a server-side component
>> that allows credentials to be easily sync'd between browser brands.
>>
>
> That is a potential solution. It seems like it might be nice to have.
>
>
>> Assuming a world where you have to provide a more complex credential,
>> like an assertion that you're over the age of 21 so you can buy alcohol
>> from a US online liquor store, how is that credential retrieved from the
>> web-based credential storage mechanism? How is it stored locally?
>> Updated? Issued from a government website and sent to the liquor store
>> website?
>>
>
> If one wanted a browser to be able to interact with a third-party in order
> to make such an assertion, this API would allow you to define a
> `AgeVerificationCredential` with whatever metadata was necessary in order
> to ask a third-party for age verification, and place whatever methods on
> that object you deemed necessary for the assertion to be obtained and
> delivered (with all of the security properties I'm sure you've put a lot of
> thought into already).
>
> It's not clear to me what aspects of the API design prevent that from
> being possible.
>
>
>> Since the spec seems to have larger goals (see "Future Work"), an API
>> design that allows the credential request to be redirected to an
>> external website and then the response posted back to a credential
>> consuming URL on the Relying Party seems to be in order.
>>
>
> That might be necessary and desirable for some kinds of credentials. It
> does not seem to be necessary for all kinds of credentials, so making it a
> requirement in the API seems like unnecessary complexity. If and when we
> decide to introduce support for such credentials, we can (easily?) define
> an interface that makes sense.
>
>
>> BrowserID was about killing the password and it got a lot of things
>>
> right. The Credential Management API seems like a big step backwards -
>> standardizing the broken username/password scheme instead of replacing
>> it with something better.
>>
>
> 1. For better or worse, schemes like BrowserID have yet to obtain wide
> acceptance in the market, while password are ubiquitous.
>
> 2. Password managers make users safer in a wide variety of ways. I can
> enumerate advantages if you like, but I suspect we're on the same page here
> already, given your LastPass advocacy above.
>
> 3. Making it easier for websites to integrate with password managers makes
> it more likely that users will use password managers, and obtain the
> advantages they provide, as long as password are still overwhelmingly used
> for authentication.
>
> This seems like a reasonable goal for the short-to-medium term.
>
>
>> Worse, by standardizing the username/password login scheme, the spec is
>> extending its lifespan, not reducing it.
>>
>
> Note that every mainstream browser already contains a password manager,
> and already does its best to help users deal with the sign-in problem.
>
>
>> A potential solution is to create a mechanism that takes advantage of
>> some basic crypto, like BrowsrID did, to generate stronger login
>> credentials.
>>
>
> This is a potential solution. It has the advantage of being theoretically
> wonderful. It has the disadvantage of requiring authors to change.
>
> I don't think anything in the proposed API would prevent interested folks
> from defining a `HotNewCredential` type, and offering it to developers. In
> fact, standardizing a nicely generic way of requesting and storing
> credentials seems to be a nice way to make such a definition _easier_ for
> developers to find, understand, and use.
>
>
>> The code iterates over a number of federated identity providers. This
>> approach ensures that there will only be a handful federated identity
>> providers and people will not have a wide array of options on who to use
>> for login. How big can this list get before developers get wary of
>> having X different ways of logging into their website?
>>
>
> This is a social problem which exists in the status quo. For reasons,
> Facebook's SDK is distinct from Twitter's SDK, which is distinct from
> StackExchange's OpenID implementation: sites which want to support all of
> these options need to include a number of different sign-in mechanisms.
> Nothing about this spec changes that reality. I agree it would be nice to
> change, but disagree that this spec makes the problem worse.
>
> On the contrary, this spec makes it possible for a site to _meaningfully_
> integrate more than one identity provider without giving their users a list
> of options that they can't feasibly be expected to navigate. By specifying
> the supported federations, and asking the user agent to match that list
> against the local password store, users can make a decision between those
> providers they already have relationships with. That seems like a nice way
> of mitigating some of the badness of the underlying problem.
>
>
>> A potential solution is to either standardize a federated identity
>> provider response format so that a switch statement isn't necessary. For
>> example, "this website trusts digital signatures from these 150
>> federated identity providers for the purposes of login".
>>
>
> That is a potential solution. It has the disadvantage of requiring both
> authors and identity providers to change.
>
> Previous attempts to solve this problem (OAuth2, for instance) don't fill
> me with confidence that it's a problem we can solve in the short-to-medium
> term. If we do, great! We can define a `HotNewCredential` type to cover the
> new hotness, implement it in all browsers, and be happy together. :)
>
>
>> There is definitely an overlap with login and what I'll call "rich
>> federated credentials" (drivers licenses, etc.). However, the overlap is
>> just that "login" is only one type of credential in a sea of other kinds
>> of credentials (like drivers licenses, professional licenses, age
>> assertions, shipping addresses, etc.).
>>
>
> >From a user agent implementer's perspective, I'd suggest that "login" is
> a very important kind of credential that every user agent I've used has
> built-in support for. My claim is that that support is crippled by reliance
> on proprietary heuristics, and can be significantly improved via an API
> such as the one I've proposed.
>
> To the extent that other types of credentials are important, I'd invite
> you to explore the possibility of extending the proposed API with the kinds
> of credentials you're interested in driving support for, and getting
> browser vendors on board with implementing those extensions.
>
>
>> Here are a few of the other problems related to federated credentials in
>> the spec:
>>
>
> I'd suggest that these more detailed concerns hop over to
> https://github.com/w3c/webappsec/issues/new?title=CREDENTIAL:%20 for
> discussion, and that we keep this thread focused on the larger questions
> you're raising.
>
> Thanks!
>
> -mike
>
> --
> Mike West <mkwst@google.com>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München,
> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
> Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
>