-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 2, 2009 at 9:20 AM, Hans Granqvist
wrote:
>
> It's a trade-off I am sure, but I would have loved it if the
> standard had
> decoupled the token issuer from the token verifier. In that way,
> you would
> not need the dance of triage
On Mon, Feb 2, 2009 at 9:20 AM, Hans Granqvist wrote:
>
> > The reasoning behind this is that while "scope" is a common approach,
> > it's not the only approach. For example, I may want to simply limit
> > access to "read-only/write-only/read-write", or maybe (e.g., for
> > academic article datab
> The reasoning behind this is that while "scope" is a common approach,
> it's not the only approach. For example, I may want to simply limit
> access to "read-only/write-only/read-write", or maybe (e.g., for
> academic article databases) "link/abstract/full article", or any
> number of other poss
I see. Which resources are accesible and which are not are part of an
offline agreement between Service Provider and User, and hence are out
of the scope of the spec. And I agree with your reasoning about the
temporal states.
Thanks a lot to all of you, you've helped me a lot. Greetings,
Jorgi
On Mon, Feb 2, 2009 at 9:23 AM, Jorgito
wrote:
>
> Krishna: that's exactly what I mean, granularity in time and
> granularity in the space of resources. The granularity in time is
> already implemented in OAuth, but the granularity in resources...
> maybe it's implicit in some field of some messa
Indeed, the draft of Scalable OAuth takes to account the problem of
giving access to concrete resources at the Service Provider, as well
as other problems I had detected such as token revocation and renewal.
Thank you very much to all of you who have tried to help me :-)
Jorgito
--~--~
Hi Krishna and Praveen. Sorry for the delay, but during weekends I
don't have Internet connection.
Krishna: that's exactly what I mean, granularity in time and
granularity in the space of resources. The granularity in time is
already implemented in OAuth, but the granularity in resources...
may
eers
>
>
> |-Original Message-
> |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> |Of Jorgito
> |Sent: Friday, January 30, 2009 7:08 AM
> |To: OAuth
> |Subject: [oauth] Re: Distinction between Request Token and Access token
> |
> |
>
|-Original Message-
|From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
|Of Jorgito
|Sent: Friday, January 30, 2009 7:08 AM
|To: OAuth
|Subject: [oauth] Re: Distinction between Request Token and Access token
|
|
|Thank you both for your fast replies.
|
|Indeed, I was wrong
I'm not sure I completely understand, but what resources (and how
many) that you can access with an authorized token are outside the
spec.
OAuth is a generic method for protecting resources; it's up to you to
determine what, and for how long, you make those resources available.
Chris
On 1/30/09
Thank you both for your fast replies.
Indeed, I was wrong when I said that the distinction between both
tokens would dramatically increase the response time. I misunderstood
the spec, as I thought that one pair Request Token -- Access Token
only granted access to one protected resource (namely, o
Jorgito wrote:
>
> Hi! I'm new to this group. I am very grateful for the possibility it
> brings me to ask questions, so thanks in advance ;)
>
> Reading the spec of OAuth there's something whose motivation I can't
> understand. Why distinguishing between a Request Token first, and an
> Access
Ordinarily, a consumer would get one access token and use it to access
the thousand protected resources. OAuth would add very little to the
resource response time.
On Jan 26, 3:37 am, Jorgito wrote:
> Reading the spec of OAuth there's something whose motivation I can't
> understand. Why disti
13 matches
Mail list logo
