Option 3.
Cheers
k/
|-Original Message-
|From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
|Of Blaine Cook
|Sent: Friday, May 01, 2009 1:25 AM
|To: oauth@googlegroups.com
|Subject: [oauth] Version Preference
|
|
|We need to build some consensus around the version
My first cut at an outline draft - attached to my blog
http://doubleclix.wordpress.com/2009/04/03/oauth-header-hash/ Naturally
leveraged Brian's body hash spec figuratively and literally.
There is lot of work to be done from formatting to processing model to
examples and running code. Also need
I will byte ;o)
@all, I am thinking of developing a header integrity proposal - a header hash
taking lead from Brian's body hash.
First, is there anybody attempting this ? I am sure Brian is not.
Second, while I think this is inevitable - one form or another, I also do not
want to rush in.
Eran,
Excellent write-up. Couple of quick points:
a) Instead of another easy-to-read specification document
of some kind, might be easier to write an OAuth Primer (similar to what
W3C does). The document can have a section on Lessons learned from
implementations. Naturally
The agent is a overused term and we still need to differentiate between the
service provider and the service aggregator.
What about service originator, service provider/cloud provider/service
aggregator and service consumer ? Or some version of it. Then we can talk about
SO Key or SP key or
Hi,
IMHO, you should raise this in the IETF list as it pertains to the
charter. I think this is an important topic.
Cheers
k/
|-Original Message-
|From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
|Of Onyx Raven
|Sent: Monday, February 02, 2009 11:16 AM
|To:
token. It changes state in the service
|provider, so the service provider associates authority (permission)
|with the request token.
|
|On Jan 31, 3:07 pm, Krishna Sankar (ksankar) ksan...@cisco.com
|wrote:
| I thought they *need not* be the same - because a service
| provider could conceivably
Joe,
What you are looking for is something *loosely* like a
cookie. No, OAuth does not have that type of feature. As you might well
know, usually this is done via client side cookies or plain login. Most
probably, I am missing something - maybe we can explore further if we
know
: [opensocial-and-gadgets-spec] Re: body signing for
|oauth and opensocial
|
|
|On Wed, Dec 10, 2008 at 11:30 PM, Krishna Sankar (ksankar)
|ksan...@cisco.com wrote:
|Why can't we make it binary - just say header-signature-
|required
| or header-signature-not-required. And if required, sign all
-spec] Re: body signing for oauth and
| opensocial
|
|
|
| On Wed, Dec 10, 2008 at 3:30 PM, Krishna Sankar (ksankar)
| ksan...@cisco.com wrote:
|
| Brian,
|Now that we have beaten you to submission ;o), I think it
| becomes complex by requiring arbitrary named headers to be signed
10 matches
Mail list logo
