- From: David Chadwick <d.w.chadwick@kent.ac.uk>
- Date: Mon, 23 Nov 2015 22:30:03 +0000
- To: Anders Rundgren <anders.rundgren.net@gmail.com>, public-credentials@w3.org
the user has multiple key pairs, one pair for every web site he visits. I called the user's key pair for the consumer site, the consumer SOP public key (not to be confused with the consumer's own X.509 SSL key pair). Is it clearer now? On 23/11/2015 20:51, Anders Rundgren wrote: > Hi David, > This statement of yours is the only thing I don't get: > > "The user sends the consumer SOP public key to the issuer and > the issuer assigns the attribute to that" > > How does the user send the consumer SOP public key to the issuer? > > Regards, > Anders > > On 2015-11-23 21:21, David Chadwick wrote: >> >> >> On 23/11/2015 18:14, Anders Rundgren wrote: >>> On 2015-11-23 17:47, David Chadwick wrote: >>>> >>> <snip> >>>>> Agreed. I was actually referring to "my model" where key metadata >>>>> plays a >>>>> major role. A scaled-down version of this can be found in this >>>>> one-page >>>>> doc: >>>>> http://webpki.org/papers/decentralized-payments.pdf >>>>> The certificate could surely be replaced by an account-ID, but I'm >>>>> old-school you know :-) >>>>> >>>> >>>> Your model is similar to mine, but is dealing with a step after mine >>>> has >>>> completed. >>> >>> To me they look pretty different. There's no "before-step" in my model. >>> >>> When you have received your virtual credit-card, you can start shopping >>> wherever you want. >>> >>>> Mine deals with presenting a credentail/assertion, then >>>> stops. FIDO already has a process for OKing a transaction. >>>> Comparing our models, your wallet is my authz module, your cert is >>>> replaced by a FIDO key pair, so no identity is associated with the >>>> public key. >>> >>> I still don't understand how your (per/site) credential bootstrap >>> process works from a users perspective. >> >> That is the registration process. There are multiple ways of achieving >> this >> i) turn up in person - easy if the issuer is your employer or club >> ii) send an activation code in the post to the users home >> iii) use a set of registration authorities like banks or post offices >> etc. >> Everybody today has to register for all their credentials: passports, >> driving licenses, credit cards, rail cards, bus passes etc etc. They are >> all tedious processes but essential to stop fraud since this is usually >> the easiest place to crack. >> >> regards >> >> David >> >>> >>>> The web site sends its authz policy to the wallet/authz module and it >>>> compares this to the credentials held by the user. It either presents >>>> matching ones for the user to choose between (more than one match) or >>>> consent to (exactly one match) or say Sorry you cannot proceed >>>> (insufficient credentials). >>> >>> I think I have got that. >>> >>> Regards, >>> Anders >>> >>>> >>>> regards >>>> >>>> David >>>>> >>>>>> Usability is always hard to get right, but we have experimented >>>>>> with a >>>>>> GUI for over a year and think it is intuitive and easy to use. >>>>> >>>>> *This* is the thing I'm Interested in. How is the consumer key >>>>> sent to >>>>> the issuer from a user perspective? >>>>> >>>>> >>>>>> I am not aware of any additional security issues with this scheme >>>>>> that >>>>>> are not always present when users and technology are involved. >>>>> >>>>> You're probably right :-) >>>>> >>>>> Regards >>>>> Anders >>>>>> >>>>>> regards >>>>>> >>>>>> David >>>>>>> >>>>>>> Regards >>>>>>> Anders >>>>>>> >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> David >>>>>>>>> >>>>>>>>> Anders >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > >
Received on Monday, 23 November 2015 22:30:08 UTC