- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Sun, 22 Nov 2015 17:03:02 -0500
- To: David Chadwick <d.w.chadwick@kent.ac.uk>, Anders Rundgren <anders.rundgren.net@gmail.com>, public-credentials@w3.org
On 11/22/2015 12:53 PM, David Chadwick wrote: > > > On 22/11/2015 16:33, Anders Rundgren wrote: >> On 2015-11-22 17:10, David Chadwick wrote: >>> Hi Anders >> >> Hi David, >> >> <snip> >> >>>>> The user sends the consumer SOP public key to the issuer and >>>>> the issuer assigns the attribute to that. >>>> >>>> I think you lost me here, at least with respect to the NASCAR >>>> problem. >>> >>> This is because the user does not go to any third party to >>> authenticate to a site. A new key pair is generated for the >>> site, and this authenticates the user each time he calls. Note >>> however that FIDO does not provide any identity or authz >>> information, just an authn key, which is why we need to add this >>> functionality using issuers. >> >> It is this sending of the consumer public key to issuer by the >> user which I don't quite understand :( > > The user can prove possession of all the public keys his device has > issued. This is how he authenticates. The consumer only knows it is > the user at the other end of the connection because a challenge from > the consumer was signed by the private key corresponding to the > user's consumer public key. > > Now if the consumer receives an attribute signed by an issuer, it > proves that the issuer issued it, but not who it belongs it. By > using the consumer public key as the ID of the user, the consumer now > knows that the user it has authenticated is the righful owner of the > attributes. This makes perfect sense to me, though I'm not sure if there are any restrictions in the current/prospective APIs or FIDO designs for sharing one origin's key with another origin. I mainly worry about the fact that you're sharing how you identify with every consumer out there with the issuer (and that issuers need to provide highly-available services to ensure you can give them this information in exchange for a credential). I understand that additional tracking information is required for an issuer to link the opaque identifier they are given to the consumer, but I'm uneasy about increasing the attack surface area in this way *for every credential exchange*. As I said in another mail, I'd rather see this option layered on top of a less intrusive core sharing protocol. I do think there are some very valuable ideas here that we could integrate and layer on top of the work we've been doing in the Credentials CG and I'm happy you're sharing this information with us! -- Dave Longley CTO Digital Bazaar, Inc.
Received on Sunday, 22 November 2015 22:03:28 UTC