Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

Anders,

Tl;dr is, user choice and agency is paramount.  Users are already in the
generally centralized identity silos from birth; their choices and personal
considerations are rarely if ever a consideration.  What I propose is
opening the door and describing a path which can be chosen by the user.

You know the old Robert Frost line... "two paths diverged in a wood..."  In
history we haven't had the means to realistically present people with
options that would diverge from the status quo or from the road most
traveled at all. And now we do... so it's out there.

What we do with this knowledge next, that's up to all of us.

~ Nullius in verba
On Apr 5, 2015 1:24 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com>
wrote:

>  On 2015-04-05 19:02, Colin Gallagher wrote:
>
> So if I read this correctly you are against standards that support
> centralized identities and ask W3C to follow this?
>
> What we mainly have today are rather "identity silos" where an identity
> (credential may be a better name) can only be used with a particular
> service provider.  As an example my G+, FB, and Bank.France accounts all
> have (should at least...) different userid/passwords.
>
> However, my Bank.Sweden use an eID which also allows me to access the tax
> department and some 20 other public-sector agencies using a pretty nifty
> mobile-phone-based PKI solution.   That this works is because there is a
> citizen ID (like SSN) concept in Sweden.  IMO, it is up to the Swedish
> people ("the users") to dismount this system if that's what they want.   To
> succeed with that there must be credible alternatives which doesn't
> introduce too much fuzz.  If you have one[1], it is still up to you and
> other identity activists to "sell" this concept.
>
> Personally I consider the web browser a "platform" and as a platform
> builder I believe the more uses it has the better as long as they are not
> technically inferior [2].  Most technology can be used in "wrong" way.  The
> web has tons of bad stuff but removing that is a political and/or legal
> process.
>
> Anders
>
> 1]  I cannot from the documentation you provided figure out if there's
> something missing in browsers or not
>
> 2] like silently leaking identity information or forcing security prompts
> that no mere mortals can understand the consequences of:
> http://webpki.org/papers/permissions.pdf
>
>  Here on Siva's points discussing identity standards, the key thing to me
> is ensuring that the user decides. If you say you want some centralized
> sort of standard it must never be forced on anyone (in my opinion, in
> corporation-states that adopt and require universal centralized
> identification systems whether for internal tracking of citizens or for
> "e-id" purposes - there should never be a mandate for such systems to be
> supported in web standards under development).  The idea is to reduce as
> close to zero the potential for coercion and use of legal threats against
> users.  Recall that the basis for most organized surplus violence has its
> root in coercive and violent systems, including states, which have
> monopolized citizen identity systems and then used the identities collected
> to remove resources from citizens in increasingly destructive spiral of war
> and destruction.  This back story on identity and our abuse of it as a
> society is but one of the many reasons against any system that would
> facilitate or ease centralized identity standards. A different direction is
> needed that provides the user with the power to choose and manage their
> identities and resources which correspond to those identities in a fully
> decentralized way, free from the shackles of the past and which provides
> the user with identity options which are not reliant upon any organization,
> institution, or service.
>
> Rather than a political objective such as "reduce potential for warmaking"
> or "increase decentralization online," however, the W3C's stance on
> identity should not be so political as expressed. It should be simplified
> to a point, like this:
>
> "Users need choices in what identity or identity system they will utilize..
> Standards developed on the issue of identities will favor user choice and
> respect users' consent and agency, providing for ways that users can define
> their own identities and depart from coercive systems."
>
> I offer the following for examples of decentralized identity projects
> (I've authored some of what you see, such as the ABIS project which
> includes partnership with IDMAS, a decentralized ID proposal that I did not
> author, and I did also write the Trans-identical proposal presented last
> year to W3C, shown below as item 2).
>
> 1.  Bitname - presently contains reference links to discussion fora on
> decentralized identity concepts https://github.com/abisprotocol/bitname
>
> 2.  Trans-identical proposal (as I presented it at WebCrypto2014) -
> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_12.txt
>
> 3. ABIS, shown here in partnership with IDMAS - http://abis.io (Note the
> IDMAS repository shown at the ABIS page, contains a strong decentralized
> identity development tool... please do have a look at it!)
>
> I hope this sparks some discussion. Thanks to Siva for his comment to
> which I am replying, to Anders who I had some discussion with about this
> before, and thanks to BJ Perng who recently encouraged me to discuss
> identity issues further here.
> On Jan 29, 2015 11:31 PM, "Siva Narendra" <siva@tyfone.com> wrote:
>
>> (+1 for Karen's proposal, albeit the nuances have to be determined in a
>> future WG.)
>>
>> Pls see attached a presentation for W3C's consideration, along similar
>> lines as Karen, but perhaps more generic. It is not completely vetted, that
>> of course should be after the formation of a future WG.
>>
>> Based on [1] needless to say there was unanimous interest for hardware
>> security based on the workshop in Sep 2014. The unanimous interest becomes
>> moderate interest based on the voting if one considers just
>> individual-managed IDs (aka FIDO). Hopefully W3C will consider that the web
>> standards should be built to support both new standards that enables
>> individual-managed and  existing standards that enable centrally-issued.
>>
>> Unless I'm mistaken,  clearly there are two camps. One set of parties,
>> PayPal..., that strongly feel centrally-issued identity standards (such as
>> banking, payments, healthcare, citizen cards...) have absolutely NO place
>> for the Web and the other set of parties,  Gemalto, Tyfone, Mozilla...,
>> that feels Web standards should include both centrally-issued as well as
>> user-managed identity standards through a generic framework (see attached).
>>
>> Irrespective of where we politically/technically stand limited by each of
>> our perceptions, for hardware security, it is absolutely essential for W3C
>> to support both existing centrally-issued ID standards and the new
>> user-managed ID standards such as FIDO.
>>
>> With all due respect, FIDO,  is not a "be all end all" .  Anything less
>> than a generic framework will undermine the usefulness and the openness of
>> the web when adding hardware (that needs to manufactured & dustributed) to
>> secure ID, data, and transactions.
>>
>> We cannot bridge the divide between new FIDO individual-managed standards
>> and well-established centrally-issued standards, unless and until we know
>> who will pay for hardware and who will pay for distribution. So let's
>> support all through ONE generic framework (see attached). Let the user's
>> pick the winners if some happen to be better than the others. Let us not
>> assume users are uneducated about the tradeoffs.
>>
>> [1] http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/
>>
>> Best regards,
>> Siva
>>
>> On 2015-01-29 23:50, Brad Hill wrote:
>>
>> I would like to see details of how this kind of API would or could
>> interact with the Same-Origin model of web security, specifically:
>>
>>  1. Privacy and tracking.  How does the presence of specific crypto
>> elements and discoverable keys which are not Origin-scoped not create
>> privacy violations?
>>
>> 2. Origin security.  How are risks around identification of or
>> impersonation of the server-side of a transaction, and potential abuse of a
>> globally-scope key mitigated by  this kind of API design?
>>
>> Without a clear discussion of how this API fits into the existing Web
>> security and threat model, I think it is inappropriate to proceed.  We
>> can't just throw away the fundamental security model that billions of users
>> and deployed applications depend on, and I see no evidence (at least in
>> these few slides) that such issues have been considered by this proposal..
>>
>>
>> +1
>>
>> I sent a bunch of similar questions privately.
>>
>> Assuming that the scheme indeed *is* SOP compliant a number of other
>> questions arise such as:
>> - What does this offer that U2F doesn't already have?
>> - What are the thought applications for SOP-constrained certificates?
>>
>> Then I would of course be very interested hearing how this specification
>> matches the following
>> bold statement by the W3C
>>
>>              http://www.w3.org/2015/01/banker_payments.pdf
>>
>> given the fact that
>>
>>              Secure AND Convenient Web Payments
>>
>> haven't really progressed the last 20 years or so.
>> If you consider usage and importance also, it has actually moved in the
>> *opposite* direction.
>>
>> Cheers
>> Anders Rundgren
>>
>>
>> Brad Hill
>>
>> From: Lu HongQian Karen <karen.lu@gemalto.com<mailto:karen.lu@gemalto.com
>> >>
>> Date: Wednesday, January 28, 2015 at 10:01 AM
>> To: GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:
>> Virginie.Galindo@gemalto.com>>, "public-webcrypto@w3.org<mailto:
>> public-webcrypto@w3.org>" <public-webcrypto@w3.org<mailto:
>> public-webcrypto@w3.org>>
>> Cc: "public-web-security@w3.org<mailto:public-web-security@w3.org>" <
>> public-web-security@w3.org<mailto:public-web-security@w3.org>>, Wendy
>> Seltzer <wseltzer@w3.org<mailto:wseltzer@w3.org>>, Harry Halpin <
>> hhalpin@w3.org<mailto:hhalpin@w3.org>>
>> Subject: RE: [W3C Web Crypto WG] Rechartering discussion - Gemalto
>> contribution
>> Resent-From: <public-web-security@w3.org<mailto:
>> public-web-security@w3.org>>
>> Resent-Date: Wednesday, January 28, 2015 at 10:04 AM
>>
>>     Please review Gemalto’s contribution. We welcome your comments.
>>
>>     Regards,
>>
>>     Karen
>>
>>     *From:*GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com]
>>     *Sent:* Wednesday, January 07, 2015 3:48 AM
>>     *To:*public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
>>     *Cc:*public-web-security@w3.org<mailto:public-web-security@w3.org>;
>> Wendy Seltzer; Harry Halpin
>>     *Subject:* [W3C Web Crypto WG] Rechartering discussion
>>
>>     Dear all,
>>
>>     Web Crypto WG charter [1] will end by the end of March. We need to
>> prepare the next charter of Web Crypto.
>>
>>     As a reminder, the conversation has started on this page :
>> https://www.w3.org/Security/wiki/IG/webcryptonext_draft_charter
>>
>>     Feel free to add you ideas and suggestions on the wiki and/or expose
>> your opinion and question on thepublic-webcrypto@w3.org<mailto:
>> public-webcrypto@w3.org> orpublic-webcrypto-comment@w3.org<mailto:
>> public-webcrypto-comment@w3.org> (for non W3C Web Crypto WG members).
>>
>>     Regards,
>>
>>     Virginie
>>
>>     [1]http://www.w3.org/2011/11/webcryptography-charter.html
>>
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>     /This message and any attachments are intended solely for the
>> addressees and may contain confidential information. Any unauthorized use
>> or disclosure, either whole or partial, is prohibited.
>>     E-mails are susceptible to alteration. Our company shall not be
>> liable for the message if altered, changed or falsified. If you are not the
>> intended recipient of this message, please delete it and notify the sender.
>>     Although all reasonable efforts have been made to keep this
>> transmission free from viruses, the sender will not be liable for damages
>> caused by a transmitted virus./
>>
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>     This message and any attachments are intended solely for the
>> addressees and may contain confidential information. Any unauthorized use
>> or disclosure, either whole or partial, is prohibited.
>>     E-mails are susceptible to alteration. Our company shall not be
>> liable for the message if altered, changed or falsified. If you are not the
>> intended recipient of this message, please delete it and notify the sender.
>>     Although all reasonable efforts have been made to keep this
>> transmission free from viruses, the sender will not be liable for damages
>> caused by a transmitted virus.
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>     This message and any attachments are intended solely for the
>> addressees and may contain confidential information. Any unauthorized use
>> or disclosure, either whole or partial, is prohibited.
>>     E-mails are susceptible to alteration. Our company shall not be
>> liable for the message if altered, changed or falsified. If you are not the
>> intended recipient of this message, please delete it and notify the sender.
>>     Although all reasonable efforts have been made to keep this
>> transmission free from viruses, the sender will not be liable for damages
>> caused by a transmitted virus
>>
>>
>