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

[internet-drafts]

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-05.txt
Pages   : 18
Date: 2016-10-21

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-05

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


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/

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

[OAUTH-WG] Metadata about Authorization Servers

[Hannes Tschofenig]

Hi all,

I need the feedback from the group on one of our working group items,
namely https://tools.ietf.org/html/draft-ietf-oauth-discovery-04

Despite the name (discovery) the document really only describes
configuration information about an authorization server in a machine
readable form, which today a developer would typically retrieve from an
HTML page. The confirmation information includes things like endpoint
URIs, issuer identifiers, etc..

In the discussions the concern that surfaced was about the envisioned
message flow on when a client would obtain such information:

* One group was of the opinion that a client would already know what
resource server it wants to talk to before reaching out to the
authorization server to obtain this meta data.

* The second group was under the believe that a resource server would
tell the client what authorization server to contact.

There was no conclusion about which message interaction is more likely
or better but in any case there are security concerns that arise. I
don't think that there is a conclusion that the message interaction
actually matters for the context of this work since the information
about resource servers is available already today although not in an
machine readable form.

The main concern is that a resource server gets the client to obtain a
token that he can then re-use with other resource servers.

Quite naturally this is a bad thing and we have developed two solution
approaches to deal with this problem, namely

* Audience restricted access tokens (see
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01),
and

* PoP tokens (with the current token binding solution as a WG item)

Since token binding will need a bit of time before it gets widely
deployed I believe that we need to mandate the use of audience
restrictions for use with the resource meta data (which IMHO should have
been mandated already in the OAuth core specification).

I don't think we have a conclusion whether these security issues are
really tied to the metadata document since the security concern about
tokens getting replayed at other resource servers was a concern long
before the meta-data work was even considered in OAuth.

So, how should we move forward with the metadata document? Your views
are appreciated!

Ciao
Hannes



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Device Flow Open Issues

[Hannes Tschofenig]

Hi all,

at the last IETF meeting we got lots of good feedback regarding the
device flow document. Here is the link to the device flow draft:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03

Four main issues got captured in the minutes, namely
1) Alternative to polling
2) Missing security guidance
3) UI recommendations
4) Alternative Authorization Request/Response Pattern

Here is the link to the meeting minutes:
https://www.ietf.org/proceedings/96/minutes/minutes-96-oauth

In a discussion with John, William, Simon, and myself we thought it
would be best to drop a mail to the list about these issues and seek for
your feedback.

Ciao
Hannes




signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Device Flow: Alternative to Polling

[Hannes Tschofenig]

Hi all,

the device flow document outlines the case when an OAuth interaction
gets "outsourced" to a separate device in order to allow user
authentication and collecting the consent.

The exchange is described in Section 1 of
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03.

Here is the step that was raised during the discussions:

  (E) While the end-user authorizes (or denies) the client's request
  (D), the client repeatedly polls the authorization server to find
  out if the end-user completed the end-user authorization step.
  The client includes the verification code and its client
  identifier.

The question was whether we could come up with an alternative to polling
since this step could potentially take some time. Hence, it would be
better if the authorization server has a way to send a message to the
client without polling. Of course, the polling frequency matters and how
quickly one (e.g., user) wants to know about the successful authorization.

So, the first question is whether polling is considered as a problem in
the first place.

If so, then the question is how this could be addressed and (from work
in other areas) there are really only two approaches:

1) We make use of some protocol that keeps the connection open and allow
asynchronous communication. HTTP/2 and Websockets come to mind.

2) The client can be addressed through some push notification mechanism,
such as by running an HTTP server on the device that can then be used by
the authorization server.

Any views about this topic?

Ciao
Hannes




signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Device Flow: Alternative to Polling

[Aaron Parecki]

Part of the beauty of the current device flow spec is that it's so simple
to support. Keeping that simplicity is crucial especially for this, since
this flow is used by a variety of devices that often do not have higher
level stacks.

I would love to hear from someone who has experience with large-scale
deployments of this to know whether polling is even a problem in the first
place.


Aaron Parecki
aaronparecki.com
@aaronpk 


Aaron Parecki
aaronparecki.com
@aaronpk 


On Fri, Oct 21, 2016 at 3:23 PM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> Hi all,
>
> the device flow document outlines the case when an OAuth interaction
> gets "outsourced" to a separate device in order to allow user
> authentication and collecting the consent.
>
> The exchange is described in Section 1 of
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03.
>
> Here is the step that was raised during the discussions:
>
>   (E) While the end-user authorizes (or denies) the client's request
>   (D), the client repeatedly polls the authorization server to find
>   out if the end-user completed the end-user authorization step.
>   The client includes the verification code and its client
>   identifier.
>
> The question was whether we could come up with an alternative to polling
> since this step could potentially take some time. Hence, it would be
> better if the authorization server has a way to send a message to the
> client without polling. Of course, the polling frequency matters and how
> quickly one (e.g., user) wants to know about the successful authorization.
>
> So, the first question is whether polling is considered as a problem in
> the first place.
>
> If so, then the question is how this could be addressed and (from work
> in other areas) there are really only two approaches:
>
> 1) We make use of some protocol that keeps the connection open and allow
> asynchronous communication. HTTP/2 and Websockets come to mind.
>
> 2) The client can be addressed through some push notification mechanism,
> such as by running an HTTP server on the device that can then be used by
> the authorization server.
>
> Any views about this topic?
>
> Ciao
> Hannes
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Brian Campbell]

I did consider something like that but stopped short of putting it in the
-00 document. I'm not convinced that some metadata around it would really
contribute to interop one way or the other. I also wanted to get the basic
concept written down before going too far into the weeds. But I'd be open
to adding something along those lines in future revisions, if there's some
consensus that it'd be useful.

On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov  wrote:

> Superb, I welcome that!
>
> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
> client-auth-00#section-5.2 :
>
> My concern is that the choice of how to bind the client identity is left
> to implementers, and that may eventually become an interop problem.
> Have you considered some kind of an open ended enumeration of the possible
> binding methods, and giving them some identifiers or names, so that AS /
> OPs can advertise them in their metadata, and clients register accordingly?
>
> For example:
>
> "tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match",
> "subject_public_key_info_match" ]
>
>
> Cheers,
>
> Vladimir
>
> On 10/10/16 23:59, John Bradley wrote:
>
> At the request of the OpenID Foundation Financial Services API Working group, 
> Brian Campbell and I have documented
> mutual TLS client authentication.   This is something that lots of people do 
> in practice though we have never had a spec for it.
>
> The Banks want to use it for some server to server API use cases being driven 
> by new open banking regulation.
>
> The largest thing in the draft is the IANA registration of “tls_client_auth” 
> Token Endpoint authentication method for use in Registration and discovery.
>
> The trust model is intentionally left open so that you could use a “common 
> name” and a restricted list of CA or a direct lookup of the subject public 
> key against a reregistered value,  or something in between.
>
> I hope that this is non controversial and the WG can adopt it quickly.
>
> Regards
> John B.
>
>
>
>
>
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for 
> draft-campbell-oauth-tls-client-auth-00.txt
> Date: October 10, 2016 at 5:44:39 PM GMT-3
> To: "Brian Campbell"  
> , "John Bradley"  
> 
>
>
> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
> has been successfully submitted by John Bradley and posted to the
> IETF repository.
>
> Name: draft-campbell-oauth-tls-client-auth
> Revision: 00
> Title:Mutual X.509 Transport Layer Security (TLS) 
> Authentication for OAuth Clients
> Document date:2016-10-10
> Group:Individual Submission
> Pages:5
> URL:
> https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
> Htmlized:   
> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
>
>
> Abstract:
>   This document describes X.509 certificates as OAuth client
>   credentials using Transport Layer Security (TLS) mutual
>   authentication as a mechanism for client authentication to the
>   authorization server's token endpoint.
>
>
>
>
> 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
>
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Device Flow: Alternative to Polling

[William Denniss]

We've been operating with polling for a while and handle a decent amount of
traffic (the YouTube TV app uses it), the polling gets the job done. The
simplicity of the protocol definitely helps when used on constrained
devices.

I like the idea of adding HTTP/2 based long-poll as an optional
enhancement, especially if we can define it in ways that don't alter the
underlying protocol a whole lot.

On Fri, Oct 21, 2016 at 3:35 PM, Aaron Parecki  wrote:

> Part of the beauty of the current device flow spec is that it's so simple
> to support. Keeping that simplicity is crucial especially for this, since
> this flow is used by a variety of devices that often do not have higher
> level stacks.
>
> I would love to hear from someone who has experience with large-scale
> deployments of this to know whether polling is even a problem in the first
> place.
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
>
> On Fri, Oct 21, 2016 at 3:23 PM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
>> Hi all,
>>
>> the device flow document outlines the case when an OAuth interaction
>> gets "outsourced" to a separate device in order to allow user
>> authentication and collecting the consent.
>>
>> The exchange is described in Section 1 of
>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03.
>>
>> Here is the step that was raised during the discussions:
>>
>>   (E) While the end-user authorizes (or denies) the client's request
>>   (D), the client repeatedly polls the authorization server to find
>>   out if the end-user completed the end-user authorization step.
>>   The client includes the verification code and its client
>>   identifier.
>>
>> The question was whether we could come up with an alternative to polling
>> since this step could potentially take some time. Hence, it would be
>> better if the authorization server has a way to send a message to the
>> client without polling. Of course, the polling frequency matters and how
>> quickly one (e.g., user) wants to know about the successful authorization.
>>
>> So, the first question is whether polling is considered as a problem in
>> the first place.
>>
>> If so, then the question is how this could be addressed and (from work
>> in other areas) there are really only two approaches:
>>
>> 1) We make use of some protocol that keeps the connection open and allow
>> asynchronous communication. HTTP/2 and Websockets come to mind.
>>
>> 2) The client can be addressed through some push notification mechanism,
>> such as by running an HTTP server on the device that can then be used by
>> the authorization server.
>>
>> Any views about this topic?
>>
>> Ciao
>> Hannes
>>
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 97

["IETF Secretariat"]

Dear Hannes Tschofenig,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

oauth Session 1 (1:30:00)
Wednesday, Afternoon Session II 1520-1620
Room Name: Studio 3 size: 80
-
oauth Session 2 (1:30:00)
Monday, Morning Session I 0930-1200
Room Name: Studio 3 size: 80
-



Request Information:


-
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Hannes Tschofenig

Number of Sessions: 2
Length of Session(s):  1.5 Hours, 1.5 Hours
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: tokbind tls core saag




Special Requests:
  Please avoid conflict with sec area BoFs.
-

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