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

Discussion:

i***@ietf.org

2017-03-03 06:27:49 UTC

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://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-08

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

William Denniss

2017-03-03 06:39:03 UTC

Permalink

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.

Post by i***@ietf.org
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
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-08
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-08
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.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Hannes Tschofenig

2017-03-06 19:41:05 UTC

Permalink

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

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.
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
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.
https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/
<https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/>
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-08
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-08>
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-08
<https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-08>
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
<http://tools.ietf.org>.
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

John Bradley

2017-03-06 20:16:03 UTC

Permalink

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.

Post by Hannes Tschofenig
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

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

William Denniss

2017-03-07 00:49:54 UTC

Permalink

Section 7.1.1 can probably be rolled up into Section 7.1, I agree it's a
bit out of place. I'll do that in -09.

+1 with the plan that this BCP documents the current state, and we can rev
it if and when that changes.

One comment to add: password eavesdropping isn't the only threat from
WebView, the app is basically in total control and can do other things like
modify the contents of the page, interact with it (like faking a click on
the "Approve" button), copy out the session cookie, etc.

Post by John Bradley
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.

Post by William Denniss
â Addresses feedback from the second round of WGLC.
â Reordered security consideration sections to better group related

topics.

Post by Hannes Tschofenig

Post by William Denniss
â Added complete URI examples to each of the 3 redirect types.
â Editorial pass.
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.

Post by Hannes Tschofenig

Post by William Denniss
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
OAuth 2.0 authorization requests from native apps should only be

made

Post by Hannes Tschofenig

Post by William Denniss
through external user-agents, primarily the user's browser. This
specification details the security and usability reasons why this

Post by Hannes Tschofenig

Post by William Denniss
the case, and how native apps and authorization servers can

implement

Post by Hannes Tschofenig

Post by William Denniss
this best practice.
https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/
<https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/>
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-08
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-08>
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-08
<https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-08>
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
<http://tools.ietf.org>.
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Anthony Nadalin

2017-03-07 08:16:18 UTC

Permalink

Not true John, the CTAP support that is current would support the web-view w/o any changes

-----Original Message-----
From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of John Bradley
Sent: Monday, March 6, 2017 12:16 PM
To: Hannes Tschofenig <***@gmx.net>
Cc: internet-***@ietf.org; ***@ietf.org
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.

Post by Hannes Tschofenig
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

– 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.
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
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.
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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=YQ0dcSViranVx4sjH7aeFrEYvTgbQM3OruoK%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>
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%7C72f988bf86f141af91ab2d7cd011db47%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>
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%7C72f988bf86f141af91ab2d7cd011db47%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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=sDynfqey0ru0Vm4%2FPEh0MA1IKtkrqmDnQ%2BmPCP%2B6K60%3D&reserved=0>.
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
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
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
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

John Bradley

2017-03-07 20:08:06 UTC

Permalink

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.

Post by Anthony Nadalin
Not true John, the CTAP support that is current would support the web-view w/o any changes
-----Original Message-----
Sent: Monday, March 6, 2017 12:16 PM
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.

Post by Hannes Tschofenig
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

Post by William Denniss
â 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.
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
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.
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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=YQ0dcSViranVx4sjH7aeFrEYvTgbQM3OruoK%2FR7EZak%3D&reserved=0 <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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=YQ0dcSViranVx4sjH7aeFrEYvTgbQM3OruoK%2FR7EZak%3D&reserved=0>
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat>
atracker.ietf.org <http://atracker.ietf.org/>%2Fdoc%2Fdraft-ietf-oauth-native-apps%2F&data=02%7C0
1%7Ctonynad%40microsoft.com <http://40microsoft.com/>%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f9
88bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=YQ0dc
SViranVx4sjH7aeFrEYvTgbQM3OruoK%2FR7EZak%3D&reserved=0>
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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=ipyVLaXhefjwhIPqu4Vym3Nmi%2FXPER8hyKBDvP%2FAVCw%3D&reserved=0 <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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=ipyVLaXhefjwhIPqu4Vym3Nmi%2FXPER8hyKBDvP%2FAVCw%3D&reserved=0>
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo>
ls.ietf.org <http://ls.ietf.org/>%2Fhtml%2Fdraft-ietf-oauth-native-apps-08&data=02%7C01%7Ct
onynad%40microsoft.com <http://40microsoft.com/>%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf8
6f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=pFJdiZd2ni
SxiuXtThG8OE32rjHxoJ8U0jsoCmiaqKc%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%7C72f988bf86f141af91ab2d7cd011db47%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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=0JOejYI%2F9vSFph4dteZ6g16NbvLRy37erpRUAw2q%2FW8%3D&reserved=0>
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww>
.ietf.org <http://ietf.org/>%2Frfcdiff%3Furl2%3Ddraft-ietf-oauth-native-apps-08&data=02%
7C01%7Ctonynad%40microsoft.com <http://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 <http://tools.ietf.org/>
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org&data=02%7C01%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=sDynfqey0ru0Vm4%2FPEh0MA1IKtkrqmDnQ%2BmPCP%2B6K60%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org&data=02%7C01%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=sDynfqey0ru0Vm4%2FPEh0MA1IKtkrqmDnQ%2BmPCP%2B6K60%3D&reserved=0>>.
ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
<ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>>
_______________________________________________
OAuth mailing list
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%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cRYUSlotpr6JXtFXpduGuI%3D&reserved=0>
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww>
.ietf.org <http://ietf.org/>%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40micro
soft.com <http://soft.com/>%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7
cd011db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7c
RYUSlotpr6JXtFXpduGuI%3D&reserved=0>
_______________________________________________
OAuth mailing list
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww>.
ietf.org <http://ietf.org/>%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40micros
oft.com <http://oft.com/>%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7c
d011db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cR
YUSlotpr6JXtFXpduGuI%3D&reserved=0

_______________________________________________
OAuth mailing list
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i>
etf.org <http://etf.org/>%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsof
t.com <http://t.com/>%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd01
1db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cRYUSl
otpr6JXtFXpduGuI%3D&reserved=0

William Denniss

2017-03-07 20:35:22 UTC

Permalink

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.

Post by John Bradley
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.
Not true John, the CTAP support that is current would support the web-view w/o any changes
-----Original Message-----
Behalf Of John Bradley
Sent: Monday, March 6, 2017 12:16 PM
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.
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
â 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.
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
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.
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%7Cef
f092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd01
1db47%7C1%7C0%7C636244281810078497&sdata=YQ0dcSViranVx4sjH7a
eFrEYvTgbQM3OruoK%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>
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%7Ceff092e6b28
94ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011db47%
7C1%7C0%7C636244281810078497&sdata=ipyVLaXhefjwhIPqu4Vym3Nm
i%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>
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%7Cef
f092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd01
1db47%7C1%7C0%7C636244281810088501&sdata=0JOejYI%2F9vSFph4dt
eZ6g16NbvLRy37erpRUAw2q%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%7C72f988bf86f141af91a
b2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=sDynfqey0ru
0Vm4%2FPEh0MA1IKtkrqmDnQ%2BmPCP%2B6K60%3D&reserved=0>.
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
https://na01.safelinks.protection.outlook.com/?url=https%
3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%
7C01%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d4
64cda4d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244
281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cRYUSlotpr6JXtFXpd
uGuI%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
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
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
https://www.ietf.org/mailman/listinfo/oauth

A***@telekom.de

2017-03-13 08:35:32 UTC

Permalink

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:oauth-***@ietf.org] On Behalf Of William Denniss
Sent: Tuesday, March 07, 2017 9:35 PM
To: John Bradley
Cc: internet-***@ietf.org; ***@ietf.org
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 <***@ve7jtb.com<mailto:***@ve7jtb.com>> 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 <***@microsoft.com<mailto:***@microsoft.com>> wrote:

Not true John, the CTAP support that is current would support the web-view w/o any changes

-----Original Message-----
From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of John Bradley
Sent: Monday, March 6, 2017 12:16 PM
To: Hannes Tschofenig <***@gmx.net<mailto:***@gmx.net>>
Cc: internet-***@ietf.org<mailto:internet-***@ietf.org>; ***@ietf.org<mailto:***@ietf.org>
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 <***@gmx.net<mailto:***@gmx.net>> 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, <internet-***@ietf.org<mailto:internet-***@ietf.org>
<mailto:internet-***@ietf.org>> 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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=YQ0dcSViranVx4sjH7aeFrEYvTgbQM3OruoK%2FR7EZak%3D&reserved=0

<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
atracker.ietf.org<http://atracker.ietf.org/>%2Fdoc%2Fdraft-ietf-oauth-native-apps%2F&data=02%7C0
1%7Ctonynad%40microsoft.com<http://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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810078497&sdata=ipyVLaXhefjwhIPqu4Vym3Nmi%2FXPER8hyKBDvP%2FAVCw%3D&reserved=0

<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
ls.ietf.org<http://ls.ietf.org/>%2Fhtml%2Fdraft-ietf-oauth-native-apps-08&data=02%7C01%7Ct
onynad%40microsoft.com<http://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%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244281810088501&sdata=0JOejYI%2F9vSFph4dteZ6g16NbvLRy37erpRUAw2q%2FW8%3D&reserved=0

<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
.ietf.org<http://ietf.org/>%2Frfcdiff%3Furl2%3Ddraft-ietf-oauth-native-apps-08&data=02%
7C01%7Ctonynad%40microsoft.com<http://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<http://tools.ietf.org/>
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org&data=02%7C01%7Ctonynad%40microsoft.com%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd011db47%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
***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org>
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<http://ietf.org/>%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40micro
soft.com<http://soft.com/>%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7
cd011db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7c
RYUSlotpr6JXtFXpduGuI%3D&reserved=0>

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ietf.org<http://ietf.org/>%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40micros
oft.com<http://oft.com/>%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7c
d011db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cR
YUSlotpr6JXtFXpduGuI%3D&reserved=0

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
etf.org<http://etf.org/>%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsof
t.com<http://t.com/>%7Ceff092e6b2894ace8f8408d464cda4d5%7C72f988bf86f141af91ab2d7cd01
1db47%7C1%7C0%7C636244281810088501&sdata=14GztZLY%2BnQNbhR5bqjS7cRYUSl
otpr6JXtFXpduGuI%3D&reserved=0

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

William Denniss

2017-03-13 16:48:23 UTC

Permalink

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

Post by A***@telekom.de
Hi,
"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
Denniss
*Sent:* Tuesday, March 07, 2017 9:35 PM
*To:* John Bradley
*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" 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
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.
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.
Not true John, the CTAP support that is current would support the web-view w/o any changes
-----Original Message-----
Behalf Of John Bradley
Sent: Monday, March 6, 2017 12:16 PM
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.
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
â 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.
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
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.
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>
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>
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>.
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
OAuth mailing list
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
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
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
https://www.ietf.org/mailman/listinfo/oauth