On 2015-02-03 12:34, Rigo Wenning wrote:
Rigo,
Although I agree with what you are saying there's a problem:
None of the stuff you are referring to has ever been directly connected
to the [UNTRUSTED] web, they are always used with a trusted App + GU.
This component and thinking is entirely absent from all proposals submitted to
date.
Anders
--trimming CC
On Tuesday 03 February 2015 2:53:59 Ryan Sleevi wrote:
I know of zero eID schemes that properly preserve privacy - and that is
including PIV's notion of derived credentials - and so if the question is
"Can we bring these, as-is, to the web", then the answer is and should be a
resounding no.
Ryan,
privacy is the wrong argument here:
1/ paying using eID is as private as paying with a credit card
2/ my ID-card eID can be used in many ways, including trigger anon-credentials
using double-blind sigs (Camenisch et.al), which are privacy preserving
3/ you emit a reserve with "as-is" but you remain unclear how far of a bridge
is needed to overcome the "as-is" and who should build that bridge.
I think eID schemes are not made for privacy, they are used within an
environment that is more or less privacy preserving (e.g. EU regulation). So
the privacy argument has nothing to do with webcrypto. eID schemes may not fit
your use case, but eGov e.g. is a use case where I have to be identified but I
also want to be secure and use webcrypto in my browser to have end-to-end
security.
Finally, after years of privacy work, I think most of the meat is in data
collection limitation and data retention times. So if you throw away the eID
after 24 hours, I don't think there is much of a privacy issue. But that's not
for webcrypto to specify.
My question was rather whether the webcrypto system can improve security of
systems like the Estonian eID scheme where everyone has an eID, can vote, do
all administrative actions etc. It can only do so if the API is open enough to
also connect to those systems. Will the web remain relevant for them or will
they have to create some "App" to connect to their eID system?
Because this cuts both ways. If the API is open enough to consume more than
one smartcard/crypto system, it also creates pressure for the eID system to
evolve towards fully catering to the web. If you have to necessarily pass by
FIDO first, I think this would be much more difficult (although not
impossible)
Let me finish by my most favored phrase from Peter Brown (Board of OASIS) who
said: "Standards are great, please use mine". We shouldn't fall into that
trap. We should be as inclusive as possible without breaking things IMHO.
--Rigo
