It now occurs to me that "bug" for item (1) below is perhaps
a bit understated; it's really more of a security issue,
since if the implementer follows what the current spec is
apparently saying, the authorization server essentially
becomes an open redirector.
(... Apologies if this was obvious
+1, what John said.
Marius
On Sat, Dec 3, 2011 at 9:39 PM, John Bradley wrote:
> I remain unconvinced that at this point MTI is going to be useful.
>
> I appreciate that some people want MAC, I could not support it being MTI.
>
> The below text with Bearer as MTI the only would be acceptable,
BEAST is an attack against TLS 1.0. In order to succeed, an attacker,
predicting that a user will eventually make an https connection to
www.example.com, lures the user to an attacker-controlled web site. From that
site the user browser downloads the attacker's script (e.g., JavaScript). Then,
I agree that the core should remain token agnostic. However, I do see
value in MAC. The ability to have parameter values signed by a client
key is important for security in depth, even in a world of pervasive
server-side TLS. I would like to see MAC tokens mature to the point
where we could use
