- From: <Joerg.Heuer@telekom.de>
- Date: Thu, 28 May 2015 10:31:31 +0200
- To: <adrian@hopebailie.com>, <dsr@w3.org>
- CC: <eanders@pobox.com>, <public-webpayments-ig@w3.org>
- Message-ID: <FB5E170315856249A4C381355C027E4502912D033E0C@HE100041.emea1.cds.t-internal.com>
… I have the habit of saying that the main aspect of authenticating an authorized user today is a written contract saying the subject will receive (or be able to define) a password, PIN or the alike for his/ her personal use only. Basically saying ‘you are responsible if you don’t keep the secret to yourself!’ It’s not technology, it’s a contract. With biometry we can now make sure that it really is the same person who registered. But this is exactly the point here: enrolment determines whether you want to tie authentication to a person or not – if you are allowed to, and whether you have a right or an interest to know who the person really is. For privacy reasons we should always ask for the least identifying procedure that still makes sense, but always allow for better security – more identification – being established, and of course for the appropriate security technology. What we shouldn’t ask for IMO is, an identity of a person having to be established mandatorily, or high security being required, while the risks can be borne by a business that e.g. lives from low entrance barriers and mitigates fraud as long as they don’t harm the user. So my fivepence are: - Don’t require personal authentication, but make sure it can be done properly - Allow for PKI and the alike, but make sure, there’s no other way without the deployment trouble which might be sufficient for some businesses as long as users don’t get harmed Cheers, Jörg From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com] Sent: Donnerstag, 28. Mai 2015 07:40 To: Dave Raggett Cc: Erik Anderson; Web Payments IG Subject: Re: [identity-credentials] Clarity of definitions: Credentials, unbound identity, identity hardening, and bound identity On 27 May 2015 at 20:14, Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>> wrote: On 27 May 2015, at 15:28, Adrian Hope-Bailie <adrian@hopebailie.com<mailto:adrian@hopebailie.com>> wrote: To harden this identity we must "tie it to reality". The problem is, anyone with the document in Example3 can present it and claim to be the subject of that document. In order to harden this identity we require a way for the holder to prove they are also the subject. This can be achieved through technology by having biometric data in the document that can be verified by the consumer or the presenter must be able to sign a challenge with one of the keys used to sign the document or.... some other mechanism. I am not suggesting this is a requirement. These are just examples. The challenge with simply having a document that contains real-world attributes is that anyone can attest to being the subject of the document, even if the document itself is signed. I would define hardening as a means to prove that the holder of the identity is also the subject of the identity. Without biometrics, I agree that one needs some PKI based solutions where the holder can prove they are the subject. I would imagine the easiest way to do this is for the holder to prove they have a secret that was defined when the identity was first compiled and signed by a trusted authority that attests to the connection between the content of the identity and the real-world entity. The requirement to embed biometric data isn’t obvious to me. I would instead expect that we would have assertions about identities, e.g. a web identity used in a transaction and based upon an ecliptic curve key pair that applies to the {user, device, account} combo. This could be tied to a real world identity with attributes such as full name, address, data of birth, financial institution, account number etc. Essentially, KYC is addressed through a certificate that ties a web identity to a real world identity. Privacy considerations might weaken this to allow for a deferred binding that is only revealed upon a court order / legal proceedings. — Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>
Received on Thursday, 28 May 2015 08:32:06 UTC