Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt

[William Denniss <[e-mail]>]

Thanks! I've corrected that in my local copy.

On Mon, Mar 13, 2017 at 1:35 AM, <[e-mail]> wrote:

> Hi,
>
>
>
> There is an extra “where” in this Terminology definition:
>
>
>
> "reverse domain name notation"  A naming convention based on the
>
>       domain name system, but where where the domain components are
>
>       reversed, for example "app.example.com" becomes "com.example.app".
>
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-09
>
>
>
> cheers
>
> Axel
>
>
>
>
>
> *From:* OAuth [mailto:[e-mail]] *On Behalf Of *William
> Denniss
> *Sent:* Tuesday, March 07, 2017 9:35 PM
> *To:* John Bradley
>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt
>
>
>
> That's an important distinction. It's not a "web-view vs browser"
> question, but an "embedded user-agent vs external user-agent" question.  If
> something is named "webview" but has all the attributes of an external
> use-agent, then it's still an external user-agent for the purpose of the
> BCP.
>
>
>
> I tried to be careful to always use the term "embedded user-agent"
> following the nomenclature of RFC6749, e.g. title of Section 8.1. Webview
> is referenced in a few places, for example Sec 8.1 says "In typical
> web-view based implementations of embedded user-agents", as most embedded
> user-agents do happen to use technology called webview – but there's no
> normative text that means something named "webview" but that is actually an
> external user-agent can't be used.
>
>
>
> External user-agent is defined in the spec as such:
>
>
>
>    "external user-agent"  A user-agent capable of handling the
>
>       authorization request that is a separate entity to the native app
>
>       making the request (such as a browser), such that the app cannot
>
>       access the cookie storage or modify the page content.
>
>
>
>
>
> Earlier versions were not as careful with the terms, but it was tightened
> up and clarified for this very reason.
>
>
>
> Regarding the Windows broker, it is explicitly mentioned as an external
> user agent in the implementation details appendix (emphasis added):
>
>
>
>  Universal Windows Platform (UWP) apps can use the Web Authentication
>
>    Broker API in SSO mode as an *external user-agent* for authorization
>
>    flows…
>
>
>
> I've had the same experiance as you John, and have not seen U2F work on
> any implementation of webview that I've used (including iOS, Android, and
> Windows using the old-style embedded IE control).
>
>
>
> +1 to update the BCP when and if the best current practice changes. I
> believe it does accurately capture the best current practice as of today.
>
>
>
> On Tue, Mar 7, 2017 at 12:08 PM, John Bradley <[e-mail]> wrote:
>
> That is theory that CTAP should let web-views work.
>
>
>
> I just ran a test on the current shipping Android build. U2F is only
> working from the View controller and system browser.
>
> Web-view is not currently exposing CTAP.
>
>
>
> I believe that is also the case on iOS, but haven't built a app to test it.
>
>
>
> This first version of the BCP doesn’t go into advanced issues around Web
> Auth/Fido in detail.  We know that currently WebView/View controller/Token
> Agent work with existing CTAP implementations.
>
>
>
> Once we have systems deployed that can use CTAP from a web view we can
> update the BCP.
>
>
>
> We may also have a definitional problem, we consider the Windows token
> broker in SSO mode to fit the model of a view controller/Web View in that
> it is sandboxed from the app , rather than considering it a web-view.   I
> know that the token broker can support WebAuthentication (CTAP 2) in recent
> RS2 builds of Win 10.
>
>
>
> John B.
>
>
>
>
>
> On Mar 7, 2017, at 5:16 AM, Anthony Nadalin <[e-mail]> wrote:
>
>
>
> Not true John, the CTAP support that is current would support the web-view
> w/o any changes
>
>
>
> -----Original Message-----
> From: OAuth [mailto:[e-mail] <[e-mail]>] On
> Behalf Of John Bradley
> Sent: Monday, March 6, 2017 12:16 PM
> To: Hannes Tschofenig <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-08.txt
>
> On fido I can tell you that for security reasons U2F wont work from a
> web-view currently.
>
> Once we move to Web Auth (Fido 2) where the OS provides a API for apps to
> call to get the token it will work but the tokens are audianced to the app
> based on its developer key and bundle_id so that a app cant ask for a token
> for a different site to do correlation.
>
> It is true that Fido UAF currently requires a web-view to work as the
> authenticator is effectively compiled in to each application, and that
> application has access to the private keys on most platforms (Samsung knox
> being the only exception to that that I know of where the keys are managed
> by a common API to hardware key storage, but they are scoped like U2F as
> well)
>
> So for the most part it is true and that unless you use the browser to get
> the Fido token the audience is for the app.
> Example  Salesforce creates native app that may use enterprise SSO via
> SAML, and the enterprise may use Fido as a authentication factor.
> If they use the webview + fido API approach the app can only get a token
> for SalesForce based on its signing key.  It could fire up the web-view and
> do U2F authentication with the enterprise after Salesforec has redirected
> the user.  However it will give every enterprise a token audience to
> Salesforce with a salesforce specific key.   If there is a second app for
> say Slack if they do the same thing the enterprise would get a slack
> audienced token and a slack key forcing a separate registration.
>
> The recommended alternative is that the app use a custom tab for the user
> to SalesForce and that redirect to the enterprise.
> The enterprise gets the same token/key with the correct audience from all
> apps on the device using the browser or custom tab.
> The user may not need to signin a second time, and if they do there Fido
> token will not need to be re-registerd.
>
> The Fido API approach really only works for first party apps like PayPal
> if the the app is not doing federation and paypal is doing the
> authentication for there own app.
>
> Token binding private keys have similar issues.   The pool of private keys
> will probably not be shared between apps, and not between the app and the
> browser (Win 10 may be an exception but it is not documented yet)
>
> In the case of using AppAuth with token binding the browser maintains the
> keys so the enterprise would be able to see the same key and use the same
> cookies across all AppAuth Apps.
>
> You can include token binding in your app, however the token bindings and
> cookies are going to be sand boxed per app.
> Depending on implementation the app gets access to the cookie, but perhaps
> not to the private token binding key.  (At least I don't think it will in
> Android embedded webview).
>
> We could expand on this later in an update to the BCP once Web
> Authentication and Token Binding are final.
>
> There are still some unknowns, but in general for any sort of
> SSO/Federation 3rd party app I don’t see recommending anything other than a
> custom tab/ view controller/ external browser.
>
> William can take the formatting question:)
>
> John B.
>
> On Mar 6, 2017, at 4:41 PM, Hannes Tschofenig <[e-mail]>
> wrote:
>
> Hi William, Hi John,
>
> I just re-read version -8 of the document again.
>
> Two minor remarks only.
>
> Editorial issue: Why do you need to introduce a single sub-section
> within Section 7.1. (namely Section 7.1.1)?
>
> Background question: You note that embedded user agents have the
> disadvantage that the app that hosts the embedded user-agent can
> access the user's full authentication credential. This is certainly
> true for password-based authentication mechanisms but I wonder whether
> this is also true for strong authentication techniques, such as those
> used by FIDO combined with token binding. Have you looked into more
> modern authentication techniques as well and their security implication?
>
> Ciao
> Hannes
>
> On 03/03/2017 07:39 AM, William Denniss wrote:
>
> Changes:
>
> – Addresses feedback from the second round of WGLC.
> – Reordered security consideration sections to better group related topics.
> – Added complete URI examples to each of the 3 redirect types.
> – Editorial pass.
>
>
>
> On Thu, Mar 2, 2017 at 10:27 PM, <[e-mail]
> <mailto:[e-mail] <[e-mail]>>> wrote:
>
>
>   A New Internet-Draft is available from the on-line Internet-Drafts
>   directories.
>   This draft is a work item of the Web Authorization Protocol of the IETF.
>
>           Title           : OAuth 2.0 for Native Apps
>           Authors         : William Denniss
>                             John Bradley
>           Filename        : draft-ietf-oauth-native-apps-08.txt
>           Pages           : 20
>           Date            : 2017-03-02
>
>   Abstract:
>      OAuth 2.0 authorization requests from native apps should only be made
>      through external user-agents, primarily the user's browser.  This
>      specification details the security and usability reasons why this is
>      the case, and how native apps and authorization servers can implement
>      this best practice.
>
>
>   The IETF datatracker status page for this draft is:
>
>   https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-
> oauth-native-apps%2F&data=02%7C01%7Ctonynad%40microsoft.com%
> 7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636244281810078497&sdata=YQ0dcSViranVx4sjH7aeFrEYvTgbQM
> 3OruoK%2FR7EZak%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> atracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-native-apps%2F&data=02%7C0
> 1%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f9
> 88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=YQ0dc
> SViranVx4sjH7aeFrEYvTgbQM3OruoK%2FR7EZak%3D&reserved=0>
>
>   There's also a htmlized version available at:
>   https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-
> native-apps-08&data=02%7C01%7Ctonynad%40microsoft.com%
> 7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636244281810078497&sdata=ipyVLaXhefjwhIPqu4Vym3Nmi%
> 2FXPER8hyKBDvP%2FAVCw%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
> ls.ietf.org%2Fhtml%2Fdraft-ietf-oauth-native-apps-08&data=02%7C01%7Ct
> onynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf8
> 6f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=pFJdiZd2ni
> SxiuXtThG8OE32rjHxoJ8U0jsoCmiaqKc%3D&reserved=0>
>
>   A diff from the previous version is available at:
>   https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-
> oauth-native-apps-08&data=02%7C01%7Ctonynad%40microsoft.com%
> 7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636244281810088501&sdata=0JOejYI%
> 2F9vSFph4dteZ6g16NbvLRy37erpRUAw2q%2FW8%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-oauth-native-apps-08&data=02%
> 7C01%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C7
> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=0J
> OejYI%2F9vSFph4dteZ6g16NbvLRy37erpRUAw2q%2FW8%3D&reserved=0>
>
>
>   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
>   <https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Ftools.ietf.org&data=02%7C01%7Ctonynad%40microsoft.com%
> 7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636244281810088501&sdata=sDynfqey0ru0Vm4%
> 2FPEh0MA1IKtkrqmDnQ%2BmPCP%2B6K60%3D&reserved=0>.
>
>   Internet-Drafts are also available by anonymous FTP at:
>   ftp://ftp.ietf.org/internet-drafts/
>   <ftp://ftp.ietf.org/internet-drafts/>
>
>   _______________________________________________
>   OAuth mailing list
>   [e-mail] <mailto:[e-mail] <[e-mail]>>
>   https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&
> data=02%7C01%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=
> 14GztZLY%2BnQNbhR5bqjS7cRYUSlotpr6JXtFXpduGuI%3D&reserved=0
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40micro
> soft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7c
> RYUSlotpr6JXtFXpduGuI%3D&reserved=0>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40micros
> oft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cR
> YUSlotpr6JXtFXpduGuI%3D&reserved=0
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsof
> t.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cRYUSl
> otpr6JXtFXpduGuI%3D&reserved=0
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>