Re: [OAUTH-WG] OAuth 2.0 for Native Apps: Call for Adoption Finalized

[Justin Richer]

I’d like to note that when Tony brought up it being Experimental on the list, 
several of us (myself included) pointed out that Informational is the correct 
designation for this specification.

 — Justin

> On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig  
> wrote:
> 
> Hi all,
> 
> On January 19th I posted a call for adoption of the OAuth 2.0 for Native
> Apps specification, see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15400.html
> 
> There was very positive feedback during the Yokohama IETF meeting to
> work on this document in the OAuth working group. More than 10 persons
> responded positively to the call on the mailing list as well.
> 
> Several persons provided additional input for content changes during the
> call and here are the relevant links:
> http://www.ietf.org/mail-archive/web/oauth/current/msg15434.html
> http://www.ietf.org/mail-archive/web/oauth/current/msg15435.html
> http://www.ietf.org/mail-archive/web/oauth/current/msg15438.html
> 
> Tony also noted that this document should become an Experimental RFC
> rather than a Standards Track RFC. The chairs will consult with the
> Security Area directors on this issue.
> 
> To conclude, based on the call  will
> become the starting point for work in OAuth. Please submit the document
> as draft-ietf-oauth-native-apps-00.txt.
> 
> Ciao
> Hannes & Derek
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

[Justin Richer]

Hannes, thanks for your clarification.

I believe what we need is more working group involvement and feedback and not 
more authors on the document. As I’ve explained off-list and on several times, 
the document didn’t move forward in the last year because there hadn’t been any 
discussion or reason to move it forward. Now I have a reason to move it forward 
on my own, so I’ve contributed the implementation and updated text.

I’m of course happy to have additional authors if they’re interested in 
contributing to the draft text itself and helping to edit it. I’m surprised 
that there are people willing to edit the document when there haven’t been any 
public discussions of it to date, so I would suggest that as a WG we start 
there.

 — Justin

> On Feb 4, 2016, at 2:14 PM, Hannes Tschofenig  
> wrote:
> 
> Hi Justin,
> 
> you have not been removed from the author list of the HTTP signing
> draft. Unfortunate wording in my mail below may have given you that
> impression but I would like to bring some additional people on board who
> expressed interest.
> 
> As you know, it is also great if we get new people to volunteer to do
> work when we get stuck.
> 
> Since there needs to be "space" on the author list I would at least
> remove myself from the author list of the HTTP signing document.
> 
> Ciao
> Hannes
> 
> PS: I saw your post regarding the PoP implementation. Thanks for doing
> that work. It is highly appreciated!
> 
> On 01/19/2016 05:34 PM, Justin Richer wrote:
>> Well that’s interesting: I was unaware I was being removed as the author
>> of the HTTP signing draft. This is especially surprising after the
>> presentation I gave at Yokohama about this topic. The draft hasn’t been
>> updated because there’s not really been any discussion on it here in the
>> group to drive an update, and I’m not one to artificially publish a new
>> draft with the same content and a new date just to avoid the “expired”
>> tag in the repository.
>> 
>> To see the direction I proposed that we go in at Yokohama, check my
>> slides here:
>> 
>> https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf
>> 
>> Again, I got no real feedback on this and there was no discussion on the
>> list. Even so, I’m implementing this in a Node.js application anyway
>> that I plan to post back to the group here when it’s done.
>> 
>> — Justin
>> 
>>> On Jan 19, 2016, at 6:45 AM, Hannes Tschofenig
>>> mailto:hannes.tschofe...@gmx.net>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I wanted to drop a high level message about possible next steps for the
>>> PoP work.
>>> 
>>> As you have seen from my status update, see
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the
>>> PoP architecture document was already in IESG processing but I have had
>>> asked Kathleen to delay the publication given that we ran into scoping
>>> issues, as discussed on the list. See
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html
>>> 
>>> The change of scope related to desire to not just binding a key to the
>>> access token but also to other parts of the OAuth system to avoid cases
>>> where an attacker can just obtain attack other parts of the system
>>> instead (for example, by obtaining an bearer-based refresh token to then
>>> obtain a new PoP access token).
>>> 
>>> The recently discovered security problems tell us that we need to
>>> simplify our solutions a bit as well to ensure that we get the security
>>> analysed properly. More options means more time to analyse all the
>>> different options.
>>> 
>>> What does this mean to simplify when I talk about expanding the scope in
>>> the earlier paragraph?
>>> 
>>> I am suggesting to
>>> 
>>> * to consider focusing on a public key-based only solution for the
>>> web/smart phone app space. (The ACE working group will have to develop a
>>> symmetric key-based version on their own, if desired.)
>>> 
>>> * to extend the support of PoP token functionality throughout the entire
>>> solution. This means that we have to include support for a asymmetric
>>> version of PKCE into account (which had been discussed in the group
>>> already earlier already).
>>> 
>>> * to define at least a TLS-based security security solution for the
>>> communication between the client and the resource server.
>>> 
>>> * to rethink the work on the application layer security solution. The
>>> HTTP signing draft, which defines the application layer security
>>> solution for use between the client and the resource server, has expired
>>> and we will have to find new authors. I believe we got stuck a bit.
>>> Luckily new persons came along and volunteered to help, namely Fredrik
>>> Ljunggren and Jakob Schlyter. Nevertheless, the group will have to judge
>>> whether a newly developed application layer security solution is
>>> promising. My impression is that it is a very difficult to come up with
>>> a solution that satisfies the security requirements and, at the same
>>> time, also takes the deployment stat

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

[John Bradley]

I would personally be fine with just the .well-known discovery.

I think in the earlier thread I was trying to make the argument that webfinger 
discovery is going to be based on the API that you are looking for and not 
generic OAuth.

A generic OAuth rel per user doesn’t really make sense.   A client is looking 
for a OpenID Connect identity provider ,  a photo sharing service,  a calendar 
service etc.

Given the way UMA works by starting at the resource I would expect that a 
client would discover a medical records service and make a request to the API 
and get back a RPT token and location of the UMA server to get a AT.   I don’t 
quite know what good knowing the UMA server would be unless it supported 
discovery (Talked about I think) however that might be circular.

Let the protocols define how to use WebFinger and define the rel and we can 
pick up from there.

We should adopt the current dock as a starting point.  

John B.

> On Feb 4, 2016, at 9:34 PM, Justin Richer  wrote:
> 
> +1, if we define a webfinger/rel at all.
> 
> I would rather we just define the service discovery document, the thing that 
> lives under .well-known.
> 
> — Justin
> 
> 
>> On Feb 4, 2016, at 4:01 AM, Roland Hedberg  wrote:
>> 
>> +1
>> 
>>> 4 feb 2016 kl. 08:10 skrev Phil Hunt :
>>> 
>>> +1 for adoption.
>>> 
>>> However I would like a rel value distinct from OpenID (see separate email). 
>>> While the mechanics of discovery is the same, I believe some clients will 
>>> want to distinguish between OAuth AS’s and OIDC OPs.  Further, I would 
>>> expect over time that different discovery features may be required. Locking 
>>> them together seems like a pre-mature or rush choice.
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> phil.h...@oracle.com
>>> 
>>> 
>>> 
>>> 
>>> 
 On Feb 3, 2016, at 10:44 PM, William Denniss  wrote:
 
 +1 for adoption of this document by the working group
 
 On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones  
 wrote:
 I support adoption of this document by the working group.  I'll note that 
 elements of this specification are already in production use by multiple 
 parties.
 
   -- Mike
 
 -Original Message-
 From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
 Sent: Tuesday, January 19, 2016 3:49 AM
 To: oauth@ietf.org
 Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery
 
 Hi all,
 
 this is the call for adoption of OAuth 2.0 Discovery, see
 https://tools.ietf.org/html/draft-jones-oauth-discovery-00
 
 Please let us know by Feb 2nd whether you accept / object to the adoption 
 of this document as a starting point for work in the OAuth working group.
 
 Note: If you already stated your opinion at the IETF meeting in Yokohama 
 then you don't need to re-state your opinion, if you want.
 
 The feedback at the Yokohama IETF meeting was the following: 19 for / zero 
 against / 4 persons need more information.
 
 Ciao
 Hannes & Derek
 
 ___
 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 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

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

[Phil Hunt]

I thought about this when doing the SCIM discovery document. Initially I only 
had cases for plain ./well-known.  But I found there are two types of clients. 
I decided later that mobile and web apps have different needs.

E.g. a mobile app might ask anonymously or on behalf of an already 
authenticated subject.  ./well-known works fine.

A web app that works on behalf of multiple users (e.g. is an OIDC client), 
might find that the answer varies based on the user acnt it wants to ask on 
behalf of.  The webfinger?rel=oauth&acnt: model works much better.

Phil

@independentid
www.independentid.com phil.h...@oracle.com 






> On Feb 4, 2016, at 4:34 PM, Justin Richer  wrote:
> 
> +1, if we define a webfinger/rel at all.
> 
> I would rather we just define the service discovery document, the thing that 
> lives under .well-known.
> 
> — Justin
> 
> 
>> On Feb 4, 2016, at 4:01 AM, Roland Hedberg  wrote:
>> 
>> +1
>> 
>>> 4 feb 2016 kl. 08:10 skrev Phil Hunt :
>>> 
>>> +1 for adoption.
>>> 
>>> However I would like a rel value distinct from OpenID (see separate email). 
>>> While the mechanics of discovery is the same, I believe some clients will 
>>> want to distinguish between OAuth AS’s and OIDC OPs.  Further, I would 
>>> expect over time that different discovery features may be required. Locking 
>>> them together seems like a pre-mature or rush choice.
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> phil.h...@oracle.com
>>> 
>>> 
>>> 
>>> 
>>> 
 On Feb 3, 2016, at 10:44 PM, William Denniss  wrote:
 
 +1 for adoption of this document by the working group
 
 On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones  
 wrote:
 I support adoption of this document by the working group.  I'll note that 
 elements of this specification are already in production use by multiple 
 parties.
 
   -- Mike
 
 -Original Message-
 From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
 Sent: Tuesday, January 19, 2016 3:49 AM
 To: oauth@ietf.org
 Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery
 
 Hi all,
 
 this is the call for adoption of OAuth 2.0 Discovery, see
 https://tools.ietf.org/html/draft-jones-oauth-discovery-00
 
 Please let us know by Feb 2nd whether you accept / object to the adoption 
 of this document as a starting point for work in the OAuth working group.
 
 Note: If you already stated your opinion at the IETF meeting in Yokohama 
 then you don't need to re-state your opinion, if you want.
 
 The feedback at the Yokohama IETF meeting was the following: 19 for / zero 
 against / 4 persons need more information.
 
 Ciao
 Hannes & Derek
 
 ___
 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 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] Call for Adoption: OAuth 2.0 Discovery

[Justin Richer]

+1, if we define a webfinger/rel at all.

I would rather we just define the service discovery document, the thing that 
lives under .well-known.

 — Justin


> On Feb 4, 2016, at 4:01 AM, Roland Hedberg  wrote:
> 
> +1
> 
>> 4 feb 2016 kl. 08:10 skrev Phil Hunt :
>> 
>> +1 for adoption.
>> 
>> However I would like a rel value distinct from OpenID (see separate email). 
>> While the mechanics of discovery is the same, I believe some clients will 
>> want to distinguish between OAuth AS’s and OIDC OPs.  Further, I would 
>> expect over time that different discovery features may be required. Locking 
>> them together seems like a pre-mature or rush choice.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>> 
>> 
>> 
>> 
>> 
>>> On Feb 3, 2016, at 10:44 PM, William Denniss  wrote:
>>> 
>>> +1 for adoption of this document by the working group
>>> 
>>> On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones  
>>> wrote:
>>> I support adoption of this document by the working group.  I'll note that 
>>> elements of this specification are already in production use by multiple 
>>> parties.
>>> 
>>>-- Mike
>>> 
>>> -Original Message-
>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>>> Sent: Tuesday, January 19, 2016 3:49 AM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery
>>> 
>>> Hi all,
>>> 
>>> this is the call for adoption of OAuth 2.0 Discovery, see
>>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00
>>> 
>>> Please let us know by Feb 2nd whether you accept / object to the adoption 
>>> of this document as a starting point for work in the OAuth working group.
>>> 
>>> Note: If you already stated your opinion at the IETF meeting in Yokohama 
>>> then you don't need to re-state your opinion, if you want.
>>> 
>>> The feedback at the Yokohama IETF meeting was the following: 19 for / zero 
>>> against / 4 persons need more information.
>>> 
>>> Ciao
>>> Hannes & Derek
>>> 
>>> ___
>>> 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 mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-00.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 Working Group of 
the IETF.

Title   : OAuth 2.0 for Native Apps
Authors : William Denniss
  John Bradley
Filename: draft-ietf-oauth-native-apps-00.txt
Pages   : 16
Date: 2016-02-04

Abstract:
   OAuth 2.0 authorization requests from native apps should only be made
   through external user-agents such as the system browser (including
   via an in-app browser tab).  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-00


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] I-D Action: draft-ietf-oauth-closing-redirectors-00.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 Working Group of 
the IETF.

Title   : OAuth 2.0 Security: Closing Open Redirectors in OAuth
Authors : John Bradley
  Antonio Sanso
  Hannes Tschofenig
Filename: draft-ietf-oauth-closing-redirectors-00.txt
Pages   : 7
Date: 2016-02-04

Abstract:
   This document gives additional security considerations for OAuth,
   beyond those in the OAuth 2.0 specification and in the OAuth 2.0
   Threat Model and Security Considerations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-closing-redirectors/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00


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] OAuth 2.0 Mix-Up Mitigation: My Impressions

[Hannes Tschofenig]

Hi all,

when I posted the call for adoption of the 'OAuth 2.0 Mix-Up Mitigation'
solution  I wasn't expecting such a
heavy debate on the list. While the call for adoption is still ongoing I
would like to share my view as someone who has to judge consensus in a
few days together with Derek.

Regardless of where we are with respect to oauth-meta vs.
draft-jones-oauth-mix-up-mitigation we should keep an eye on the threats
we are trying to address (and we have to document them).

Here is how I would summarize the situation after reviewing the drafts,
blog posts and various emails sent to the list.


We have two types of threats:

#1: Threat described in the papers referenced in my email to the list
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html

The attack assumes that '... the presence of a network attacker who can
manipulate the request in which the user sends her identity to the RP as
well as the corresponding response to this request ...' (see page 15 of
http://arxiv.org/pdf/1601.01229v2.pdf).

I believe that this threat is well documented (at least in the paper).

#2: Cut-and-Paste Attacks

Here things get a bit more difficult since the threat is less well
described. In Section 7.3 of
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 Mike
makes an attempt to describe the attack and refers to Section 4.4.1.13
of RFC 6819, which talks about 'Code Substitution'. I am not convinced
that the description in RFC 6819 exactly matches the intention of
Section 7.3 of draft-jones-oauth-mix-up-mitigation-01 but I might be
misinterpreting.

Anyway, here is a copy-and-paste from the draft:

   A "cut-and-paste" attack is performed
   by the attacker creating what appears to be a legitimate
   authorization response, but that substitutes some of the response
   parameter values with values of the attacker's choosing.

Clearly, this attack makes different assumptions than what is stated in
the papers listed under item #1. It appears that the attacker will have
to be on the users device /browser itself. If that's true then the text
needs to state that.

Nat also provides a description of a similar attack in his blog post
under the name of 'Code Phishing' at
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
In his description the attacker assumption is that the developer is
tricked into re-configuring the token endpoint so that the attacker is
able to obtain the authorization code.

While I believe the group is well advised to tackle the attack described
in item #1 to mitigate the attacks discovered late last year. I am
curious whether the group also sees the mitigation of threat #2 in scope
of this document. In some sense, one could argue that cut-and-paste is
more generic and a concern also for those cases where an OAuth client
does not talk to multiple ASs.

So, here are my questions:

- Can we describe the threat #2 in more details and by stating the
assumptions about the attacker?

I believe that this is important for understanding the attack within the
participants of the group but also for those who stumble over our
documents. Once we have a good description we should move on and answer
the next two questions:

- Should the document describe mitigations for attacks #1 and #2?

- Should the solution mandate a solution for dealing with both attacks?

Finally, we can talk about the details of the attack mitigation itself.

As far as the work from Mike (oauth-mix-up-mitigation) and Nat
(oauth-meta) is concerned Derek and I will find ways to ensure that the
prior work by all involved participants is appropriately attributed and
acknowledged!

Ciao
Hannes



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

[OAUTH-WG] Encoding claims in the OAuth 2 state parameter using a JWT and Stateless Client Identifier for OAuth 2: Call for Adoption Finalized

[Hannes Tschofenig]

Hi all,

On January 19th I posted a call for adoption of the 'Encoding claims in
the OAuth 2 state parameter using a JWT' and of the 'Stateless Client
Identifier for OAuth 2' specifications, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15406.html
http://www.ietf.org/mail-archive/web/oauth/current/msg15407.html

Only Mike and John responded to the call on the mailing list. The lack
of feedback may indicate that this is not important or that the value of
the document has not been understood. Maybe there have also been too
many other items on the plate (and given the list traffic I have seen in
the last few weeks on the OAuth list this wouldn't be such a far-fetched
thought).

Given the feedback I have received privately I have a hard time to
believe that there is no interest in these two items.

Here is what we will do: we will talk to the document authors in an
attempt to reposition the documents (and maybe change title, abstract
and intro). Then, we will come back to the group to gauge the reaction.

Ciao
Hannes & Derek





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

[OAUTH-WG] OAuth 2.0 Device Flow: Call for Adoption Finalized

[Hannes Tschofenig]

Hi all,

On January 19th I posted a call for adoption of the OAuth 2.0 Device
Flow specification, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15403.html

The feedback at the Yokohama IETF meeting was very positive and also the
response on the mailing list was positive.

To conclude, based on the call  will
become the starting point for work in the OAuth working group. Please
submit the document as draft-ietf-oauth-device-flow-00.txt.

Ciao
Hannes & Derek





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

[OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

[Hannes Tschofenig]

Hi all,

On January 19th I posted a call for adoption of the Authentication
Method Reference Values specification, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html

What surprised us is that this work is conceptually very simple: we
define new claims and create a registry with new values. Not a big deal
but that's not what the feedback from the Yokohama IETF meeting and the
subsequent call for adoption on the list shows. The feedback lead to
mixed feelings and it is a bit difficult for Derek and myself to judge
consensus.

Let me tell you what we see from the comments on the list.

In his review at
http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html James
Manger asks for significant changes. Among other things, he wants to
remove one of the claims. He provides a detailed review and actionable
items.

William Denniss believes the document is ready for adoption but agrees
with some of the comments from James. Here is his review:
http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html

Justin is certainly the reviewer with the strongest opinion. Here is one
of his posts:
http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html

Among all concerns Justin expressed the following one is actually
actionable IMHO: Justin is worried that reporting how a person
authenticated to an authorization endpoint and encouraging people to use
OAuth for authentication is a fine line. He believes that this document
leads readers to believe the latter.

John agrees with Justin in
http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html that we
need to make sure that people are not mislead about the intention of the
document. John also provides additional comments in this post to the
list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html
Most of them require more than just editing work. For example, methods
listed are really not useful,

Phil agrees with the document adoption but has some remarks about the
registry although he does not propose specific text. His review is here:
http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html

With my co-chair hat on: I just wanted to clarify that registering
claims (and values within those claims) is within the scope of the OAuth
working group. We standardized the JWT in this group and we are also
chartered to standardize claims, as we are currently doing with various
drafts. Not standardizing JWT in the IETF would have lead to reduced
interoperability and less security. I have no doubts that was a wrong
decision.

In its current form, there is not enough support to have this document
as a WG item.

We believe that the document authors should address some of the easier
comments and submit a new version. This would allow us to reach out to
those who had expressed concerns about the scope of the document to
re-evaluate their decision. A new draft version should at least address
the following issues:

 * Clarify that this document is not an encouragement for using OAuth as
an authentication protocol. I believe that this would address some of
the concerns raised by Justin and John.

 * Change the registry policy, which would address one of the comments
from James, William, and Phil.

Various other items require discussion since they are more difficult to
address. For example, John noted that he does not like the use of
request parameters. Unfortunately, no alternative is offered. I urge
John to provide an alternative proposal, if there is one. Also, the
remark that the values are meaningless could be countered with an
alternative proposal. James wanted to remove the "amr_values" parameter.
Is this what others want as well?

After these items have been addressed we believe that more folks in the
group will support the document.

Ciao
Hannes & Derek





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

[OAUTH-WG] OAuth Open Redirector: Call for Adoption Finalized

[Hannes Tschofenig]

Hi all,

On January 19th I posted a call for adoption of the OAuth Open
Redirector specification, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15401.html

There was positive feedback during the Yokohama IETF meeting to work on
security fixes and more than 10 persons responded positively to the call
on the mailing list. As requested, we will have to change the title of
the document to avoid given the impression that we want to use OAuth to
deploy open redirectors.

To conclude, based on the call 
will become the starting point for work in the OAuth working group.
Please submit the document as draft-ietf-oauth-open-redirector-00.txt.

Ciao
Hannes & Derek





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

[OAUTH-WG] OAuth 2.0 for Native Apps: Call for Adoption Finalized

[Hannes Tschofenig]

Hi all,

On January 19th I posted a call for adoption of the OAuth 2.0 for Native
Apps specification, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15400.html

There was very positive feedback during the Yokohama IETF meeting to
work on this document in the OAuth working group. More than 10 persons
responded positively to the call on the mailing list as well.

Several persons provided additional input for content changes during the
call and here are the relevant links:
http://www.ietf.org/mail-archive/web/oauth/current/msg15434.html
http://www.ietf.org/mail-archive/web/oauth/current/msg15435.html
http://www.ietf.org/mail-archive/web/oauth/current/msg15438.html

Tony also noted that this document should become an Experimental RFC
rather than a Standards Track RFC. The chairs will consult with the
Security Area directors on this issue.

To conclude, based on the call  will
become the starting point for work in OAuth. Please submit the document
as draft-ietf-oauth-native-apps-00.txt.

Ciao
Hannes & Derek





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

[OAUTH-WG] OAuth 2.0 Discovery: Call for Adoption Finalized

[Hannes Tschofenig]

Hi all,

On January 19th I posted a call for adoption of the discovery spec, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15404.html

The feedback at the Yokohama IETF meeting was very positive and also the
response on the mailing list was positive.

Various people, Phil, Brian, and Torsten, used the call for adoption to
also provide comments, which will have to be resolved.

For completeness I add the most important links here:
http://www.ietf.org/mail-archive/web/oauth/current/msg15662.html
http://www.ietf.org/mail-archive/web/oauth/current/msg15674.html
http://www.ietf.org/mail-archive/web/oauth/current/msg15663.html

Comments regarding metadata values for revocation, introspection, and
PKCE raised by NAT have already been incorporated during the call for
adoption, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15644.html

There may, however, still be further work, as explained here:
http://www.ietf.org/mail-archive/web/oauth/current/msg15651.html

To conclude,  will become the starting
point for an OAuth discovery solution. Please submit the document as
draft-ietf-oauth-discovery-00.txt.

Ciao
Hannes & Derek



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

Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

[Hannes Tschofenig]

Hi Kepeng,

thanks for your input.

> Yes, I am interested in this solution direction.
> 
> Sender Constrained JWT is already indicated in PoP architecture document
> as one of the solutions.

That is correct.

> 
> If we don’t specify it in detail, the solution set is incomplete.

That's unfortunately wrong. The Sender Constrained JWT is one solution
that essentially provides the same functionality to the PoP token.

> 
> And there will be interoperability issues when people implement it in
> different ways.
That's correct. However, the group decided to go on a different route,
namely the PoP token route and if we can reduce the number of options
that people use to implement the same functionality then that's actually
better in the long run.

Ciao
Hannes

> 
> Kind Regards
> Kepeng
> 
> 在 19/1/16 7:45 pm， "Hannes Tschofenig"  写入:
> 
>> Hi all,
>>
>> I wanted to drop a high level message about possible next steps for the
>> PoP work.
>>
>> As you have seen from my status update, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the
>> PoP architecture document was already in IESG processing but I have had
>> asked Kathleen to delay the publication given that we ran into scoping
>> issues, as discussed on the list. See
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html
>>
>> The change of scope related to desire to not just binding a key to the
>> access token but also to other parts of the OAuth system to avoid cases
>> where an attacker can just obtain attack other parts of the system
>> instead (for example, by obtaining an bearer-based refresh token to then
>> obtain a new PoP access token).
>>
>> The recently discovered security problems tell us that we need to
>> simplify our solutions a bit as well to ensure that we get the security
>> analysed properly. More options means more time to analyse all the
>> different options.
>>
>> What does this mean to simplify when I talk about expanding the scope in
>> the earlier paragraph?
>>
>> I am suggesting to
>>
>> * to consider focusing on a public key-based only solution for the
>> web/smart phone app space. (The ACE working group will have to develop a
>> symmetric key-based version on their own, if desired.)
>>
>> * to extend the support of PoP token functionality throughout the entire
>> solution. This means that we have to include support for a asymmetric
>> version of PKCE into account (which had been discussed in the group
>> already earlier already).
>>
>> * to define at least a TLS-based security security solution for the
>> communication between the client and the resource server.
>>
>> * to rethink the work on the application layer security solution. The
>> HTTP signing draft, which defines the application layer security
>> solution for use between the client and the resource server, has expired
>> and we will have to find new authors. I believe we got stuck a bit.
>> Luckily new persons came along and volunteered to help, namely Fredrik
>> Ljunggren and Jakob Schlyter. Nevertheless, the group will have to judge
>> whether a newly developed application layer security solution is
>> promising. My impression is that it is a very difficult to come up with
>> a solution that satisfies the security requirements and, at the same
>> time, also takes the deployment status of proxies and other middleware
>> into account.
>>
>> * to make a decision about other extensions. Nat and Kepeng submitted
>> the Sender Constrained JWT for OAuth2 2.0 document, see
>> https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06
>> We asked the working group for feedback during IETF #93 and we couldn't
>> get enough feedback at that time. Please give us feedback whether you
>> are interested in exploring that solution direction as part of this
>> process. Today, we don't have enough indication of interest for working
>> on that solution direction.
>>
>> Before making any changes to the PoP document set we would like to hear
>> your thoughts.
>>
>> Ciao
>> Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 



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

Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

[Hannes Tschofenig]

Hi Justin,

you have not been removed from the author list of the HTTP signing
draft. Unfortunate wording in my mail below may have given you that
impression but I would like to bring some additional people on board who
expressed interest.

As you know, it is also great if we get new people to volunteer to do
work when we get stuck.

Since there needs to be "space" on the author list I would at least
remove myself from the author list of the HTTP signing document.

Ciao
Hannes

PS: I saw your post regarding the PoP implementation. Thanks for doing
that work. It is highly appreciated!

On 01/19/2016 05:34 PM, Justin Richer wrote:
> Well that’s interesting: I was unaware I was being removed as the author
> of the HTTP signing draft. This is especially surprising after the
> presentation I gave at Yokohama about this topic. The draft hasn’t been
> updated because there’s not really been any discussion on it here in the
> group to drive an update, and I’m not one to artificially publish a new
> draft with the same content and a new date just to avoid the “expired”
> tag in the repository. 
> 
> To see the direction I proposed that we go in at Yokohama, check my
> slides here:
> 
> https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf
> 
> Again, I got no real feedback on this and there was no discussion on the
> list. Even so, I’m implementing this in a Node.js application anyway
> that I plan to post back to the group here when it’s done. 
> 
>  — Justin
> 
>> On Jan 19, 2016, at 6:45 AM, Hannes Tschofenig
>> mailto:hannes.tschofe...@gmx.net>> wrote:
>>
>> Hi all,
>>
>> I wanted to drop a high level message about possible next steps for the
>> PoP work.
>>
>> As you have seen from my status update, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the
>> PoP architecture document was already in IESG processing but I have had
>> asked Kathleen to delay the publication given that we ran into scoping
>> issues, as discussed on the list. See
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html
>>
>> The change of scope related to desire to not just binding a key to the
>> access token but also to other parts of the OAuth system to avoid cases
>> where an attacker can just obtain attack other parts of the system
>> instead (for example, by obtaining an bearer-based refresh token to then
>> obtain a new PoP access token).
>>
>> The recently discovered security problems tell us that we need to
>> simplify our solutions a bit as well to ensure that we get the security
>> analysed properly. More options means more time to analyse all the
>> different options.
>>
>> What does this mean to simplify when I talk about expanding the scope in
>> the earlier paragraph?
>>
>> I am suggesting to
>>
>> * to consider focusing on a public key-based only solution for the
>> web/smart phone app space. (The ACE working group will have to develop a
>> symmetric key-based version on their own, if desired.)
>>
>> * to extend the support of PoP token functionality throughout the entire
>> solution. This means that we have to include support for a asymmetric
>> version of PKCE into account (which had been discussed in the group
>> already earlier already).
>>
>> * to define at least a TLS-based security security solution for the
>> communication between the client and the resource server.
>>
>> * to rethink the work on the application layer security solution. The
>> HTTP signing draft, which defines the application layer security
>> solution for use between the client and the resource server, has expired
>> and we will have to find new authors. I believe we got stuck a bit.
>> Luckily new persons came along and volunteered to help, namely Fredrik
>> Ljunggren and Jakob Schlyter. Nevertheless, the group will have to judge
>> whether a newly developed application layer security solution is
>> promising. My impression is that it is a very difficult to come up with
>> a solution that satisfies the security requirements and, at the same
>> time, also takes the deployment status of proxies and other middleware
>> into account.
>>
>> * to make a decision about other extensions. Nat and Kepeng submitted
>> the Sender Constrained JWT for OAuth2 2.0 document, see
>> https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06
>> We asked the working group for feedback during IETF #93 and we couldn't
>> get enough feedback at that time. Please give us feedback whether you
>> are interested in exploring that solution direction as part of this
>> process. Today, we don't have enough indication of interest for working
>> on that solution direction.
>>
>> Before making any changes to the PoP document set we would like to hear
>> your thoughts.
>>
>> Ciao
>> Hannes
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 



signature.asc
Description: OpenPGP digital signature

Re: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2

[John Bradley]

I support it.

I have always thought of this as informational.  It is not the only way to do 
it, and has no real interoperability impact.

John B.
> On Feb 4, 2016, at 3:29 AM, Mike Jones  wrote:
> 
> I support adoption of this document by the working group as either an 
> experimental or information specification.
> 
>   -- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, January 19, 2016 4:05 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2
> 
> Hi all,
> 
> this is the call for adoption of Stateless Client Identifier for OAuth 2, see
> https://tools.ietf.org/html/draft-bradley-oauth-stateless-client-id-02
> 
> Please let us know by Feb 2nd whether you accept / object to the adoption of 
> this document as a starting point for work in the OAuth working group.
> 
> Ciao
> Hannes & Derek
> 
> 
> ___
> 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] Call for Adoption: Encoding claims in the OAuth 2 state parameter using a JWT

[John Bradley]

I support this too if I haven't already.
> On Jan 19, 2016, at 8:50 AM, Hannes Tschofenig  
> wrote:
> 
> 
> Hi all,
> 
> this is the call for adoption of Encoding claims in the OAuth 2 state
> parameter using a JWT, see
> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-05
> 
> Please let us know by Feb 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
> 
> Ciao
> Hannes & Derek
> 
> ___
> 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] [Ace] Questions about OAuth and DTLS

[John Bradley]

In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution

The proof key is included in the access token or provided out of band. 

The proof mechanism to the RS is what would determine if the key type needs to 
match DTLS .  
If the proof is DTLS then they would need to match.  

POP will have different presentment mechanisms such as signing the payload or 
binding to mutual TLS client auth.

For a symmetric key you would encrypt it in the Access token with a Key known 
to the RS so only the token decryption key needs to be managed out of band.

John B.

> On Feb 4, 2016, at 11:58 AM, Ludwig Seitz  wrote:
> 
> Thank you Michael! Comments inline.
> 
> /Ludwig
> 
> On 02/04/2016 03:31 PM, Michael Richardson wrote:
>> 
>> Ludwig Seitz  wrote:
>> > Assuming we are using (D)TLS to secure the connection between C and RS,
>> > assuming further that we are using proof-of-possession tokens [2],
>> > i.e. tokens linked to a key, of which the client needs to prove 
>> possession in
>> > order for the RS to accept the token.
>> 
>> > Do we need to support cases, where the type of key used with DTLS does 
>> not
>> > match the type of key in the PoP-token?
>> 
>> > Example:
>> 
>> > The client uses its raw public key as proof of possession, but the DTLS
>> > connection C - RS is secured with a pre-shared symmetric key.
>> 
>> > Is that a realistic use case?
>> 
>> Before I agree that it's unrealistic, I think it's worth going out of charter
>> scope and ask how much these two credentials were created/distributed.
>> 
>> I think that in this case, the pre-shared symmetric key is initialized
>> through some out-of-band (perhaps human mediated?) process, while the raw
>> public key did not need any other pre-arrangement.
> 
> Actually even the raw public key needs to be provisioned out-of-band to those 
> supposed to trust it for authentication.
> 
>> 
>> So my question is then: could the out-of-band process have pre-exchanged the
>> raw public key (and the RS's key/certificate!) as well?
>> 
> 
> Short answer: Yes but only to the AS not to the client(s).
> 
> Long answer: I am laboring under the assumption that the AS not only provides 
> the OAuth token and the corresponding PoP key to the client, but also some 
> information on the communication security protocols that the RS supports. 
> Furthermore the AS facilitates the establishment of a security context 
> between client and RS by providing things such as a (D)TLS-PSK or the RS's 
> raw public key, depending on the (D)TLS mode that the RS is going to support. 
> Thus individual clients would not, a-priori, know the raw public key of a RS, 
> but would be able to get that information from the AS.
> 
> -- 
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
> 
> Phone +46(0)70 349 9251
> http://www.sics.se
> 
> ___
> 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] [Ace] Questions about OAuth and DTLS

[Ludwig Seitz]

Thank you Michael! Comments inline.

/Ludwig

On 02/04/2016 03:31 PM, Michael Richardson wrote:


Ludwig Seitz  wrote:
 > Assuming we are using (D)TLS to secure the connection between C and RS,
 > assuming further that we are using proof-of-possession tokens [2],
 > i.e. tokens linked to a key, of which the client needs to prove 
possession in
 > order for the RS to accept the token.

 > Do we need to support cases, where the type of key used with DTLS does 
not
 > match the type of key in the PoP-token?

 > Example:

 > The client uses its raw public key as proof of possession, but the DTLS
 > connection C - RS is secured with a pre-shared symmetric key.

 > Is that a realistic use case?

Before I agree that it's unrealistic, I think it's worth going out of charter
scope and ask how much these two credentials were created/distributed.

I think that in this case, the pre-shared symmetric key is initialized
through some out-of-band (perhaps human mediated?) process, while the raw
public key did not need any other pre-arrangement.


Actually even the raw public key needs to be provisioned out-of-band to 
those supposed to trust it for authentication.




So my question is then: could the out-of-band process have pre-exchanged the
raw public key (and the RS's key/certificate!) as well?



Short answer: Yes but only to the AS not to the client(s).

Long answer: I am laboring under the assumption that the AS not only 
provides the OAuth token and the corresponding PoP key to the client, 
but also some information on the communication security protocols that 
the RS supports. Furthermore the AS facilitates the establishment of a 
security context between client and RS by providing things such as a 
(D)TLS-PSK or the RS's raw public key, depending on the (D)TLS mode that 
the RS is going to support. Thus individual clients would not, 
a-priori, know the raw public key of a RS, but would be able to get that 
information from the AS.


--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

[Michael Richardson]

Ludwig Seitz  wrote:
> Assuming we are using (D)TLS to secure the connection between C and RS,
> assuming further that we are using proof-of-possession tokens [2],
> i.e. tokens linked to a key, of which the client needs to prove 
possession in
> order for the RS to accept the token.

> Do we need to support cases, where the type of key used with DTLS does not
> match the type of key in the PoP-token?

> Example:

> The client uses its raw public key as proof of possession, but the DTLS
> connection C - RS is secured with a pre-shared symmetric key.

> Is that a realistic use case?

Before I agree that it's unrealistic, I think it's worth going out of charter
scope and ask how much these two credentials were created/distributed.

I think that in this case, the pre-shared symmetric key is initialized
through some out-of-band (perhaps human mediated?) process, while the raw
public key did not need any other pre-arrangement.

So my question is then: could the out-of-band process have pre-exchanged the
raw public key (and the RS's key/certificate!) as well?

> It would simplify the DTLS cases a lot, if I could just require the token 
and
> the DTLS session to use the same type of key. For starters we could use 
DTLS
> handshake to perform the proof-of-possession.

I agree, that it would be better.
(I'm also concerned that we not fail into where IKEv1 did: with weak PSK
being the only interoperable mechanism...)

> Would there be any security issues with using the PoP key in the DTLS
> handshake?

> I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279 
and
> raw public PoP keys as client-authentication key as in
> RFC7250.

Just because I had to look it up...
4279 - Pre-Shared Key Ciphersuites for Transport Layer Security
7250 - Using Raw Public Keys in Transport Layer Security

I thought perhaps it was some more specific mechanism...

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





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

Re: [OAUTH-WG] OAuth PoP Implementation

[Justin Richer]

Hi Erik, responses inline.

On 2/4/2016 4:20 AM, Erik Wahlström wrote:

Hi,

Good work Justin.

I’ve also implemented (parts) of PoP tokens for the ACE WG oauth2 
draft and made a lot of the same assumptions.


See below.


On 03 Feb 2016, at 23:47, Justin Richer > wrote:


Hi Everyone,

I recently decided to put together an end to end implementation of at 
least part of the proposed OAuth specs. I haven’t seen any other 
implementations of the whole system, so I wanted to see how viable 
this whole idea really. It’s done in Node.js (using Express.js) and 
it’s on GitHub here:


https://github.com/jricher/oauth-pop

The client requests a token from the auth server using the auth code 
flow, nothing special here.


I use client creds but nothing special there either.


Should be generally identical to bearer tokens, so that's good to hear. :)



The AS generates a random-value access token and a 2048-bit RSA key 
in JWK format. It sends the keypair to the client alongside the 
token. This step varies from the pop-key-distribution draft in the 
following ways:


 - Parameter name is “access_token_key” instead of just “key”, 
partially to allow us to redefine keys for other tokens like refresh 
tokens in the future.


My implementation uses “key” but it would be a quick change.


Yeah, it's a little bikeshedding but I think "access_token_key" is 
clearer and the WG should go in that direction. It'd be a trivial change 
for my code to change to "key" too if we went that way, it's syntax.


I’ve actually have a problem naming a PoP based access token. Is it a 
PoP token or an access token?


PoP tokens really have two parts: the access token itself, which is 
analogous to the bearer token, and the key associated with it. That's 
part of why I went with "access_token" and "access_token_key" above. I 
would still consider a PoP token a kind of access token.




 - Key is returned as a JSON object, not string-encoded. I think we 
should use the fact that JWK is JSON in the response from the token 
endpoint. This makes it difficult for the implicit flow, but we can 
define a separate encoding for that flow. I don’t see a good argument 
for crippling the token endpoint with the limitations of another part 
of the system.


Looking through my code I use a string in the token response, but 
actually use a object in the request if it’s a asymmetric key that 
should be bound to the token and the client generates the keys. Will 
change to object in the response.


I think we should be consistent about this, and I think we should use 
objects where possible (IE, where we're already speaking JSON) and 
strings were not (IE, where we're speaking www-form-encoded).





 - The AS doesn’t return an algorithm, I should probably add that to 
my implementation though.
 - The AS doesn’t let the client pick its keys or algorithms on any 
part of the process but always issues the same key type. I understand 
this to be a valid (if not very friendly) interpretation of the spec.


I have that as a config on the AS for the RS.


Makes sense, and I want to explore the implications of client-supplied 
keys on my implementation too. Just haven't gotten there.






The client takes this token and key and makes a JWS-signed object out 
of them. It adds a few bits about the request, but doesn’t do the 
normalization and hashing of query parameters and headers yet. That’s 
an important bit that still needs to be implemented.


The client sends the signed object (which includes the token) to the 
RS over the authorization header using the “PoP” scheme name, 
mirroring bearer tokens.


(Note: I’ve also updated the HTTP signing draft to incorporate the 
necessary changes above, which were discussed in Yokohama. That 
should be posted to the list already. It’s a lot of rewriting, so 
please check the diffs. Yes, I’m aware that the chairs have stated 
their intent to replace me as editor for the document, but I haven’t 
heard any communication beyond that original announcement so I felt 
it prudent to publish the update anyway.)


Will read through changes asap.



The RS parses the signed object out of the header and extracts the 
token. The RS introspects the token at the AS to get the key (note 
that it doesn’t send the whole signed object, just the access token 
itself).


Same here.

The key is returned in the introspection response as 
“access_token_key”, parallel with the response from the token 
endpoint. It is a JSON object here, too (not encoded as a string). 
Whatever we decide for the token endpoint response we should stay 
consistent for the introspection response.


Just so that I follow correctly, do you return something like this 
(but with access_token_key).


{
"active" : true,
"key" : {"kty”:”…

/ Erik




Yes, exactly like that.



The RS uses the key to validate the JWS’s signature. The RS uses the 
other bits from the introspection callback (scopes, client ID, stuff 
like that) to determine how to r

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-02.txt

[Sergey Beryozkin]

Hi Justin

IMHO it would be useful to consider dropping body hashes and simply 
using JWS filters to convert the body to/from JWS compact or even JSON 
on the fly.
I recall there was some conversation before. People do want to stream 
the data end to end in today's web services. The idea of hashing the 
payload (even if it is arguably a 'small' payload such as 50-60k) won't 
fly in many productions but only in the demos.


JWS Compact is designed to support streaming, and even JWS JSON can do 
the streaming on the way out. Of course the final payload, especially if 
it is JWS compact, won't be easy to analyze when it is on the wire, but 
JWS JSON with base64url disabled can help. The filters will need to 
recreate the original body but it is the same with for ex GZIP.


The headers/queries hash can be linked to the signed body as a JWS 
header and thus protected too...


Not sure if it is convincing...

Cheers, Sergey

On 03/02/16 22:30, internet-dra...@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 Working Group of 
the IETF.

 Title   : A Method for Signing HTTP Requests for OAuth
 Authors : Justin Richer
   John Bradley
   Hannes Tschofenig
Filename: draft-ietf-oauth-signed-http-request-02.txt
Pages   : 13
Date: 2016-02-03

Abstract:
This document a method for offering data origin authentication and
integrity protection of HTTP requests.  To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used.  JWS offers integrity
protection using symmetric as well as asymmetric cryptography.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-02


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




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

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

[OAUTH-WG] Questions about OAuth and DTLS

[Ludwig Seitz]

Hello list(s),

in the process of updating our draft [1] (mainly in reaction to the 
reviewer's comments) I've come up with a question I'd like to put to the 
list (crossposting to OAuth as well, they might have considered that 
already):


Assuming we are using (D)TLS to secure the connection between C and RS, 
assuming further that we are using proof-of-possession tokens [2], i.e. 
tokens linked to a key, of which the client needs to prove possession in 
order for the RS to accept the token.


Do we need to support cases, where the type of key used with DTLS does 
not match the type of key in the PoP-token?


Example:

The client uses its raw public key as proof of possession, but the DTLS 
connection C - RS is secured with a pre-shared symmetric key.


Is that a realistic use case?

It would simplify the DTLS cases a lot, if I could just require the 
token and the DTLS session to use the same type of key. For starters we 
could use DTLS handshake to perform the proof-of-possession.


Would there be any security issues with using the PoP key in the DTLS 
handshake?


I'm thinking of using pre-shared symmetric PoP keys as PSK as in RFC4279 
and raw public PoP keys as client-authentication key as in

RFC7250.


Regards,

Ludwig

[1] https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
[2] https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02


--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70 349 9251
http://www.sics.se



smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth PoP Implementation

[Erik Wahlström]

Hi,

Good work Justin.

I’ve also implemented (parts) of PoP tokens for the ACE WG oauth2 draft and 
made a lot of the same assumptions. 

See below.


> On 03 Feb 2016, at 23:47, Justin Richer  wrote:
> 
> Hi Everyone,
> 
> I recently decided to put together an end to end implementation of at least 
> part of the proposed OAuth specs. I haven’t seen any other implementations of 
> the whole system, so I wanted to see how viable this whole idea really. It’s 
> done in Node.js (using Express.js) and it’s on GitHub here:
> 
> https://github.com/jricher/oauth-pop 
> 
> The client requests a token from the auth server using the auth code flow, 
> nothing special here.

I use client creds but nothing special there either.

> The AS generates a random-value access token and a 2048-bit RSA key in JWK 
> format. It sends the keypair to the client alongside the token. This step 
> varies from the pop-key-distribution draft in the following ways:
> 
>  - Parameter name is “access_token_key” instead of just “key”, partially to 
> allow us to redefine keys for other tokens like refresh tokens in the future.

My implementation uses “key” but it would be a quick change. I’ve actually have 
a problem naming a PoP based access token. Is it a PoP token or an access token?

>  - Key is returned as a JSON object, not string-encoded. I think we should 
> use the fact that JWK is JSON in the response from the token endpoint. This 
> makes it difficult for the implicit flow, but we can define a separate 
> encoding for that flow. I don’t see a good argument for crippling the token 
> endpoint with the limitations of another part of the system.

Looking through my code I use a string in the token response, but actually use 
a object in the request if it’s a asymmetric key that should be bound to the 
token and the client generates the keys. Will change to object in the response.


>  - The AS doesn’t return an algorithm, I should probably add that to my 
> implementation though.
>  - The AS doesn’t let the client pick its keys or algorithms on any part of 
> the process but always issues the same key type. I understand this to be a 
> valid (if not very friendly) interpretation of the spec.

I have that as a config on the AS for the RS.

> 
> The client takes this token and key and makes a JWS-signed object out of 
> them. It adds a few bits about the request, but doesn’t do the normalization 
> and hashing of query parameters and headers yet. That’s an important bit that 
> still needs to be implemented. 
> 
> The client sends the signed object (which includes the token) to the RS over 
> the authorization header using the “PoP” scheme name, mirroring bearer tokens.
> 
> (Note: I’ve also updated the HTTP signing draft to incorporate the necessary 
> changes above, which were discussed in Yokohama. That should be posted to the 
> list already. It’s a lot of rewriting, so please check the diffs. Yes, I’m 
> aware that the chairs have stated their intent to replace me as editor for 
> the document, but I haven’t heard any communication beyond that original 
> announcement so I felt it prudent to publish the update anyway.)

Will read through changes asap.

> 
> The RS parses the signed object out of the header and extracts the token. The 
> RS introspects the token at the AS to get the key (note that it doesn’t send 
> the whole signed object, just the access token itself).

Same here.

> The key is returned in the introspection response as “access_token_key”, 
> parallel with the response from the token endpoint. It is a JSON object here, 
> too (not encoded as a string). Whatever we decide for the token endpoint 
> response we should stay consistent for the introspection response.

Just so that I follow correctly, do you return something like this (but with 
access_token_key).

{ 
"active" : true,
"key" : {"kty”:”…

/ Erik


> 
> The RS uses the key to validate the JWS’s signature. The RS uses the other 
> bits from the introspection callback (scopes, client ID, stuff like that) to 
> determine how to respond, like with bearer tokens.
> 
> The RS responds to the client like in a more traditional OAuth request.
> 
> It’s my hope that this simple implementation can help us move the 
> conversation forward around PoP and help us make sure that what we’re 
> implementing is actually viable. 
> 
>  — Justin
> ___
> 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] Call for Adoption: OAuth 2.0 Discovery

[Roland Hedberg]

+1

> 4 feb 2016 kl. 08:10 skrev Phil Hunt :
> 
> +1 for adoption.
> 
> However I would like a rel value distinct from OpenID (see separate email). 
> While the mechanics of discovery is the same, I believe some clients will 
> want to distinguish between OAuth AS’s and OIDC OPs.  Further, I would expect 
> over time that different discovery features may be required. Locking them 
> together seems like a pre-mature or rush choice.
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
> 
> 
> 
> 
>> On Feb 3, 2016, at 10:44 PM, William Denniss  wrote:
>> 
>> +1 for adoption of this document by the working group
>> 
>> On Wed, Feb 3, 2016 at 10:27 PM, Mike Jones  
>> wrote:
>> I support adoption of this document by the working group.  I'll note that 
>> elements of this specification are already in production use by multiple 
>> parties.
>> 
>> -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Tuesday, January 19, 2016 3:49 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery
>> 
>> Hi all,
>> 
>> this is the call for adoption of OAuth 2.0 Discovery, see
>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00
>> 
>> Please let us know by Feb 2nd whether you accept / object to the adoption of 
>> this document as a starting point for work in the OAuth working group.
>> 
>> Note: If you already stated your opinion at the IETF meeting in Yokohama 
>> then you don't need to re-state your opinion, if you want.
>> 
>> The feedback at the Yokohama IETF meeting was the following: 19 for / zero 
>> against / 4 persons need more information.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

[Roland Hedberg]

> 3 feb 2016 kl. 00:48 skrev Phil Hunt :
> 
> 
> Item 2:  rel value for webfinger
> It seems to me while the discovery requirements for plain OAuth and OIDC are 
> the same for today that might not always be true.  What will happen if OIDC 
> wants to add more stuff?  Will plain oAuth sites have to comply?
> 
> A client may want to know both the OAuth discovery endpoint information for a 
> resource AND it might want to know the OIDC discovery information.  They 
> endpoints might not always be the same - how do we tell them apart?

I’ve (we’ve) had exactly this problem in the UMA use-case.
Which is just one example where an AS may have OAuth2 or OIDC parentage.
So, I support having different real values.

— Roland



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Device Flow

[Roland Hedberg]

+1

> 4 feb 2016 kl. 07:26 skrev Mike Jones :
> 
> I support adoption of this document by the working group.
> 
>   -- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, January 19, 2016 3:48 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Device Flow
> 
> Hi all,
> 
> this is the call for adoption of OAuth 2.0 Device Flow, see
> https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00
> 
> Please let us know by Feb 2nd whether you accept / object to the adoption of 
> this document as a starting point for work in the OAuth working group.
> 
> Note: If you already stated your opinion at the IETF meeting in Yokohama then 
> you don't need to re-state your opinion, if you want.
> 
> The feedback at the Yokohama IETF meeting was the following: 16 persons for 
> doing the work / 0 persons against / 2 persons need more info
> 
> Ciao
> Hannes & Derek
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values

[Roland Hedberg]

+1

> 20 jan 2016 kl. 23:07 skrev John Bradley :
> 
> So if this is scoped to be a registry for the values of a JWT claim then it 
> is fine.
> We should discourage people from thinking that it is part of the OAuth 
> protocol vs JWT claims.
> 
> John B.
> 
>> On Jan 20, 2016, at 6:29 PM, Mike Jones  wrote:
>> 
>> The primary purpose of the specification is to establish a registry for 
>> "amr" JWT claim values.  This is important, as it increases interoperability 
>> among implementations using this claim.
>> 
>> It's a fair question whether "requested_amr" should be kept or dropped.  I 
>> agree with John and James that it's bad architecture.  I put it in the -00 
>> individual draft to document existing practice.  I suspect that should the 
>> draft is adopted by the working group as a starting point, one of the first 
>> things the working group will want to decide is whether to drop it.  I 
>> suspect that I know how this will come out and I won't be sad, 
>> architecturally, to see it go.
>> 
>> As to whether this belongs in the OAuth working group, long ago it was 
>> decided that JWT and JWT claim definitions were within scope of the OAuth 
>> working group.  That ship has long ago sailed, both in terms of RFC 7519 and 
>> it continues to sail, for instance, in draft-ietf-oauth-proof-of-possession, 
>> which defines a new JWT claim, and is in the RFC Editor Queue.  Defining a 
>> registry for values of the "amr" claim, which is registered in the 
>> OAuth-established registry at http://www.iana.org/assignments/jwt, is 
>> squarely within the OAuth WG's mission for the creation and stewardship of 
>> JWT.
>> 
>>  -- Mike
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
>> Sent: Wednesday, January 20, 2016 12:44 PM
>> To: Justin Richer 
>> Cc:  
>> Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference 
>> Values
>> 
>> I see your point that it is a fine line reporting how a person authenticated 
>> to a Authorization endpoit (it might be by SAML etc) and encouraging people 
>> to use OAuth for Authentication.
>> 
>> We already have the amr response in connect.  The only thing really missing 
>> is a registry.  Unless this is a sneaky way to get requested_amr into 
>> Connect?
>> 
>> John B.
>>> On Jan 20, 2016, at 5:37 PM, Justin Richer  wrote:
>>> 
>>> Just reiterating my stance that this document detailing user authentication 
>>> methods has no place in the OAuth working group.
>>> 
>>> — Justin
>>> 
 On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig  
 wrote:
 
 Hi all,
 
 this is the call for adoption of Authentication Method Reference
 Values, see
 https://tools.ietf.org/html/draft-jones-oauth-amr-values-03
 
 Please let us know by Feb 2nd whether you accept / object to the
 adoption of this document as a starting point for work in the OAuth
 working group.
 
 Note: The feedback during the Yokohama meeting was inconclusive,
 namely
 9 for / zero against / 6 persons need more information.
 
 You feedback will therefore be important to find out whether we
 should do this work in the OAuth working group.
 
 Ciao
 Hannes & Derek
 
 ___
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector

[Roland Hedberg]

+1

> 4 feb 2016 kl. 07:25 skrev Mike Jones :
> 
> I support adoption of this document by the working group.
> 
>   -- Mike
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, January 19, 2016 3:48 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open 
> Redirector
> 
> Hi all,
> 
> this is the call for adoption of OAuth 2.0 Security: OAuth Open Redirector, 
> see
> https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02
> 
> Please let us know by Feb 2nd whether you accept / object to the adoption of 
> this document as a starting point for work in the OAuth working group.
> 
> Note: At the IETF Yokohama we asked for generic feedback about doing security 
> work in the OAuth working group and there was very positive feedback. 
> However, for the adoption call we need to ask for individual documents. 
> Hence, you need to state your view again.
> 
> Ciao
> Hannes & Derek
> 
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth