Hi Francisco, PKAuth seems similar to OAuth 2, I think it would help if you used the same terminology: - application => client - social site => authorization server - client => end user - reference code => authorization code
The paper claims that users do not know how to interpret domain names, which is probably true. Is there any evidence that users are doing better with names as found in SSL certificates? Discovery is based on link tags in HTML pages, did you consider using /.well-known/host-meta instead? At step 1, the difference between official-name and alternative-name can only be "www.". Why not just follow redirects? Not sure I understand why the reference code must be generated by the social site, how would session fixation work if it was generated by the application? The social site most likely has a large number of API endpoints, providing only one pkauth-subsequent-access does not scale. Or maybe I misunderstood the purpose of pkauth-subsequent-access. PKAuth would work only for web applications and compared to OAuth 2 it raises the bar for them: they need an SSL cert and also an API endpoint. Especially web app only, is a very strong limitation. Marius On Wed, Dec 22, 2010 at 9:57 AM, Francisco Corella <fcore...@pomcor.com>wrote: > Hi all, > > OAuth provides only weak security when used with > unregistered applications. OTOH compulsory registration is > a bad idea: imagine a situation where a social site becomes > dominant, social login via that site becomes the de facto > authentication standard on the Web, every application has to > register with the site, and the site can kill any > application by revoking its registration. I've written a > paper <http://www.pomcor.com/whitepapers/PKAuth.pdf> that proposes a > solution. Thanks in advance for any > comments. > > -- Francisco > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
