Hi Marius,
Thank you very much for your detailed reading of the paper
and your very useful comments. I've revised the paper based
on your comments and put a new version online, with an
acknowledgment of your contribution.
> PKAuth seems similar to OAuth 2, I think it would help if you used the s
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, w
This expiration time is just a hint, client code should work perfectly
fine without it, or with a wrong one.
Trying to understand the use case here: JavaScript code receives an
access token and the associated expires_in. It passes the access token
to backend code, and this backend code is properly
You can't access it from JavaScript in most use-cases unfortunately. It's why
having both expires_in and expires_at would be nice.
On 23 déc. 2010, at 11:36, "Pelle Wessman"
mailto:pe...@kodfabrik.se>> wrote:
For the Web Server flow you will have a HTTP Date header containing the
timestamp at
For the Web Server flow you will have a HTTP Date header containing the
timestamp at which the token was generated - right? Combining the value of
that header with expires_in will get you the value of expires_at.
/ Pelle
On Tue, Dec 14, 2010 at 10:14 PM, Paul Walker wrote:
> Has there been disc
