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

I think that at this point it should be no problem for
WebAppSec to rename the Credential Management API to something like
"Password Manager API". The interfaces could use "identity" instead of
"credential"?

+1 as a start.
However this does miss the opportunity for the spec to be specifically
accommodating of the work and plans from the Web Payments IG and
Credentials CG which do overlap with the stated Future Work of the spec.
It also means that should a Credentials API be proposed in future (highly
likely it is currently spec'ed by the Credentials CG) we end up with two
APIs that will eventually begin to overlap.
Is that a problem?

Supporting linked-data as the mechanism for expressing identity and
credentials is the greatest bang-for-buck change that could be made to the
current spec.
Is this beyond achieving?

As far as I can tell all that the Credentials CG and Web Payments IG are
asking for is some time to give this a more thorough analysis before the
spec goes to FPWD and some active collaboration from the spec's editors.
Is there a good reason to deny this?

On 15 April 2015 at 03:28, Janusz Majnert <jmajnert@gmail.com> wrote:

> Hi,
> I totally agree with Brad. The use cases, goals and proposed solutions
> are so fundamentally different that I can't even see (at this point in
> time) what the two groups could converge on.
>
> It would be great if we could pin down exactly what should be done for
> the two groups not to step over each other. From what I understand,
> the initial argument was mostly about naming the specification and its
> interfaces. I think that at this point it should be no problem for
> WebAppSec to rename the Credential Management API to something like
> "Password Manager API". The interfaces could use "identity" instead of
> "credential"?
>
> Regards,
> Janusz Majnert
> Samsung Electronics
>
> 2015-04-14 19:19 GMT+02:00 Brad Hill <hillbrad@gmail.com>:
> > I think the subject of this thread is an excellent summary of the core
> issue
> > here, and the more I read, the more I'm convinced that the only overlap
> is
> > in the name of this spec and the CG.
> >
> > The Credentials CG is working on a very ambitious project to reinvent how
> > authentication, identity, federations and attested attributes are
> exchanged
> > on the web.
> >
> > The Credential Management API is attempting to make incremental
> improvements
> > to existing browser (and plugin) technology for ease-of-use affordances
> > around saving what might accurately be termed legacy username/password
> and
> > username/realm pairs.
> >
> > These differences are also in-keeping with the style and charter
> obligations
> > of the different types of groups.  A Community Group has much looser
> patent
> > commitments and a broader scope to explore and invent.  A Working Group
> is
> > chartered with a specific scope, strong patent commitments within that
> > scope, and member organizations *very* carefully review that scope before
> > choosing to participate.
> >
> > Given that WebAppSec has just completed a rechartering, and the scope in
> > that charter, I don't think that we _can_ work on something with much
> more
> > detail than the abstractly extensible model that Mike has specified.
> >
> > The overall construction might be arranged differently, but getting into
> the
> > details of things going on in the Credentials CG, which involves
> technology
> > around payment instruments, claims, blinding, signatures, credential
> > brokering, linked data formats, etc. is seriously beyond our charter and
> > risks the ability for many of our participating organizations to
> continue to
> > do so, were we to put it into the charter.  (and I don't think there is
> any
> > energy or enthusiasm for another rechartering process at this time)
> >
> > Really, I see the goals and use cases targeted here as different enough
> that
> > neither one is a threat to the other - even if they were to continue to
> > share the term "credentials".
> >
> > But, unfortunately, as a point of order within this group, I'd like to
> ask
> > that we confine discussion to the shape of the abstract API.  If we can
> > improve it to make it more future-proof, we should of course do so, but
> > providing a direct implementation for the Credential CG and Payment IG's
> use
> > cases is not what we are chartered to do, members of those groups have
> not
> > joined the WG or executed contributor's agreements, and we cannot take
> > potentially encumbered technology into our specifications, especially
> that
> > which is beyond our charter scope.
> >
> > Sincerely,
> >
> > Brad Hill
> > Co-Chair WebAppSec WG
> >
> >
> >
> >
>
>