Re: Overlap with Credentials/Web Payments CG (was Re: CfC to publish a FPWD of Credential Management; ending April 17th.)

On Wed, Apr 15, 2015 at 3:08 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> But we need to concentrate on showing what the specific issues are and
> how they can be addressed. It would be great if concerned members of
> Credential and Web Payments CGs could raise issues on github instead
> of reiterating the same points in lengthy emails :-)
>
> +1 again, however the call for consensus closes in 2 days.
> As far as I know there are a number of people working on providing just
> that feedback but they simply require some more time.
> As I asked in a previous email; would it help for a member/members of
> these groups to join the WebAppSec WG in order to provide a voice from that
> corner?
> I am happy to do so if required but have not had feedback on this yet.
>
> My original email on this thread was a proposal that the groups be given
> time to pull down the latest polyfill code and demos and actually attempt
> to run through some use cases as a basis for logging issues in GitHub.
> That email has had no response...
>

I haven't responded because I want to make sure I understand the documents
Credentials CG has produced before extending the thread further. :)

I've read through both http://opencreds.org/specs/source/use-cases/ (where
username/password login is explicitly excluded from the flow under
consideration in section 4.3
<http://opencreds.org/specs/source/use-cases/#legacy-support>), and
http://opencreds.org/specs/source/identity-credentials/. I haven't found
reference to the `navigator.credentials.get` API that David referenced in
an earlier message on this thread. Could you point me at that document so I
can get a feel for the way you've structured things?

My impression is that we might indeed be able to find some abstraction that
doesn't stomp on anyone's use cases. I'm a little worried that doing so
will make both sets of use cases more difficult to actually use, and
developer ergonomics are important. I'm also worried that the credentials
CG's work on both a new protocol and delivery mechanism is a bit too "boil
the ocean"; my hope was to slowly move towards a better world by leveraging
the things that currently exist today. The use cases in section 1.1 of the
credential spec I proposed lay out the baby steps that I think start us
down the road. Critically, they have very small hurdles to developer
adoption, as they can be trivially layered on top of an existing sign-in
flow.

I recognize that the world the credentials CG is envisioning is (in broad
strokes) "better" than usernames and passwords. I hope you can likewise
recognize that supporting usernames and passwords, and existing federations
(which, together constitute the entirety of status-quo sign-in) is
something that has real value for both users and web developers in the
short- to medium-term.

-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.)