AM
>> To: Eran Hammer-Lahav
>> Cc: Brian Eaton; Ethan Jewett; OAuth WG
>> Subject: Re: [OAUTH-WG] Thinking about our secrets for signatures
>>
>> An interesting question is, who decides what kind of token to issue? 1) Is it
>> the authorization server beca
Possibly this is a silly question, but why not #2 and have the bearer
token method (over SSL of course) include the token secret? The
provider would always issue a token and a token secret. If the client
is not interested in signing methods, it can discard the token and
keep the token secret. This
On Fri, Mar 19, 2010 at 6:21 PM, Brian Eaton wrote:
>
> The gadget tells the container *where* to send the request. So if
> OpenSocial gadgets supported PLAINTEXT, a malicious gadget author, or
> a malicious user of a gadget (they are pure javascript) could tell the
> container "please send a req
Accidentally sent the following directly to Brian instead of the list.
I'll try again
On Fri, Mar 19, 2010 at 2:44 PM, Brian Eaton wrote:
> Plaintext doesn't work in this context, because it sends long-lived
> secrets in clear-text to servers that are under the control of the
> application a
On Fri, Mar 19, 2010 at 2:45 PM, Brian Eaton wrote:
>
> Ah, the other reason plaintext doesn't work is because one of the
> goals is to guarantee the integrity of the identity information passed
> in the request - neither the application author nor the viewer of the
> application is permitted to t
I think 4.5 should read "iLike gadget can choose to sign request with
MySpace's private key or with a shared secret between iLike &
MySpace."
If I'm reading correctly, if the gadget chooses to use the container's
private key, then that is making use of the RSA signature mechanism.
If the gadget ch
Thanks Thorsten, this is good.
The "Pro Signature" section seemed a little thin to me (pro HTTPS too,
though most security pros are included obliquely in the "Powerful"
bullet). I changed the "Pro Signature" section to:
* Low latency and computational costs (HMAC)
* Provides for authentication
Agreed. I've heard tell of Yahoo access tokens with encoded
information weighing in at up to 800 characters. I don't see anything
necessarily wrong with this and I don't think there's much reason to
limit it in the spec. It could incur a significant bandwidth cost, but
since the provider is going t
>>> >> contract,
>>> >> and only when opening a web browser is not feasible or desirable. We
>>> >> strongly discourage apps from using this profile, and it's unlikely
>>> >> that
>>> >> it'll ever be a pub
On Sun, Mar 7, 2010 at 10:25 PM, Allen Tom wrote:
> This is why the username/password profile is intended for rich client apps,
> where invoking a browser is not feasible. Given that the user already
> downloaded and installed the rich app, popping open a browser is not going
> to protect the user
I'm glad I managed to prompt some discussion on the topic!
In order to avoid responding to several individual messages in this
thread, I'll compile points:
Use cases: The request was for use cases where signatures a la OAuth
1.0a might be required. I've tried to provide some, along with
reasoning
secure approach for authentication over an insecure channel
(OAuth 1.0a signing) and replacing it with a less secure approach
(bearer tokens w/o SSL/TLS).
Ethan
On Sun, Mar 7, 2010 at 1:40 PM, John Kemp wrote:
> On Mar 7, 2010, at 12:24 PM, Ethan Jewett wrote:
>
> [...]
>
>>
Thanks for your comments. I'm mostly interested in watching the
discussion unfold, but there are a couple of things to add:
On Sun, Mar 7, 2010 at 1:23 PM, John Panzer wrote:
> You can make the token short-lived if this is a concern. (Short lived
> meaning minutes.) And presumably the user is
Before I get started, let me say that this should be taken with a very
large grain of salt. I am not a technical expert in these areas. I've
only done a fair amount of reading and following along with standards
efforts. Conclusions here should be questioned thoroughly and
corrected as necessary, bu
On Thu, Feb 18, 2010 at 11:14 AM, Eran Hammer-Lahav wrote:
> A few questions we should answer before moving forward. Considering *your*
> use cases and reasons for being here:
>
> 1. Why are you here? What are you trying to solve that is not already
> addressed by existing specifications (OAuth
15 matches
Mail list logo
