Makes perfect sense as we have the same model for our clients tokens:)
The one use case we've encountered is that this model revokes the tokens
for all clients with the same client_id. So if I've got three of the
same client installed (on three computers) and they likely all have the
same
Am 11.06.2010 16:38, schrieb George Fletcher:
Makes perfect sense as we have the same model for our clients tokens:)
The one use case we've encountered is that this model revokes the
tokens for all clients with the same client_id. So if I've got three
of the same client installed (on three
Along these lines, I'd like to propose an extension for per-client
instance information to be passed from a client to the server. Things
like a human-readable client name/description, instance name/description
(could be tied to host name, ip, label like home or Work), and even
something like a
Hi!
Am 11.06.10 17:05, schrieb Justin Richer:
Along these lines, I'd like to propose an extension for per-client
instance information to be passed from a client to the server. Things
like a human-readable client name/description, instance name/description
(could be tied to host name, ip,
+1 for dynamic registration
On 6/11/10 11:35 AM, Christian Scholz wrote:
Hi!
Am 11.06.10 17:05, schrieb Justin Richer:
Along these lines, I'd like to propose an extension for per-client
instance information to be passed from a client to the server. Things
like a human-readable client
One missing point from this is that the same client ID could be used for
different instances for the same user. That's how google's
xoauth_display_name was used, and that's what I'm proposing as an
extension to the capability below. Unregistered clients are a separate,
but slightly related, issue,
On Fri, Jun 11, 2010 at 8:35 AM, Christian Scholz c...@comlounge.net wrote:
Hi!
Am 11.06.10 17:05, schrieb Justin Richer:
Along these lines, I'd like to propose an extension for per-client
instance information to be passed from a client to the server. Things
like a human-readable client
That sounds like a security consideration to me! :)
I imagine that authorization servers will verify ownership in
different manners depending on their tolerance of risk.
On Fri, Jun 11, 2010 at 8:54 AM, Marius Scurtescu mscurte...@google.com wrote:
On Fri, Jun 11, 2010 at 8:35 AM, Christian
On Fri, Jun 11, 2010 at 8:59 AM, David Recordon record...@gmail.com wrote:
That sounds like a security consideration to me! :)
I imagine that authorization servers will verify ownership in
different manners depending on their tolerance of risk.
Instead of POSTing a JSON with all the details,
On Fri, Jun 11, 2010 at 9:25 AM, George Fletcher gffle...@aol.com wrote:
On 6/11/10 12:07 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 8:59 AM, David Recordonrecord...@gmail.com
wrote:
That sounds like a security consideration to me! :)
I imagine that authorization servers will
On 6/11/10 12:34 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 9:25 AM, George Fletchergffle...@aol.com wrote:
On 6/11/10 12:07 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 8:59 AM, David Recordonrecord...@gmail.com
wrote:
That sounds like a security
Client doesn't need to *be* a web server, just *have* a web server available.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of George Fletcher
Sent: Friday, June 11, 2010 9:25 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] User-agent
On Fri, Jun 11, 2010 at 10:07 AM, George Fletcher gffle...@aol.com wrote:
On 6/11/10 12:34 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 9:25 AM, George Fletchergffle...@aol.com wrote:
On 6/11/10 12:07 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 8:59 AM, David
On 6/11/10 2:09 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 10:07 AM, George Fletchergffle...@aol.com wrote:
On 6/11/10 12:34 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 9:25 AM, George Fletchergffle...@aol.comwrote:
On 6/11/10 12:07 PM, Marius
On Fri, Jun 11, 2010 at 11:46 AM, George Fletcher gffle...@aol.com wrote:
On 6/11/10 2:09 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 10:07 AM, George Fletchergffle...@aol.com
wrote:
On 6/11/10 12:34 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 9:25 AM, George
On 6/11/10 3:15 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 11:46 AM, George Fletchergffle...@aol.com wrote:
On 6/11/10 2:09 PM, Marius Scurtescu wrote:
On Fri, Jun 11, 2010 at 10:07 AM, George Fletchergffle...@aol.com
wrote:
Well... given this is a POST and
Thanks Marius.
I've answered your question below.
On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu mscurte...@google.comwrote:
I've always considered an authorization as a tuple of
client_id,user,scope,issue_date. If an authorization has been approved,
and
another request for
On Thu, Jun 10, 2010 at 8:35 AM, Andrew Arnott andrewarn...@gmail.com wrote:
Thanks Marius.
I've answered your question below.
On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu mscurte...@google.com
wrote:
I've always considered an authorization as a tuple of
Andrew, Marius,
Comments in-line.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Marius Scurtescu
Sent: Thursday, June 10, 2010 1:35 PM
To: Andrew Arnott
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] User-agent flow and pre-registered
Hi Thomas,
Some responses inline...
On Thu, Jun 10, 2010 at 1:27 PM, Thomas Hardjono hardj...@mit.edu wrote:
The issue_date enables to scenarios: expiring tokens and token
revocation.
Here's how, for each scenario:
Obviously to know if a token has expired you need to know when it
Marius,
You seem to be coming from the perspective that the auth server stores
authorizations (that would eliminate the need for the user to interactively
approve an authorization) based on redirect_url rather than client_id. Is
that right?
I've always considered an authorization as a tuple of
Thanks - I get your line of reasoning now. I believe it would still help in
preventing certain types of attack. These are especially apparent around
immediate.
1) User initially grants access to example.com
2) User goes to an evil site
3) Without the user's knowledge, the malicious site
Rick, ...
On Sat, Jun 5, 2010 at 12:45 PM, Rick Olson technowee...@gmail.com wrote:
How else are you preregistered with the auth server?
I don't understand the question, sorry.
Why can't you
just return the temporary code and rely on the JS or Desktop app to
make another call to get the
On Fri, Jun 4, 2010 at 9:49 PM, Andrew Arnott andrewarn...@gmail.com wrote:
The user agent flow indicates that the redirect_uri SHOULD be preregistered
with the auth server for a given client. I would like to suggest that the
SHOULD here be changed to MUST. Unless I'm missing something,
You are pointing out Marius point -- he wants to require registration. If the
redirect_uri is not registered, the only party that can detect that it is the
right URI is the user. The AS can only show the user the redirect_uri passed
over.
-- Dick
On 2010-06-07, at 5:31 PM, Chuck Mortimore
25 matches
Mail list logo
