Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer

[William Mills <[e-mail]>]

A big problem, in my opinion, is that credentials will end up in the browser history cache when they are included in the URL.  This is significant.  Unless an explicit user "sign out" in the browser invalidates all tokens issued to the browser (this is a significant revocation requirement and revocations isn't properly solved yet) then someone sitting down at the machine can recover a credential by looking in the history.


Note that enterprise edge proxies that are doing SSL termination may well see this, but that could be considered "their problem".  I have seen apparent evidence of 
large companies using egress proxies that terminate all SSL outbound at 
their proxy (depressingly evil), and they frequently get stuff wrong in 
terms of proxy settings.

-bill



>________________________________
> From: Derek Atkins <[e-mail]>
>To: Tim Bray <[e-mail]> 
>Cc: Ned Freed <[e-mail]>; [e-mail]; Apps Discuss <[e-mail]>; Mark Nottingham <[e-mail]>; Pete Resnick <[e-mail]> 
>Sent: Monday, April 16, 2012 7:38 AM
>Subject: Re: [apps-discuss] Reserved URI query parameter in draft-ietf-oauth-v2-bearer
> 
>Tim,
>
>Tim Bray <[e-mail]> writes:
>
>> As I pointed out in the other thread on this, it’s an architectural
>> botch. Go and look in RFC3986 and find where it discusses reserving
>> keywords in this part of the URI.  Hey, it’s not there!  (hint, hint)
>>
>> What *is* there is a lengthy discussion of the very important task,
>> done probably millions of times per second, of comparing two URIs and
>> deciding if they're equivalent, i.e. identify the same thing; this is
>> done by every piece of caching infrastructure and webcrawler.  Do all
>> these have to be retooled to peek in the arguments and change their
>> decision based on whether some bits are just outh_* crud?    (That
>> question is rhetorical).
>>
>> This is a deeply bad idea. -T
>
>As pointed out elsewhere on this thread by Mike Jones, caches, crawlers,
>and other middleware will never see this because the bearer token MUST
>be protected by SSL/TLS.  So no, nothing needs to be retooled because
>nothing will see it.
>
>-derek
>
>-- 
>       Derek Atkins                 617-623-3745
>      [e-mail]            www.ihtfp.com
>       Computer and Internet Security Consultant
>_______________________________________________
>apps-discuss mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>