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

(bcc: Web Payments IG and Credentials CG)

On 04/13/2015 04:45 AM, Mike West wrote:
> Hi Manu!

Hey Mike, thanks for the responses. I've blocked out a good chunk of
time today to try and respond to all your questions/assertions.

First, let me thank you for devoting the considerable time that you have
already spent in putting together the use cases and spec. Speaking as a
fellow editor, the job can be frustrating and thankless at times, so as
you read these responses, please keep in mind that we all appreciate the
work you're doing and are striving to get to the same general future you
and the WebAppSec group wants. There are just some concerns about the
path we take to get there.

Feedback starts below...

> I've put forward this draft of the credential management spec in 
> order to seek exactly this sort of feedback from developers. If
> there are indeed technical deficiencies in the spec that make it
> unsuitable for use cases that we ought to support, then we certainly
> need to change it.

+1, although the message I'm getting from some of the other participants
is: we don't see any overlap from what you're doing and what we're doing.

I disagree. I see some overlap that could cause problems down the road.
>From the looks of things, others do as well.

> Indeed, the API proposed in this document is intended to be fairly 
> generic (it has ~2 methods) and extensible (by subclassing 
> `Credential`) so as not to block future innovation. It would be 
> helpful to understand how exactly it blocks you from doing the work 
> you'd like to be doing.

Here's one way:

https://github.com/w3c/webappsec/issues/256#issuecomment-93427814

I think we should be careful to not use the "blocks" language. It's the
Web Platform, there is little that you can do to block other people from
doing something.

The goal here should be to provide an API that is simple and as future
proof as we can design today. A number of the members in the Credentials
CG knows what you're trying to do because we started designing something
that looked very close to it 7+ years ago, and again 4+ years ago.

Some of us understand what you're doing, but I don't think that you
quite understand what we would like to see changed yet. At least, it's
not apparent from the responses that the WebAppSec group has fully
grasped the points we're making.

> Perhaps the word "credentials" is causing problems; after skimming 
> the documents you pointed to, I don't see significant overlap
> between this spec and those groups. Is your concern that we're
> co-opting the term? Or is there something deeper?

Use of the term is problematic, as you're just specifying a very small
subset of credentials, but that's not the main issue.

There's something deeper, and that "something" has to do with the way
"Future Work" in the spec attempts to say that there are richer
credentials and you attempt to provide an API for those richer
credentials. That's where the overlap is.

Again, we don't think that the overlap is a bad thing. In fact, we think
it's great. However, the API design in the spec right now doesn't
support the types of richer credentials we know we're going to need.

As the github issue above points out, we don't think you need to make a
big change to support the future work both you and we envision. However,
not making a change would require us to spec out an entirely new API
that more or less looks 80% similar to what's in the spec right now.
That future doesn't thrill us, nor do I think it's good for the Web.

We'd rather build a very thin shim on top of what you've done rather
than having to redefine 80% of the proposed API.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: High-Stakes Credentials and Web Login
http://manu.sporny.org/2014/identity-credentials/

Received on Wednesday, 15 April 2015 16:18:23 UTC