On Sun, May 16, 2010 at 11:27 AM, Dick Hardt wrote:
> Torsten: enabling a client to revoke a refresh token looks like a useful
> mechanism. I anticipate it will be viewed as a vitamin feature rather than a
> painkiller and will fall by the wayside unless the security conscience rally
> to have it
Dirk,
A good approach would be to define a generic mechanism (say "MAC") for signing
a request with a secret key. Define it to take two identities: an identity
associated with the key (authentication identity); and another (~identity to
act as / authorization identity / token). This mechanism n
Hi Dirk-
We at Yahoo would be very much against using the client secret for signing
requests to Protected Resources, since this would require that the client
secret be distributed to the PR endpoints. For security reasons, one of the
design goals for WRAP was to keep the client secret a secret bet
Marius,
>> I wouldn't be surprised if, in some scenarios, the token info gets too big
>> to fit in a URI. In that case even the user-agent flow will need to make a
>> direct request to get the token info, which is more likely to be delivered
>> as JSON. OpenID and SAML have found they need thi
We're able to use the client secret for signing requests instead of a token
secret, but my understanding is that this exists because of deployers who do
not wish for their protected resources to have access to client secrets.
--David
On Thu, May 20, 2010 at 4:39 PM, Dirk Balfanz wrote:
> Hi gu
Hi guys,
at today's interim meeting, we were discussing Brian Eaton's proposal for
OAuth signatures. He was proposing a mechanism that would (1) do away with
base string canonicalization, (2) allow for symmetric and public keys, and
(3) allow for extensibility.
He got homework from the group to p
At the IETF 77 the need for documenting the OAuth use cases was discussed and I
volunteered writing a draft. The draft has been published at
http://www.ietf.org/id/draft-zeltsan-use-cases-oauth-00.txt.
At today's interim meeting its presentation did not generate any controversy.
Please provide yo
I was reading through the spec and had some questions about 3.2 and 3.3 that I
list below.
Thanks,
Yaron
Section 3.2/3.3 - Handling requests without supported transport layer security
Although optional in section 3.2 and mandatory in section 3.3 bot
For extra readability can we add titles to the figures in the Internet-
Drafts? I think it would make it easier to skim sections, such as the
various flows.
Here are my suggestions for titles for draft-ietf-oauth-v2-05:
Figure 1 - Generic flow between client and server
Figure 2 - Obtaining a
This is a link to the draft on the use cases that I presented at today's
meeting.
http://www.ietf.org/id/draft-zeltsan-use-cases-oauth-00.txt
Zachary
-Original Message-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org]
Sent: Tuesday, May 18, 2010 2:07 AM
To: Zeltsan, Zachary
Yes. The user is delegating access to the browser.
EHL
On 5/20/10 9:05 AM, "Dick Hardt" wrote:
The image can be protected by both. Do you expect OAuth to be used with user
present in the browser?
On 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote:
Why can't an image be protected with both
On Wed, May 19, 2010 at 6:33 PM, Manger, James H
wrote:
> Marius,
>
>> Only direct responses are JSON, form/url encoded
>> still has to be used:
>> - direct requests
>> - through browser requests
>> - through browser responses
>> - through browser fragment responses
>
> A better solution would be
The image can be protected by both. Do you expect OAuth to be used with user
present in the browser?
On 2010-05-17, at 11:20 PM, Eran Hammer-Lahav wrote:
> Why can’t an image be protected with both Basic and OAuth? In this case the
> browser is the OAuth client.
>
> EHL
>
> From: Dick Hardt
Note: it takes us a bit to get setup here in the meeting venue but in
any case here is the info for the remote participants
Jabber: oa...@jabber.ietf.org
Webex:
> From: messen...@webex.com
> Date: May 19, 2010 10:05:03 AM PDT
> To: amor...@amsl.com
> Subject: Meeting scheduled: OAuth Interim M
On Wed, May 19, 2010 at 6:33 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:
> Marius,
>
> > Only direct responses are JSON, form/url encoded
> > still has to be used:
> > - direct requests
> > - through browser requests
> > - through browser responses
> > - through browser fragment
15 matches
Mail list logo
