+1.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http://www.abstractioneer.org/ /
@jpanzer
On Mon, Sep 27, 2010 at 11:25 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
(Please take a break from the other threads and read this with an open
mind. I have tried to make
it will
actually ACCEPT the data, it will be fine. MITM attackers can always
mis-route even signed messages of course, given that firewalls etc. are not
aware of signatures, so I don't see this as a distinction.)
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http
On Fri, Sep 24, 2010 at 9:06 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
Validating the signed data delivered with the request is as much magic as
the current 1.0 approach. Go write the validation rules and see.
Done that (for the specific case of Salmon). The only trick is to write the
to it, you may have issues. But I think you have issues under ALL
these proposals in that case.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http://www.abstractioneer.org/ /
@jpanzer
On Fri, Sep 24, 2010 at 9:20 AM, Richard L. Barnes rbar...@bbn.com wrote:
Maybe I've
around and I'd rather resolve that quickly.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http://www.abstractioneer.org/ /
@jpanzer
On Thu, Sep 23, 2010 at 6:43 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
Since much of this recent debate was done off list, I'd like to ask
for a JSONP extension spec
This might also result in much cleaner JSONP support.
regards,
Torsten.
Am 17.08.2010 um 09:28 schrieb John Panzer jpan...@google.com:
Except you cannot guarantee that result of course (proxies, apache
plus tomcat separate processes etc. will all result in error codes
(e.g. jsonp) to be inconsistent.
Authorization servers are simpler beasts.
--
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
support, an additional substitution of 2 characters.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http://www.abstractioneer.org/ /
@jpanzer
On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah n...@daaku.org wrote:
On Fri, Jun 25, 2010 at 11:39 AM, Breno breno.demedei...@gmail.comwrote
On Tue, Jun 22, 2010 at 2:36 AM, Ben Laurie b...@google.com wrote:
On 22 June 2010 07:03, David Recordon record...@gmail.com wrote:
Thanks for writing this. A few questions...
Do we need both `issuer` and `key_id`? Shouldn't we use `client_id`
instead at least for OAuth?
Can we write
So the thinking is that this is just a generic include or one level of
indirection feature that is orthogonal to other flows?
FWIW, I really like that notion. It's also very easy to describe and
understand conceptually.
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http
and it seems like services worried about this sort of risk would
not want to issue long lived access tokens.
--David
On Mon, May 10, 2010 at 10:39 PM, John Panzer jpan...@google.com wrote:
Yes; a service that does a one time configuration step, requiring
extensive access, followed
On Wed, Apr 7, 2010 at 10:46 PM, Evan Gilbert uid...@google.com wrote:
On Wed, Apr 7, 2010 at 9:29 AM, John Panzer jpan...@google.com wrote:
I'm assuming that tokens need not be bound to a specific user (typically
they are, but imagine a secretary granting an app access to his boss's
I'm confused by one pro for signatures:
Protect integrity of whole request - authorization data and payload when
communicating over unsecure channel
I do not believe there is an existing concrete proposal that will protect
the whole request, unless you add additional restrictions on the request
On Mon, Mar 8, 2010 at 5:38 AM, Torsten Lodderstedt tors...@lodderstedt.net
wrote:
...
1. Connection latency to bootstrap the connection (from the
asymmetric/public-key encryption operations)
Bootstrapping a SSL sessions is expensive. But every session can be
used for multiple
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo
James,
Thanks for the feedback.
+salmon-proto...@googlegroups.com
bcc:oauth@ietf.org bcc%3aoa...@ietf.org
--
John Panzer / Google
jpan...@google.com / abstractioneer.org http://www.abstractioneer.org/ /
@jpanzer
On Wed, Feb 10, 2010 at 10:59 PM, Manger, James H
james.h.man
).
It should have the PKCS#1 v1.5 block type 1 prefix (01 FF FF… 00
DigestInfo), making the value a similar size to the modulus.
Sorry for being picky ;)
--
James Manger
--
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
I think the question at hand is: If a server says it wants to do bearer
tokens and no TLS, is a client obligated to interop in order to claim spec
compliance?
--
John Panzer / Google
jpan...@google.com / abstractioneer.org / @jpanzer
On Fri, Jan 15, 2010 at 10:01 AM, Hurliman, John john.hurli
case?
--Richard
On Jan 15, 2010, at 1:29 PM, John Panzer wrote:
I think the question at hand is: If a server says it wants to do bearer
tokens and no TLS, is a client obligated to interop in order to claim spec
compliance?
--
John Panzer / Google
jpan...@google.com
20 matches
Mail list logo
