By not feasible, what is the technical use case/issue?
Phil
Sent from my phone.
On 2011-04-01, at 21:52, Skylar Woodward wrote:
> Am I the only one still supporting SHOULD on this case? If someone else
> supports this language, please speak up. Otherwise, it seems the group SHOULD
> move f
Am I the only one still supporting SHOULD on this case? If someone else
supports this language, please speak up. Otherwise, it seems the group SHOULD
move forward with MUST.
As a provider, we (Kiva) must deal with the possibility of an ecosystem of
developer apps which can't feasibly serve HTTP
Sorry. I forgot to add it becomes a race if and only if the TS is smart enough
to invalidate code after first use.
Phil
Sent from my phone.
On 2011-04-01, at 18:07, Skylar Woodward wrote:
> I'm going to summarize (hopefully faithfully) the attacks referenced here,
> with the hope of attemp
I'm going to summarize (hopefully faithfully) the attacks referenced here, with
the hope of attempting to sum up the scope of attacks being documented.
On Apr 1, 2011, at 1:29 PM, Francisco Corella wrote:
> Skylar,
>
> > Right, but just so we are clear, the only case you are
> > discussing here
We ran out of time in the working group meeting to consider the JWT profile in
any depth. I pointed out that it was intentionally very parallel to the SAML
profile and asked people to review it toward the goal of making it a working
group document.
Cheers,
Hi Prateek,
> I would like to strongly disagree with this proposal.
>
> It amounts to explicitly making OAuth 2.0 insecure so as to
> satisfy some mysterious and unspecified set of legacy OAuth
> 1.0 deployments.
>
> The SAML web SSO (artifact) profile - which shares many
> characteristics with
Unfortunately neither solution suggested so far is acceptable. So a vote from
my perspective is premature.
I'd like to keep working for a new solution.
Phil
phil.h...@oracle.com
On 2011-04-01, at 10:51 AM, Oleg Gryb wrote:
> It's a very interesting discussion and I think, I understand both
It's a very interesting discussion and I think, I understand both parties well
because consider myself belonging to both communities (enterprise and
networking). Still, I would vote in favor of MUST.
Considering the big size of this mailing list and the big level of engagement
of
its members,
Skylar,
> Right, but just so we are clear, the only case you are
> discussing here is the MITM attack, which George, I and
> others have recently outlined.
There several flavors of MITM attacks, and a passive attack.
See
http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html,
http://ww
Skylar,
> Francisco, correct me if I'm wrong, but in your discussion
> you assume that the application is incapable of keeping
> secrets from the public (eg, mobile, desktop apps, etc.).
> According to the spec, those applications should never
> receive client credentials to begin with. They can'
What Mike said.
Definitely keep section 3 and I would really like to see the client
assertion section restored. Glad to hear there is some progress on
that front.
Marius
On Fri, Apr 1, 2011 at 6:19 AM, Mike Jones wrote:
> Also -1 on dropping section 3. Rather, we need to restore the client
I agree with Justin.
From: "Richer, Justin P."
To: Eran Hammer-Lahav ; OAuth WG
Sent: Friday, April 1, 2011 5:18 AM
Subject: Re: [OAUTH-WG] Reques to drop section 3
-1 once again
I want to keep the client password mechanism in core as it reflects the way
that
> So we have 2 different communities of Oauth developers that
> will never agree.
>
> SHOULD: Typically the social networking sites that need to
> cater for tail end developers by not enforcing TLS on
> redirect_uri. It is a risk to think that using strong
> language in the spec will help them app
Sadly, I am not in Prague. Given the similarities between the JWT and
SAML grant drafts, please let me know if anything substantial comes
out of the JWT discussions. Thanks!
On Thu, Mar 31, 2011 at 3:05 PM, Mike Jones wrote:
> To this, I'd like to add discussion of draft-jones-oauth-jwt-bearer
Withdrawn. I just don't care enough to waste any more time on this. I'll wait
for the revised text assigned at the meeting and will integrate at the
direction of the chairs.
EHL
On Apr 1, 2011, at 2:14, "Eran Hammer-Lahav"
mailto:e...@hueniverse.com>> wrote:
There was (still is) a long heated
I'm withdrawing my vote. When others decide what they want to do I'll apply it.
EHL
On Mar 31, 2011, at 17:10, "Eran Hammer-Lahav"
mailto:e...@hueniverse.com>> wrote:
(The previous thread is became completely inaccessible to anyone not following
it carefully for the past week or so. For the sa
Also -1 on dropping section 3. Rather, we need to restore the client assertion
credentials to 3, per the outcome of the discussion at today's working group
meeting. I'm glad that we're headed in that direction.
-- Mike
-Original Message-
From: oauth-bou
-1 once again
I want to keep the client password mechanism in core as it reflects the way
that most (nearly all in my personal experience) client implementations pass
their auth parameters today. I do think that the assertion credentials could
live fine in a simple extension, though, with the s
This section makes sense as it does setup for the identification and
authentication of the client, so I do believe that it makes sense in the
document. Thomas undertook the task to revive the Client Credentials section
from previous draft that will include normative text, which when asked the r
There was (still is) a long heated debate at the WG meeting today about client
authentication and the dropped client assertion credentials section. I want to
repeat my past view (and this time post it as an open issue), that this entire
section makes no sense in this document. OAuth should not b
So we have 2 different communities of Oauth developers that will never
agree.
SHOULD: Typically the social networking sites that need to cater for tail
end developers by not enforcing TLS on redirect_uri. It is a risk to think
that using strong language in the spec will help them appreciate the is
Hi Marius,
Can you provide very high level details on what that approach is?
thanks
Mark
oauth-boun...@ietf.org wrote on 01/04/2011 02:34:56:
> Marius Scurtescu
> Sent by: oauth-boun...@ietf.org
>
> 01/04/2011 02:34
>
> To
>
> Greg Brockman
>
> cc
>
> oauth@ietf.org
>
> Subject
>
> Re: [OAUT
As discussed in the WG session at Prague just now, in discussion with
the Security Area Directors I have decided to move the OAuth Working
Group from the Applications Area to the Security Area of the IETF. The
rationale is that all of the most important work remaining for the WG to
produce OAuth 2.
23 matches
Mail list logo
