You are right that they are similar, but there is a difference, and
only one of the six countermeasures is relevant to the threat I
described.
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4
seems to be about an attack where the malicious client impersonates a
differe
I would like to join by webex.
--
James Manger
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Thomas Hardjono
Sent: Friday, 4 November 2011 6:33 AM
To: oauth (oauth@ietf.org)
Cc: barryle...@computer.org
Subject: [OAUTH-WG] Webex for OAUTH-WG
If you set it up I will connect.
Thanks
John B.
On 2011-11-03, at 4:33 PM, Thomas Hardjono wrote:
> Folks,
>
> Would anyone be interested if I set-up a Webex session for the next
> OAUTH-WG meeting in Taipei? (You can dial-in via phone or computer). I'm
> finding that often the delays in Jabb
I would be interested.
Sorry I can't make it in person.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-11-03, at 12:33 PM, Thomas Hardjono wrote:
> Folks,
>
> Would anyone be interested if I set-up a Webex session for the next
> OAUTH-WG meeting in Taipei? (You ca
Folks,
Would anyone be interested if I set-up a Webex session for the next
OAUTH-WG meeting in Taipei? (You can dial-in via phone or computer). I'm
finding that often the delays in Jabber can cause some confusion.
For this to work someone from the meeting room in Taipei would need to
dial into
At this point in the process I think it would be better to add that to the
threat model draft. It would be appropriate to add it in the core spec, but
not a good idea now that it's deep into the last call?
From: Phil Hunt
To: Eran Hammer-Lahav
Cc: Justin Ric
On 11/03/2011 09:25 AM, Eran Hammer-Lahav wrote:
It can help by telling servers that as long as they support one of the MTI
types, they will be able to interop. Of course, they don't have to.
My feeling is that until there is an actual discovery experience out there that
works, this kind of in
+1
I note that RFCs 2616 & 2617 only reference each other. There is no MTI text.
It just references them.
It may be reasonable to observe that there are two classes of tokens Bearer,
where the client treats token as opaque to return to server at appropriate
times, and client-proof tokens such
It can help by telling servers that as long as they support one of the MTI
types, they will be able to interop. Of course, they don't have to.
My feeling is that until there is an actual discovery experience out there that
works, this kind of interop is not really an issue ATM.
EHL
> -Orig
This is exactly what I was thinking of. If a given token type is MTI for
clients, but servers can do whatever they want (this, as I read it, is
what was suggested), how does the MTI bit help interop at all?
-- Justin
On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote:
> I actually think the
On 2011-11-03 00:21, Manger, James H wrote:
5) Section 3 ABNF allows "realm=foo;realm=bar;scope=baz;error=123"
is that ok? Is processing clear for all cases? I don't think it
is.
The ABNF does not allow that.
It requires commas as separators, not semi-colons.
Indeed.
It requires double quo
11 matches
Mail list logo
