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

+1 for adoption > 21 jan 2016 kl. 07:11 skrev William Denniss : > > I believe this is important work. > > The original OAuth 2 spec left the topic of native apps largely undefined > which is fair enough, the mobile-first revolution had yet to really take hold > and people didn't have much impl

Re: [OAUTH-WG] Call for Adoption

My memory of the discussions of the oauth-meta draft in Yokohama were that many people felt that it was unnecessarily dynamically duplicating a lot of information that the client already had. Most of us that were aware of the attacks then were in favor of a more targeted, minimal approach. You

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 for adoption > 21 jan 2016 kl. 07:14 skrev Antonio Sanso : > > +1 for adoption > On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig > wrote: > >> Hi all, >> >> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-

Re: [OAUTH-WG] Call for Adoption

Hi Mike. Conversely, I would like to ask why this approach does not work for Mix-up attack. As Nov stated, we in fact have discussed the approach in quite a length back in Yokohama. I really would like to know why it does not work. Besides, for oauth-meta approach, mix-up attack is only one of th

Re: [OAUTH-WG] Call for Adoption

Not to be negative, but I disagree with adopting draft-sakimura-oauth-meta. We should define and promote one mitigation approach to the mix-up attacks. Having two would confuse implementers and cause compatibility problems – reducing overall security. The approach defined in draft-jones-oauth

[OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up Mitigation draft. Changes were: * Simplified by no longer specifying the signed JWT method for returning the mitigation information. * Simplified by no longer depending upon publication of a discovery metadata d

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

+1 for adoption On Jan 19, 2016, at 12:47 PM, Hannes Tschofenig wrote: > 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 / obj

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

+1 for adoption. I do really think this fills a current gap. regards antonio On Jan 19, 2016, at 12:46 PM, Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of OAuth 2.0 for Native Apps, see > http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ > > Please let

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 for adoption On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see > https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 > > Please let us know by Feb 9th whether you accept / object to the > ado

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

Ah, OK. That's actually reasonable. 2016年1月21日(木) 9:31 nov matake : > I prefer “code_challenge_methods_supported”, since the registered > parameter name is “code_challenge_method”, not “pkce_method". > > On Jan 19, 2016, at 11:58, William Denniss wrote: > > Seems like we agree this should be add

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

This work had many issues in the OpenID WG where it failed why should this be a WG item here ? The does meet the requirements for experimental, there is a fine line between informational and experimental, I would be OK with either but prefer experimental, I don’t think that this should become a

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Thought I did, but apparently not. A belated +1. 2016年1月21日(木) 12:43 Anthony Nadalin : > +1 > > > > *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *William > Denniss > *Sent:* Wednesday, January 20, 2016 6:30 PM > *To:* John Bradley ; Phil Hunt (IDM) < > phil.h...@oracle.com> > *Cc:*

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of William Denniss Sent: Wednesday, January 20, 2016 6:30 PM To: John Bradley ; Phil Hunt (IDM) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation +1 for adoption, this is important work. On Thu, Jan

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 for adoption Mike and I are working on addressing the comments in a new draft for your reading pleasure shortly. John B. > On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) wrote: > > +1 for adoption > > +1 for Brian's comments > > Phil > > On Jan 20, 2016, at 14:42, Brian Campbell

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

Right but OAuth is the layer that needs to relay the request to the authen service. +1 on adoption However we need to discuss more on w this as a registry or how it is used in the overall architecture to pass signalling (hint maybe that falls to connect?) Phil > On Jan 20, 2016, at 12:37, J

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 for adoption +1 for Brian's comments Phil > On Jan 20, 2016, at 14:42, Brian Campbell wrote: > > I conditionally accept this document as a starting point for work in the > OAuth working group on the assumption that the considerable simplifications > discussed and accepted at > http://www

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

I prefer “code_challenge_methods_supported”, since the registered parameter name is “code_challenge_method”, not “pkce_method". > On Jan 19, 2016, at 11:58, William Denniss wrote: > > Seems like we agree this should be added. How should it look? > > Two ideas: > > "code_challenge_methods_supp

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

I kind of prefer pkce_methods_supported as it scopes it more narrowly and less likely to be overloaded. 2016年1月19日(火) 11:59 William Denniss : > Seems like we agree this should be added. How should it look? > > Two ideas: > > "code_challenge_methods_supported": ["plain", "S256"] > > or > > "pkce_me

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

Correct. I am not saying specifying resource URI as audience is a bad thing. In fact, I need it as described below. I am just asking for adding another option. For John's case, if the client started from an abstract resource type, then the token endpoint first responds with the tokens and set of p

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

As it’s currently written it’s not really limited to defining JWT claims, and so I’m with John that if that’s what this turns into and stays that way then it’s fine. I’m very afraid of scope creep and this being used for something it shouldn’t be. And, as Mike well knows, I did not support the

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

As I see it, John just said the same thing I did in parallel, using different words. From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Wednesday, January 20, 2016 2:56 PM To: Nat Sakimura Cc: Mike Jones; oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience We have been talki

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

We have been talking about providing the resource or audience as the input. The resource type would be more abstract than audience. That is something we would need to discuss in a spec. The problem foe POP is that the same scope may cover multiple resource endpoints. Especially when using a

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

That doesn’t always work when there’s multiple resource servers that the authorization server could authorize access to. Whereas, the client does know what it’s trying to access, or it wouldn’t be making the authorization request in the first place. It’s fine for the client to tell the server

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

+1 Also, I have always thought that it would be good if one could ask for a particular resource type, and the server could respond with the actual location of it with the associated access token. This is because it is often undesirable to tell the client the location of the resource before the aut

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

I conditionally accept this document as a starting point for work in the OAuth working group on the assumption that the considerable simplifications discussed and accepted at http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html will be incorporated. This document is (should be) intende

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

+1 > On Jan 20, 2016, at 7:25 PM, Mike Jones wrote: > > As mentioned in Prague, Azure Active Directory uses a “resource” request > parameter to supply the URL of the resource server that the access token is > intended for. However, I believe that Google uses scope values for this and > some

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

As mentioned in Prague, Azure Active Directory uses a “resource” request parameter to supply the URL of the resource server that the access token is intended for. However, I believe that Google uses scope values for this and some Microsoft services are moving towards using scope values as well.

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

There does seem to be a need to provide the client a means of telling the AS the place(s) and/or entity(s) where it intends to use the token it's asking for. And that it's common enough to warrant it's own small spec. This has come up several times before and I think has some consensus behind doing

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

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 estab

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

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

Re: [OAUTH-WG] Cross-Area Review Request for RDAP Authentication

It is on my todo list but ... 2016年1月19日(火) 23:40 Hollenbeck, Scott : > > -Original Message- > > From: Hollenbeck, Scott > > Sent: Monday, January 11, 2016 8:31 AM > > To: OAuth@ietf.org > > Subject: Cross-Area Review Request for RDAP Authentication > > > > I'd like to ask folks who are mo

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

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

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

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

PS as you probably suspected I am in favour of moving this forward. > On Jan 20, 2016, at 5:08 PM, Nat Sakimura wrote: > > +1 for moving this forward. > > 2016年1月21日木曜日、John Bradley >さんは書きました: > Yes more is needed. It was theoretical at that point. Now we have >

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

+1 for moving this forward. 2016年1月21日木曜日、John Bradleyさんは書きました: > Yes more is needed. It was theoretical at that point. Now we have > implementation experience. > > On Jan 20, 2016, at 3:38 PM, Brian Campbell > wrote: > > There is > https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps

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

I have always been on record as being against having this as a request parameter, and managed to keep it out of connect. So will be looking to do the same with this. In a response as a list of that methods were used it is mostly harmless. People think they need it until they discover that it i

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

Yes more is needed. It was theoretical at that point. Now we have implementation experience. > On Jan 20, 2016, at 3:38 PM, Brian Campbell > wrote: > > There is > https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A >

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

+1 for doing the work (I was remote for Yokohama so not sure if my feedback was previously counted in that 16). On Tue, Jan 19, 2016 at 4:46 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi all, > > this is the call for adoption of OAuth 2.0 for Native Apps, see > http://datatracker

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

There is https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A which has some mention of SFSafariViewController and Chrome Custom Tabs. Maybe more is needed? On Wed, Jan 20, 2016 at 10:45 AM, John Bradley wrote: > Yes, in July we recommended using the system browser rather

[OAUTH-WG] oauth - New Meeting Session Request for IETF 95

A new meeting session request has just been submitted by Hannes Tschofenig, a Chair of the oauth working group. - Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sess

Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

And I agree with Phil’s agreement with Brian :-) I should also add that I during the last part of the meeting and on my flight home afterwards implemented the techniques I felt we had come to an agreement on at the meeting. That is the new authorization request response parameters iss and clien

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

Yes, in July we recommended using the system browser rather than WebViews. About that time Apple announced Safari view controller and Google Chrome custom tabs. The code in the OS is now stable and we have done a fair amount of testing. The OIDF will shortly be publishing reference librari

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

Tony, that doesn’t make sense. An experimental draft would still be a WG draft, and even then this doesn’t match any of the qualifications of “experimental” by IETF definition. It’s arguable whether it be marked “informational” or “standard” since it’s describing best practices more than protoco

Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

Hi Sergey, that's a good question. After this document was published the functionality had been integrated into the PoP solution document. Recently, I got feedback that the functionality should be more generic and it is independent of the PoP work. So, I guess it is a good time to discuss the nee

Re: [OAUTH-WG] Call for Adoption

+1 Inline discovery and pre-configured discovery (ie, .well-known) should at the very least be compatible and developed together. It's the pre-configured discovery document that's at the root of the mix-up attack in the first place. -- Justin On 1/19/2016 10:30 PM, Nat Sakimura wrote: Just

[OAUTH-WG] Status of draft-tschofenig-oauth-audience

Hi Given that the draft-tschofenig-oauth-audience [1] has expired, I'm wondering if it is still relevant. I know the token introspection response can provide the audience value(s), but the question is really how a client is associated with a a given audience in the first place. As such [1] m

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

After reading this draft I think that this may be better off as an experimental draft and not a WG draft -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, January 19, 2016 3:47 AM To: oauth@ietf.org Subject: [OAUTH-WG] Call for a