Nat/Naveen, I must confess I keep going back and forth on this issue.
Clearly this draft is a fix for the issue of: 1. Real app initiates authorize request 2. 'bad' app intercepts grant because it has taken over the access token. But while I agree this is a problem, what's to stop the 'bad' app from doing 1 and 2? As they say all bets are off. I can register "Facebook Blue" and make it look like the next generation facebook app. Even if we could prove that an app is legit by some cryptographic means, we are still limited by Mobile App store vendors, and how well they curate apps, and what they do to make sure only legit apps can run. Naveen, you mentioned at IIW, we really have to depend more on the user authorization of the app. Can you comment here? I think the draft is correct. It fixes the problem it describes. But does it matter? Phil @independentid www.independentid.com [email protected] On 2013-10-19, at 3:15 AM, Nat Sakimura <[email protected]> wrote: > Incorporated the discussion at Berlin meeting and after in the ML. > > Best, > > Nat > > ---------- Forwarded message ---------- > From: <[email protected]> > Date: 2013/10/19 > Subject: New Version Notification for draft-sakimura-oauth-tcse-02.txt > To: Nat Sakimura <[email protected]>, John Bradley > <[email protected]>, Naveen Agarwal <[email protected]> > > > > A new version of I-D, draft-sakimura-oauth-tcse-02.txt > has been successfully submitted by Nat Sakimura and posted to the > IETF repository. > > Filename: draft-sakimura-oauth-tcse > Revision: 02 > Title: OAuth Symmetric Proof of Posession for Code Extension > Creation date: 2013-10-19 > Group: Individual Submission > Number of pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-sakimura-oauth-tcse-02.txt > Status: http://datatracker.ietf.org/doc/draft-sakimura-oauth-tcse > Htmlized: http://tools.ietf.org/html/draft-sakimura-oauth-tcse-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-tcse-02 > > Abstract: > The OAuth 2.0 public client utilizing authorization code grant is > susceptible to the code interception attack. This specification > describe a mechanism that acts as a control against this threat. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
