- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 31 May 2015 23:54:58 -0400
- To: public-webappsec@w3.org
On 05/28/2015 03:09 PM, Brad Hill wrote: > Let's continue discussing naming, since that is a concern we may be > able to find a consensus on. Naming isn't the only remaining discussion if we choose to stop the cross-origin credential discussion here. The other three dependent discussions that should be triggered are: 1. What is the purpose of the extension mechanism if it can't support an identified extension use case? Especially while developers are insisting that it is fairly close to achieving their desired result? What other types of CM API extensions are expected to be produced by other groups? Has it been proven that the extension mechanism is capable of addressing those use cases? 2. Why is the support of federated credentials not considered to be a new protocol or cross-origin in nature when the Credential CG's cross-origin credentials are considered to be out of scope? 3. What is the real value-add of this API if #1 ends up being fairly hobbled and #2 turns out to be too experimental to make it to REC? In summary, if the extension mechanism already can't be used for a fairly obvious use case and federated credentials support doesn't make it to REC, how is this spec significantly better than the already deployed password managers in most browsers and browser extensions? Maybe the best path forward would be to punt on the Credential Management API for now and send it back to a group with a broader charter that is capable of discussing the cross-origin credential use case? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Web Payments: The Architect, the Sage, and the Moral Voice https://manu.sporny.org/2015/payments-collaboration/
Received on Monday, 1 June 2015 03:55:22 UTC