Sure, this makes sense to me. It's kind of analogous to the other two legged case where you have just a Consumer with a secret (provided through some out of band mechanism) that makes requests with empty strings for the user's secret.
On Fri, May 15, 2009 at 3:59 AM, Toby <[email protected]> wrote: > > Sure, I could have been clearer: I'm actually not concerned at all > here about the generation and distribution of tokens. > > That's a valid concern, and rightly the focus of much of the effort in > OAuth. But what I'm trying to consider is a situation where that's not > an issue. Imagine that I as the Service Provider have entirely solved > the problem of granting Access Tokens to my satisfaction, outside of > OAuth; maybe I print them out on a bit of paper and cycle down the > road to hand them out to my Users. There's no meaningful Consumer in > the loop here. > > Given that that's the case, how can I best use these Access Tokens, > within the OAuth framework, to let my Users make requests of my > Service? > > What I'm suggesting is that if I invent a Consumer whose key and > secret are both the empty string, then my Users (in possession of an > Access Token which I cycled down to give them) can make requests over > https as described in my previous method; without worrying about > constructing signatures, with a minimum of things to remember. > Essentially, they can do simple string substitution into a OAuth > header template, to generate valid OAuth-authenticated requests to my > service. > > This makes their life much easier in terms of writing simple throw- > away scripts against my service. > > I could get the same effect from using HTTP Basic with opaque tokens > for usernames (and, indeed, this is what I do at the moment in > reality) - I'm wondering if this could be done within OAuth > authentication. > > Does this make my point clearer? > > Toby > > On May 15, 8:20 am, Manish Pandit <[email protected]> wrote: > > On May 14, 8:37 am, Toby <[email protected]> wrote: > > > > > > > > > I'm thinking about simplified OAuth setups, minimizing the load on the > > > client, in situations where the Consumer is not a terribly meaningful > > > concept - where there is a Service, and Users who interact directly > > > with the service (by, for example, typing in curl commands at a shell > > > interface). This is the problem addressed by HTTP Auth, of course, but > > > I want to see if I can make this work within the OAuth framework. > > > > > I'm aware of "Using OAuth for Consumer Requests" > http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/... > > > but I'm trying to approach it from a different perspective. > > > > > Reading the OAuth spec literally, I see nothing which requires the > > > Consumer Key & Secret to be non-empty strings. If I let these be empty > > > strings, then this makes construction of OAuth requests much simpler. > > > > > What I'm envisaging is registering one such Consumer on my service, > > > and letting Users create Tokens on the back of this Consumer, for use > > > in their own use-once-and-throw-away scripts. If I restrict access to > > > only come through https urls, then I can ignore all signature methods > > > other than PLAINTEXT. > > > > > This reduces OAuth authentication to a single HTTP header, looking > > > like: > > > > > Authorization: OAuth > > > > oauth_consumer_key="",oauth_token="tokenstring",oauth_signature_method="PLA > INTEXT",oauth_signature="&secretstring",oauth_timestamp="1000000000",oauth_ > nonce="random" > > > > > which is trivially easy to construct, and can be typed in as a command- > > > line option to curl. > > > > > Essentially, this would work like API tokens a la Flickr, but using > > > the OAuth authentication framework. > > > > > To place it in the context of "Using OAuth for Consumer Requests" > > > above, this lets you retain the existing three-legged framework, while > > > essentially ignoring one of the legs, without (as best I can tell) > > > needing to extend the spec, or rewrite libraries. > > > > > For what it's worth, I've managed to get this working with curl > > > talking to an unpatched version of the Python OAuth library > > > > > Does this make sense, or am I barking up the wrong tree? > > > > > Toby > > > > Not sure if I understand - are you saying that instead of a provider > > generating the tokens and secrets for the consumers, the end users > > will create their own tokens and secrets? Can you explain your use > > case a little further? > > > > -cheers, > > Manish > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
