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

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

Received on Wednesday, 15 April 2015 10:30:05 UTC