W3C home > Mailing lists > Public > public-credentials@w3.org > March 2015

Re: Egypt joins Nigeria in using association branded national ID card

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sun, 08 Mar 2015 08:59:19 +0100
Message-ID: <54FC0157.10005@gmail.com>
To: Adrian Hope-Bailie <adrian@hopebailie.com>
CC: Erik Ros <mail@erikros.me>, W3C Credentials Community Group <public-credentials@w3.org>, davidnicol@gmail.com
On 2015-03-07 22:03, Adrian Hope-Bailie wrote:
> Unless the eID requires a PIN or similar to be unlocked?

This is possible but atypical, usually it is only the private key that needs to be unlocked.


> That is the synergy I am referring to. The ability to have multiple applications on a single smart card chip.
> This was the intention for EMV at design time but has never really been exploited.

That it haven't been exploited is because the core is a business model ("renting card space") which has been tried by MNOs since the late 90'ties with moderate success.
The net effect is that they have created an incentive for embedded security in platforms, which eventually will kill the SIM as a product:
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z36xxx-z37xxx-datasheet-vol-1.pdf


> Ultimately authorising a debit from my card is actually just using the card as a token to prove I am who i say I am and that I have permission to authorise a debit of an account in my name so it does seem logical that the same token (the card) is usable for both use cases. However, as I say it would be better (in my opinion) if this was done in a way that my national ID was a proxy to the process and worked on any card network.
> i.e. The card networks allow a national id verification as a form of auth instead of a PIN or similar

That could work although there's no need for bringing the ID into the actual card networks:
http://webpki.org/papers/decentralized-payments.pdf
Payment Provider in the picture is typically your bank who already know who you are.

Personally I believe government IDs will continue to be used as "secure bootstrap" for other credentials rather than becoming a part of the transaction itself.
One reason for that is that the "card" form-factor is incompatible with most consumer computing equipment.
In most cases government IDs will only be used as physical IDs, the "e" part has shown to be very expensive to exploit.

In fact, with the recent deprecation of browser plugins and the failure of the W3C smart card (etc) mission
(https://lists.w3.org/Archives/Public/public-web-security/2015Feb/0034.html), eIDs have effectively taken a step backward.

Anders

>
> .
>
> On 7 March 2015 at 14:15, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     I can't figure out what the link is between the national ID and payments.
>     I do know that some Nordic countries have put an eID-application in the same chip as the EMV-application.
>     I think this is a horrible idea because then every merchant can read your ID as well.
>
>     Anders
>     On 2015-03-07 12:15, Adrian Hope-Bailie wrote:
>
>         Hi Erik,
>
>         I think you meant to direct your comment to David?
>
>         I would agree with you and add the following from my personal position:
>
>         I live in a country where government tenders are almost always shrouded in some level of controversy.
>         When an international commercial organisation is awarded (direct or indirect) control of a government institution it makes me very nervous.
>         After the deal is done and the government ID running payment applications that are subject to some commercial entity's rules it's very hard to go back.
>
>         I would agree with David that having a government ID that is also a payment instrument is an excellent synergy but would prefer that this was through some government/central bank controlled (or better independant and decentralized) proxy to the commercial payments providers.
>
>         Adrian
>
>
>         On 7 March 2015 at 00:15, Erik Ros <mail@erikros.me <mailto:mail@erikros.me> <mailto:mail@erikros.me <mailto:mail@erikros.me>>> wrote:
>
>              Dear Adrian,
>
>              you ask why not, the answer to that would have to be:
>
>              because it is a cluttering of power. We want power to be divided as equally as possible over as many people as possible (IMO).
>
>              I would like take my remark to a broader point. I think the specifications that are being created should valour de-centrality (the primary success factor of the internet). We shouldn't need the government, or a credit card company to make and economic exchange.
>
>              We could do without this dependency. Perhaps we should have open source exchange providers?..
>
>              Kind regards,
>
>              Erik
>
>
>              On 06-03-15 21:10, David Nicol wrote:
>
>
>                  On Tue, Mar 3, 2015 at 6:37 AM, Adrian Hope-Bailie <adrian@hopebailie.com <mailto:adrian@hopebailie.com> <mailto:adrian@hopebailie.com <mailto:adrian@hopebailie.com>>__> wrote:
>
>                      I don't think this is a very encouraging trend:
>             http://www.finextra.com/news/__fullstory.aspx?newsitemid=__27066 <http://www.finextra.com/news/fullstory.aspx?newsitemid=27066>
>
>
>                  Why not? Aside from surveillance and monopoly concerns that are actually there even without making a government-issued ID card a payment instrument, it's excellent synergy. At least
>                  its a bearer instrument and not a bar code tattoo!
>
>
>
>                  --
>                  There is a lot more low hanging fruit when you're tall.
>
>
>              --
>              =========================
>              --  Erik Ros           --
>              --+447979090626 <tel:%2B447979090626>  <tel:%2B447979090626>       --
>              --mail@erikros.me <mailto:mail@erikros.me>  <mailto:mail@erikros.me <mailto:mail@erikros.me>>     --
>              --http://erikros.me   --
>              --  @erikros_me        --
>              --  +ErikRos_ejfrme    --
>              =========================
>
>
>
>
Received on Sunday, 8 March 2015 08:00:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:23 UTC