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

[Anthony Nadalin]

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 adoption: OAuth 2.0 for Native Apps

Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-wdenniss-oauth-native-apps%2f&data=01%7c01%7ctonynad%40microsoft.com%7c2180a2867ac74a039d6108d320c642c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fT7bH5bT8ISndWGCaNj%2f4XGrCz1xFzr0cQdWmGUhk%2fs%3d

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

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

[Sergey Beryozkin]

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] may still make sense, for 
example, I can think of two options:
1. the client audiences are set out of band during the client 
registration time and all the tokens issued to that client will be 
restricted accordingly
2. the client is requesting a specific audience during the grant to 
token exchange as per [1]


I guess 1. is how it is done in practice or is 2. is also a valid option ?


Thanks, Sergey


[1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00

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

Re: [OAUTH-WG] Call for Adoption

[Justin Richer]

+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 to give more context, at IETF 94, I have done a presentation on 
discovery.


According to the minutes,

 (f) Discovery (Nat)
   
  Nat explains his document as an example of the work that has to be done

  in the area of discovery, which is a topic that has been 
identified
  as necessary for interoperability since many years but so far 
there
  was not time to work on it. Mike, John and Nat are working on a 
new
  document that describes additional discovery-relevant components.
   
  Poll: 19 for / zero against / 4 persons need more information.
The document discussed there was 
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a 
simple (only 1-page!) but a very powerful document that nudges towards 
HATEOAS which is at the core of RESTful-ness. It also mitigates the 
Mix-up attack without introducing the concept of issuer which is not 
in RFC6749. It is also good for selecting different endpoints 
depending on the user authentication and authorization results and 
more privacy sensitive than pre-announced Discovery document. It also 
allows you to find to which protected resource endpoint you can use 
the access token against.


In the last sentence of the minutes, it talks about "a new document 
that describes additional discovery-relevant components". This is 
https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went 
for the call for adoption. However, it is only a half of the story. I 
believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that 
was discussed at IETF 94 and had support there should be adopted as well.


Nat Sakimura




2016年1月20日(水) 12:05 Nat Sakimura >:


Thanks Hannes.

I did not find
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which
was discussed in Yokohama, and was largely in agreement if my
recollection is correct. Why is it not in the call for adoption?



2016年1月19日(火) 20:39 Hannes Tschofenig
mailto:hannes.tschofe...@gmx.net>>:

Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html)
and
since some IESG members like to see an updated list of
milestones as
well. For this reason, based on a suggestion from Barry, we
are also
starting a call for adoption concurrently with the review of
the charter
text by the IESG.

We will post separate mails on the individual documents. Your
feedback
is important! Please take the time to look at the documents
and provide
your feedback.

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

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

[Hannes Tschofenig]

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 needed functionality and
where it should be included.

Ciao
Hannes


On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> 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] may still make sense, for
> example, I can think of two options:
> 1. the client audiences are set out of band during the client
> registration time and all the tokens issued to that client will be
> restricted accordingly
> 2. the client is requesting a specific audience during the grant to
> token exchange as per [1]
> 
> I guess 1. is how it is done in practice or is 2. is also a valid option ?
> 
> 
> Thanks, Sergey
> 
> 
> [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
> 
> ___
> 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] Call for adoption: OAuth 2.0 for Native Apps

[Justin Richer]

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 protocols, but 
“experimental” doesn’t fit at all.

 — Justin

> On Jan 20, 2016, at 4:50 AM, Anthony Nadalin  wrote:
> 
> 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 adoption: OAuth 2.0 for Native Apps
> 
> Hi all,
> 
> this is the call for adoption of OAuth 2.0 for Native Apps, see 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-wdenniss-oauth-native-apps%2f&data=01%7c01%7ctonynad%40microsoft.com%7c2180a2867ac74a039d6108d320c642c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fT7bH5bT8ISndWGCaNj%2f4XGrCz1xFzr0cQdWmGUhk%2fs%3d
> 
> 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

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

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

[John Bradley]

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 libraries for iOS and Android to 
how how to best use View Controllers, and PKCE in native apps on those 
platforms.

We do need to update this doc to reflect what we have learned in the last 6 
months.

One problem we do still have is not having someone with Win 10 mobile 
experience to help document the best practices for that platform. 
I don’t understand that platform well enough yet to include anything.

John B.

> On Jan 20, 2016, at 12:40 PM, Aaron Parecki  wrote:
> 
> The section on embedded web views doesn't mention the new iOS 9 
> SFSafariViewController which allows apps to display a system browser within 
> the application. The new API doesn't give the calling application access to 
> anything inside the browser, so it is acceptable for using with OAuth flows. 
> I think it's important to mention this new capability for apps to leverage 
> since it leads to a better user experience.
> 
> I'm sure that can be addressed in the coming months if this document is just 
> the starting point.
> 
> I definitely agree that a document about native apps is necessary since the 
> core leaves a lot of guessing room for an implementation.
> 
> For reference, 
> https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26
>  
> 
> 
> And see the attached screenshot for an example of what it looks like.
> 
> 
> 
> 
> Aaron Parecki
> aaronparecki.com 
> @aaronpk 
> 
> 
> On Tue, Jan 19, 2016 at 3:46 AM, 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 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 
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



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

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

[Roland Hedberg]

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 client_id as well as the use of state_hash at the token endpoint.

> 13 jan 2016 kl. 05:31 skrev Phil Hunt (IDM) :
> 
> I am in agreement with Brian.
> 
> I understand what Mike is trying to do is safer, but I too am concerned that 
> the escalation in knowledge/skills for oauth clients is significant.
> 
> This may not be the same concern as for OIDC where we can expect more 
> sophistication.
> 
> Phil
> 
> On Jan 12, 2016, at 20:03, Justin Richer  wrote:
> 
>> +1 to Brian’s point, and points to Mike for promising to address this. I 
>> wasn’t able to attend the meeting in Darmstadt, but I’ve been following the 
>> discussion and original papers. Let’s take this one piece at a time and not 
>> overreach with a solution.
>> 
>> In particular, the whole “late binding discovery” bit would cause huge 
>> problems on its own. There’s good reason that OpenID Connect mandates that 
>> the “iss” value returned from the discovery endpoint MUST be the same as the 
>> “iss” value coming back from the ID Token, so let’s not ignore that.
>> 
>>  — Justin
>> 
>>> On Jan 12, 2016, at 5:53 PM, Mike Jones  wrote:
>>> 
>>> John Bradley and I went over this today and I'm already planning on 
>>> simplifying the draft along the lines described. I would have written this 
>>> earlier but I've been busy at a NIST meeting today.
>>> 
>>> John has also stated writing a note about how cut-and-paste does and 
>>> doesn't apply here but hasn't finished it yet because he's been similarly 
>>> occupied.  He's also started writing up the state_hash token request 
>>> parameter, as he agreed to do.
>>> 
>>> Watch this space for the new draft...
>>> 
>>> Best wishes,
>>> -- Mike
>>> From: Brian Campbell
>>> Sent: ‎1/‎12/‎2016 5:24 PM
>>> To: oauth
>>> Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation
>>> 
>>> The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on 
>>> them) take advantage of the fact that there's nothing in the OAuth 
>>> authorization response to the client's redirect_uri that identifies the 
>>> authorization server. As a result, a variety of techniques can be used to 
>>> trick the client into sending the code (or token in some cases) to the 
>>> wrong endpoint.
>>> 
>>> To the best of my recollection the general consensus coming out of the 
>>> meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: 
>>> Authorization Server Mix-Up) was to put forth an I-D as a simple extension 
>>> to OAuth, which described how to return an issuer identifier for the 
>>> authorization server and client identifier as authorization response 
>>> parameters from the authorization endpoint. Doing so enables the client to 
>>> know which AS the response came from and thus avoid sending the code to a 
>>> different AS. Also, it doesn't introduce application/message level 
>>> cryptography requirements on client implementations.
>>> 
>>> The mitigation draft that was posted yesterday diverges considerably from 
>>> that with a significantly expanded scope that introduces OpenID Connect ID 
>>> Tokens (sort of anyway) to regular OAuth and the retrieval of a 
>>> metadata/discovery document in-between the authorization request and the 
>>> access token request.
>>> 
>>> It is possible that my recollection from Darmstadt is wrong. But I expect 
>>> others who were there could corroborate my account of what transpired. Of 
>>> course, the agreements out of the Darmstadt meeting were never intended to 
>>> be the final word - the whole WG would have the opportunity to weigh, as is 
>>> now the case. However, a goal of meeting face-to-face was to come away with 
>>> a good consensus towards a proposed solution that could (hopefully) be 
>>> implementable in the very near term and move thought the IETF process in an 
>>> expedited manner. I believe we'd reached consensus but the content of -00 
>>> draft does not reflect it.
>>> 
>>> I've made the plea off-list several times to simplify the draft to reflect 
>>> the simple solution and now I'm doing the same on-list. Simplify the 
>>> response validation to just say not to send the code/token back to an AS 
>>> entity other that the one identified by the 'iss' in the response. And 
>>> remove the id_token and JWT parts that .
>>> 
>>> If this WG and/or the larger community believes that OAuth needs signed 
>>> responses, let's develop a proper singed response mechanism. I don't know 
>>> if it's needed or not but I do know that it's a decent chunk of work that 
>>> should be conscientiously undertaken independent of what can and should be 
>>> a simple to understand and implement fix for the idp mix-up problem.
>>> 
>>> 
>>> 
>>> _

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

["IETF Meeting Session Request Tool"]

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 Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: ace saag cfrg tls core lwig




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

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

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

[Brian Campbell]

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 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 libraries for iOS and
> Android to how how to best use View Controllers, and PKCE in native apps on
> those platforms.
>
> We do need to update this doc to reflect what we have learned in the last
> 6 months.
>
> One problem we do still have is not having someone with Win 10 mobile
> experience to help document the best practices for that platform.
> I don’t understand that platform well enough yet to include anything.
>
> John B.
>
> On Jan 20, 2016, at 12:40 PM, Aaron Parecki  wrote:
>
> The section on embedded web views doesn't mention the new iOS 9
> SFSafariViewController which allows apps to display a system browser within
> the application. The new API doesn't give the calling application access to
> anything inside the browser, so it is acceptable for using with OAuth
> flows. I think it's important to mention this new capability for apps to
> leverage since it leads to a better user experience.
>
> I'm sure that can be addressed in the coming months if this document is
> just the starting point.
>
> I definitely agree that a document about native apps is necessary since
> the core leaves a lot of guessing room for an implementation.
>
> For reference,
> https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26
>
> And see the attached screenshot for an example of what it looks like.
>
> 
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
>
> On Tue, Jan 19, 2016 at 3: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.ietf.org/doc/draft-wdenniss-oauth-native-apps/
>>
>> 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
>>
>>
> ___
> 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 for Native Apps

[Brian Campbell]

+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.ietf.org/doc/draft-wdenniss-oauth-native-apps/
>
> 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
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[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-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 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 libraries for iOS and Android 
> to how how to best use View Controllers, and PKCE in native apps on those 
> platforms.
> 
> We do need to update this doc to reflect what we have learned in the last 6 
> months.
> 
> One problem we do still have is not having someone with Win 10 mobile 
> experience to help document the best practices for that platform. 
> I don’t understand that platform well enough yet to include anything.
> 
> John B.
> 
>> On Jan 20, 2016, at 12:40 PM, Aaron Parecki > > wrote:
>> 
>> The section on embedded web views doesn't mention the new iOS 9 
>> SFSafariViewController which allows apps to display a system browser within 
>> the application. The new API doesn't give the calling application access to 
>> anything inside the browser, so it is acceptable for using with OAuth flows. 
>> I think it's important to mention this new capability for apps to leverage 
>> since it leads to a better user experience.
>> 
>> I'm sure that can be addressed in the coming months if this document is just 
>> the starting point.
>> 
>> I definitely agree that a document about native apps is necessary since the 
>> core leaves a lot of guessing room for an implementation.
>> 
>> For reference, 
>> https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26
>>  
>> 
>> 
>> And see the attached screenshot for an example of what it looks like.
>> 
>> 
>> 
>> 
>> Aaron Parecki
>> aaronparecki.com 
>> @aaronpk 
>> 
>> 
>> On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig 
>> mailto:hannes.tschofe...@gmx.net>> 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 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 
>> 
>> 
>> 
>> ___
>> 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 
> 
> 
> 



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

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

[John Bradley]

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 is not really useful in 
most circumstances.

The methods listed are really not useful,  but might be OK as general 
categories of response.

Fido U2F and UAF fall into what I would call Phishing resistant credentials,  
is that something a RP should care about or is that reflected in the LoA.

In the MODRNA profile of OpenID Connect I added some other ones to indicate if 
the key is hardware or software etc.

This is probably a OK place to start from so I am OK with adopting it, but will 
push for change:)

John B.

> On Jan 20, 2016, at 3:38 AM, William Denniss  wrote:
> 
> On Wed, Jan 20, 2016 at 12:37 PM, Manger, James 
> mailto:james.h.man...@team.telstra.com>> 
> wrote:
> Accepting draft-jones-oauth-amr-values-03 is almost okay as a starting point 
> for work.
> 
> +1 for adoption.
>  
> I would like to see significant changes though:
> 
> * The "amr_values" parameter should be dropped; it just encourages brittle 
> designs as section 4 "relationship to acr" and section 6 "security 
> considerations" already warn about. There is no need to enable that 
> brittleness. If someone really wants this functionality they could put an amr 
> value in the "acr_values" field as a hack.
> 
> I agree that it seems to encourage brittle designs. Why would the OP want to 
> use "otp" when it has U2F on file for the same user, for example? But come to 
> think of it, is any use of "amr" non-brittle?  I guess the broader ones like 
> "user", "rba", "mca" and "mfa" are a little more future-proof.
> 
> I'm very keen to hear some concrete use-cases for this parameter.
> 
> * The model for amr_values is wrong as well. For example, "amr":["pwd","otp"] 
> could be a common response that you want, but you cannot ask for that with 
> amr_values since amr_values="pwd otp" actually means just "pwd", or just 
> "otp" is okay (and just "pwd" is your preference).
> 
> * Registering values on a "Specification Required" basis is over-the-top. 
> This doc registers 8 amr values with just a few words as each value's 
> "specification" (eg "eye": retina scan biometric). Each of the other 7 amr 
> values are "specified" in a few lines with a reference (or two). A "First 
> Come First Served" basis is probably sufficient, with the "specification" 
> just the description in the registry (that can include references).
> 
> I agree, "Specification Required" does seem like a high bar.
> 
> 
> --
> James Manger
> 
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org ] 
> On Behalf Of Hannes Tschofenig
> Sent: Tuesday, 19 January 2016 10:48 PM
> To: oauth@ietf.org 
> Subject: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values
> 
> 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 
> 


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

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

[Nat Sakimura]

+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-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 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 libraries for iOS and
>> Android to how how to best use View Controllers, and PKCE in native apps on
>> those platforms.
>>
>> We do need to update this doc to reflect what we have learned in the last
>> 6 months.
>>
>> One problem we do still have is not having someone with Win 10 mobile
>> experience to help document the best practices for that platform.
>> I don’t understand that platform well enough yet to include anything.
>>
>> John B.
>>
>> On Jan 20, 2016, at 12:40 PM, Aaron Parecki > > wrote:
>>
>> The section on embedded web views doesn't mention the new iOS 9
>> SFSafariViewController which allows apps to display a system browser within
>> the application. The new API doesn't give the calling application access to
>> anything inside the browser, so it is acceptable for using with OAuth
>> flows. I think it's important to mention this new capability for apps to
>> leverage since it leads to a better user experience.
>>
>> I'm sure that can be addressed in the coming months if this document is
>> just the starting point.
>>
>> I definitely agree that a document about native apps is necessary since
>> the core leaves a lot of guessing room for an implementation.
>>
>> For reference,
>> https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26
>>
>> And see the attached screenshot for an example of what it looks like.
>>
>> 
>>
>> 
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk 
>>
>>
>> On Tue, Jan 19, 2016 at 3: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.ietf.org/doc/draft-wdenniss-oauth-native-apps/
>>>
>>> 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
>>>
>>>
>> ___
>> 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
>>
>>
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[John Bradley]

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 
> 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 
>>  
>> 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 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 libraries for iOS and Android 
>> to how how to best use View Controllers, and PKCE in native apps on those 
>> platforms.
>> 
>> We do need to update this doc to reflect what we have learned in the last 6 
>> months.
>> 
>> One problem we do still have is not having someone with Win 10 mobile 
>> experience to help document the best practices for that platform. 
>> I don’t understand that platform well enough yet to include anything.
>> 
>> John B.
>> 
>>> On Jan 20, 2016, at 12:40 PM, Aaron Parecki >> > wrote:
>>> 
>>> The section on embedded web views doesn't mention the new iOS 9 
>>> SFSafariViewController which allows apps to display a system browser within 
>>> the application. The new API doesn't give the calling application access to 
>>> anything inside the browser, so it is acceptable for using with OAuth 
>>> flows. I think it's important to mention this new capability for apps to 
>>> leverage since it leads to a better user experience.
>>> 
>>> I'm sure that can be addressed in the coming months if this document is 
>>> just the starting point.
>>> 
>>> I definitely agree that a document about native apps is necessary since the 
>>> core leaves a lot of guessing room for an implementation.
>>> 
>>> For reference, 
>>> https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26
>>>  
>>> 
>>> 
>>> And see the attached screenshot for an example of what it looks like.
>>> 
>>> 
>>> 
>>> 
>>> Aaron Parecki
>>> aaronparecki.com 
>>> @aaronpk 
>>> 
>>> 
>>> On Tue, Jan 19, 2016 at 3:46 AM, 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 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 
>>> 
>>> 
>>> 
>>> ___
>>> 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 
>> 
>> 
>> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/ 
> @_nat_en
> 



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

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

[Justin Richer]

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



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

[John Bradley]

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



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

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

[Nat Sakimura]

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 more familiar with OAuth than I am to
> > please review an I-D I've written that describes an approach to using
> > OpenID Connect with the Registration Data Access Protocol (RDAP, a
> > product of the WEIRDS WG). Those of you who are familiar with WHOIS
> > will understand the motivation behind the development of RDAP and the
> > benefits of being able to authenticate clients.
> >
> > The I-D can be found here:
> >
> > https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/
> >
> > Note that RDAP does not depend on clients using web browsers. I have
> > some text in the document that describes how to use OpenID Connect with
> > non-browser clients and I'd like to ensure that it all makes sense.
>
> Can anyone help with this?
>
> Scott
>
> ___
> 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: Authentication Method Reference Values

[Mike Jones]

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

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

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



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

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

[Brian Campbell]

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 it. What needs to happen to move forward?

The concept shows up in these three different drafts (that I know of
anyway):

https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3
has an audience parameter
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3
has an aud parameter
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1
has both an audience and a resource resource

All the above apply only to the token request. However, there are ways of
requesting/obtaining access tokens that don't involve the token endpoint
 so I think it follows
that  the same facility should be available for the authorization request
too.




On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> 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 needed functionality and
> where it should be included.
>
> Ciao
> Hannes
>
>
> On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> > 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] may still make sense, for
> > example, I can think of two options:
> > 1. the client audiences are set out of band during the client
> > registration time and all the tokens issued to that client will be
> > restricted accordingly
> > 2. the client is requesting a specific audience during the grant to
> > token exchange as per [1]
> >
> > I guess 1. is how it is done in practice or is 2. is also a valid option
> ?
> >
> >
> > Thanks, Sergey
> >
> >
> > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
> >
> > ___
> > 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] Status of draft-tschofenig-oauth-audience

[Mike Jones]

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.  Sorting 
this out soon would be good.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, January 20, 2016 2:18 PM
To: Hannes Tschofenig
Cc: oauth
Subject: 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 it. What 
needs to happen to move forward?
The concept shows up in these three different drafts (that I know of anyway):

https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 has an 
audience parameter
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3 
has an aud parameter
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has 
both an audience and a resource resource

All the above apply only to the token request. However, there are ways of 
requesting/obtaining access tokens that don't involve the token 
endpoint so I think it follows 
that  the same facility should be available for the authorization request too.



On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
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 needed functionality and
where it should be included.

Ciao
Hannes


On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> 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] may still make sense, for
> example, I can think of two options:
> 1. the client audiences are set out of band during the client
> registration time and all the tokens issued to that client will be
> restricted accordingly
> 2. the client is requesting a specific audience during the grant to
> token exchange as per [1]
>
> I guess 1. is how it is done in practice or is 2. is also a valid option ?
>
>
> Thanks, Sergey
>
>
> [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
>
> ___
> 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] Status of draft-tschofenig-oauth-audience

[John Bradley]

+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 Microsoft services are moving towards using scope values as well.  
> Sorting this out soon would be good.
>  
> -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org ] 
> On Behalf Of Brian Campbell
> Sent: Wednesday, January 20, 2016 2:18 PM
> To: Hannes Tschofenig
> Cc: oauth
> Subject: 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 it. 
> What needs to happen to move forward?
> 
> The concept shows up in these three different drafts (that I know of anyway):
> 
> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 
>  
> has an audience parameter 
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3
>  
> 
>  has an aud parameter 
> http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 
>  
> has both an audience and a resource resource
> 
> All the above apply only to the token request. However, there are ways of 
> requesting/obtaining access tokens that don't involve the token endpoint 
>  so I think it follows that  
> the same facility should be available for the authorization request too. 
> 
> 
> 
>  
> On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig  > wrote:
> 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 needed functionality and
> where it should be included.
> 
> Ciao
> Hannes
> 
> 
> On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> > 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] may still make sense, for
> > example, I can think of two options:
> > 1. the client audiences are set out of band during the client
> > registration time and all the tokens issued to that client will be
> > restricted accordingly
> > 2. the client is requesting a specific audience during the grant to
> > token exchange as per [1]
> >
> > I guess 1. is how it is done in practice or is 2. is also a valid option ?
> >
> >
> > Thanks, Sergey
> >
> >
> > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 
> > 
> >
> > ___
> > 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 
> 


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

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

[Brian Campbell]

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) intended to provide a mitigation to a security
problem. As such, it would be nice to see it progress a little faster than
the typical WG document. The more quickly the document can progress and/or
be perceived as stable, the better.

On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> 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
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Note: This call is related to the announcement made on the list earlier
> this month, see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
> time for analysis is provided due to the complexity of the topic.
>
> 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] Status of draft-tschofenig-oauth-audience

[Nat Sakimura]

+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 authorization from the privacy point of view.

So, the processing flow in this case will be:


   1. The client request an access to the resource type in the scope of the
   authorization request.
   2. The client request an access token to the resource type to the token
   endpoint with audience/resource/scope parameter.
   3. The token endpoint responds with token response with oauth-meta
   header indicating the URL of the resource as in
draft-sakimura-oauth-meta.

Best,

Nat


2016年1月21日(木) 7:27 John Bradley :

> +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 Microsoft services are moving towards using scope values as well.
> Sorting this out soon would be good.
>
> -- Mike
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
> Behalf Of *Brian Campbell
> *Sent:* Wednesday, January 20, 2016 2:18 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth
> *Subject:* 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 it. What needs to happen to move forward?
> The concept shows up in these three different drafts (that I know of
> anyway):
>
>
> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 has
> an audience parameter
>
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3
>  has an aud parameter
> http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has
> both an audience and a resource resource
>
> All the above apply only to the token request. However, there are ways of
> requesting/obtaining access tokens that don't involve the token endpoint
>  so I think it follows
> that  the same facility should be available for the authorization request
> too.
>
>
>
> On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
> 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 needed functionality and
> where it should be included.
>
> Ciao
> Hannes
>
>
>
> On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> > 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] may still make sense, for
> > example, I can think of two options:
> > 1. the client audiences are set out of band during the client
> > registration time and all the tokens issued to that client will be
> > restricted accordingly
> > 2. the client is requesting a specific audience during the grant to
> > token exchange as per [1]
> >
> > I guess 1. is how it is done in practice or is 2. is also a valid option
> ?
> >
> >
> > Thanks, Sergey
> >
> >
> > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
> >
> > ___
> > 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] Status of draft-tschofenig-oauth-audience

[Mike Jones]

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 what it wants 
access to.

-- Mike

From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Wednesday, January 20, 2016 2:47 PM
To: John Bradley; Mike Jones
Cc: oauth
Subject: 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 authorization from 
the privacy point of view.

So, the processing flow in this case will be:


  1.  The client request an access to the resource type in the scope of the 
authorization request.
  2.  The client request an access token to the resource type to the token 
endpoint with audience/resource/scope parameter.
  3.  The token endpoint responds with token response with oauth-meta header 
indicating the URL of the resource as in  draft-sakimura-oauth-meta.
Best,

Nat


2016年1月21日(木) 7:27 John Bradley mailto:ve7...@ve7jtb.com>>:
+1

On Jan 20, 2016, at 7:25 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> 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 Microsoft services are moving towards using scope values as well.  Sorting 
this out soon would be good.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, January 20, 2016 2:18 PM
To: Hannes Tschofenig
Cc: oauth
Subject: 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 it. What 
needs to happen to move forward?
The concept shows up in these three different drafts (that I know of anyway):

https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 has an 
audience parameter
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3 
has an aud parameter
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has 
both an audience and a resource resource

All the above apply only to the token request. However, there are ways of 
requesting/obtaining access tokens that don't involve the token 
endpoint so I think it follows 
that  the same facility should be available for the authorization request too.


On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
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 needed functionality and
where it should be included.

Ciao
Hannes


On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> 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] may still make sense, for
> example, I can think of two options:
> 1. the client audiences are set out of band during the client
> registration time and all the tokens issued to that client will be
> restricted accordingly
> 2. the client is requesting a specific audience during the grant to
> token exchange as per [1]
>
> I guess 1. is how it is done in practice or is 2. is also a valid option ?
>
>
> Thanks, Sergey
>
>
> [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
>
> ___
> 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] Status of draft-tschofenig-oauth-audience

[John Bradley]

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 symmetric key you need to specify what 
Resource server you are sending the token to so that it can be encrypted with 
the correct key.

John B.
> On Jan 20, 2016, at 7:47 PM, Nat Sakimura  wrote:
> 
> +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 
> authorization from the privacy point of view. 
> 
> So, the processing flow in this case will be: 
> 
> The client request an access to the resource type in the scope of the 
> authorization request. 
> The client request an access token to the resource type to the token endpoint 
> with audience/resource/scope parameter. 
> The token endpoint responds with token response with oauth-meta header 
> indicating the URL of the resource as in  draft-sakimura-oauth-meta. 
> Best, 
> 
> Nat
> 
> 
> 2016年1月21日(木) 7:27 John Bradley  >:
> +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 Microsoft services are moving towards using scope values as well.  
>> Sorting this out soon would be good.
>>  
>> -- Mike
>>  
>> From: OAuth [mailto:oauth-boun...@ietf.org ] 
>> On Behalf Of Brian Campbell
>> Sent: Wednesday, January 20, 2016 2:18 PM
>> To: Hannes Tschofenig
>> Cc: oauth
>> Subject: 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 it. 
>> What needs to happen to move forward?
>> 
>> The concept shows up in these three different drafts (that I know of anyway):
>> 
>> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 
>>  
>> has an audience parameter 
>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3
>>  
>> 
>>  has an aud parameter 
>> http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 
>>  
>> has both an audience and a resource resource
>> 
>> All the above apply only to the token request. However, there are ways of 
>> requesting/obtaining access tokens that don't involve the token endpoint 
>>  so I think it follows that 
>>  the same facility should be available for the authorization request too. 
>> 
>> 
>> 
>>  
>> On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig 
>> mailto:hannes.tschofe...@gmx.net>> wrote:
>> 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 needed functionality and
>> where it should be included.
>> 
>> Ciao
>> Hannes
>> 
>> 
>> On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
>> > 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] may still make sense, for
>> > example, I can think of two options:
>> > 1. the client audiences are set out of band during the client
>> > registration time and all the tokens issued to that client will be
>> > restricted accordingly
>> > 2. the client is requesting a specific audience during the grant to
>> > token exchange as per [1]
>> >
>> > I guess 1. is how it is done in practice or is 2. is also a valid option ?
>> >
>> >
>> > Thanks, Sergey
>> >
>> >
>> > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 
>> > 

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

[Mike Jones]

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 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 symmetric key you need to specify what 
Resource server you are sending the token to so that it can be encrypted with 
the correct key.

John B.
On Jan 20, 2016, at 7:47 PM, Nat Sakimura 
mailto:sakim...@gmail.com>> wrote:

+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 authorization from 
the privacy point of view.

So, the processing flow in this case will be:


  1.  The client request an access to the resource type in the scope of the 
authorization request.
  2.  The client request an access token to the resource type to the token 
endpoint with audience/resource/scope parameter.
  3.  The token endpoint responds with token response with oauth-meta header 
indicating the URL of the resource as in  draft-sakimura-oauth-meta.
Best,

Nat


2016年1月21日(木) 7:27 John Bradley mailto:ve7...@ve7jtb.com>>:
+1

On Jan 20, 2016, at 7:25 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> 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 Microsoft services are moving towards using scope values as well.  Sorting 
this out soon would be good.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, January 20, 2016 2:18 PM
To: Hannes Tschofenig
Cc: oauth
Subject: 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 it. What 
needs to happen to move forward?
The concept shows up in these three different drafts (that I know of anyway):

https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 has an 
audience parameter
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3 
has an aud parameter
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has 
both an audience and a resource resource

All the above apply only to the token request. However, there are ways of 
requesting/obtaining access tokens that don't involve the token 
endpoint so I think it follows 
that  the same facility should be available for the authorization request too.


On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
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 needed functionality and
where it should be included.

Ciao
Hannes


On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> 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] may still make sense, for
> example, I can think of two options:
> 1. the client audiences are set out of band during the client
> registration time and all the tokens issued to that client will be
> restricted accordingly
> 2. the client is requesting a specific audience during the grant to
> token exchange as per [1]
>
> I guess 1. is how it is done in practice or is 2. is also a valid option ?
>
>
> Thanks, Sergey
>
>
> [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or

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

[Justin Richer]

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 decision to bring JWT to this 
group, nor do I think we should be necessarily bound by the mistakes of the 
past when making future decisions of what to work on. :)

 — Justin

> On Jan 20, 2016, at 5:07 PM, John Bradley  wrote:
> 
> 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
>> 
> 



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] Status of draft-tschofenig-oauth-audience

[Nat Sakimura]

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 possible
resource endpoints, preferably with more specific rels.
Then, the client can make a second token request using the refresh token,
this time with the concrete resource endpoint URI, to get the access token
to that location.

Nat


2016年1月21日(木) 7:56 Mike Jones :

> 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 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 symmetric key you need to specify what
> Resource server you are sending the token to so that it can be encrypted
> with the correct key.
>
>
>
> John B.
>
> On Jan 20, 2016, at 7:47 PM, Nat Sakimura  wrote:
>
>
>
> +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 authorization from the privacy point of view.
>
>
>
> So, the processing flow in this case will be:
>
>
>
>1. The client request an access to the resource type in the scope of
>the authorization request.
>2. The client request an access token to the resource type to the
>token endpoint with audience/resource/scope parameter.
>3. The token endpoint responds with token response with oauth-meta
>header indicating the URL of the resource as in  draft-sakimura-oauth-meta.
>
> Best,
>
>
>
> Nat
>
>
>
>
>
> 2016年1月21日(木) 7:27 John Bradley :
>
> +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 Microsoft services are moving towards using scope values as well.
> Sorting this out soon would be good.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org ] *On
> Behalf Of *Brian Campbell
> *Sent:* Wednesday, January 20, 2016 2:18 PM
> *To:* Hannes Tschofenig
> *Cc:* oauth
> *Subject:* 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 it. What needs to happen to move forward?
>
> The concept shows up in these three different drafts (that I know of
> anyway):
>
>
> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 has
> an audience parameter
>
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3
>  has
> an aud parameter
> http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has
> both an audience and a resource resource
>
> All the above apply only to the token request. However, there are ways of
> requesting/obtaining access tokens that don't involve the token endpoint
>  so I think it follows
> that  the same facility should be available for the authorization request
> too.
>
>
>
> On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
> 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 needed functionality and
> where it should be included.
>
> Ciao
> Hannes
>
>
>
> On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> > 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] may stil

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

[Nat Sakimura]

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_methods_supported": ["plain", "S256"]
>
>
>
> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> +1
>>
>>
>> Am 06.01.2016 um 18:25 schrieb William Denniss:
>>
>> +1
>>
>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley  wrote:
>>
>>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>>>
>>> John B.
>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <
>>> vladi...@connect2id.com> wrote:
>>> >
>>> > I just noticed PKCE support is missing from the discovery metadata.
>>> >
>>> > Is it a good idea to add it?
>>> >
>>> > Cheers,
>>> >
>>> > Vladimir
>>> >
>>> > --
>>> > Vladimir Dzhuvinov
>>> >
>>> >
>>> > ___
>>> > 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 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] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

[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 added. How should it look?
> 
> Two ideas:
> 
> "code_challenge_methods_supported": ["plain", "S256"]
> 
> or
> 
> "pkce_methods_supported": ["plain", "S256"]
> 
> 
> 
> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt  > wrote:
> +1
> 
> 
> Am 06.01.2016 um 18:25 schrieb William Denniss:
>> +1
>> 
>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley > > wrote:
>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>> 
>> John B.
>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov > > > wrote:
>> >
>> > I just noticed PKCE support is missing from the discovery metadata.
>> >
>> > Is it a good idea to add it?
>> >
>> > Cheers,
>> >
>> > Vladimir
>> >
>> > --
>> > Vladimir Dzhuvinov
>> >
>> >
>> > ___
>> > 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 Mix-Up Mitigation

[Phil Hunt (IDM)]

+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.ietf.org/mail-archive/web/oauth/current/msg15351.html will be 
> incorporated.
> 
> This document is (should be) intended to provide a mitigation to a security 
> problem. As such, it would be nice to see it progress a little faster than 
> the typical WG document. The more quickly the document can progress and/or be 
> perceived as stable, the better.
> 
>> On Tue, Jan 19, 2016 at 4:49 AM, 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
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> 
>> Note: This call is related to the announcement made on the list earlier
>> this month, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>> time for analysis is provided due to the complexity of the topic.
>> 
>> 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

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

[Phil Hunt (IDM)]

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

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

[John Bradley]

+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  > 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.ietf.org/mail-archive/web/oauth/current/msg15351.html 
>>  will be 
>> incorporated.
>> 
>> This document is (should be) intended to provide a mitigation to a security 
>> problem. As such, it would be nice to see it progress a little faster than 
>> the typical WG document. The more quickly the document can progress and/or 
>> be perceived as stable, the better.
>> 
>> On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig 
>> mailto:hannes.tschofe...@gmx.net>> 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
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> 
>> Note: This call is related to the announcement made on the list earlier
>> this month, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html 
>> . More
>> time for analysis is provided due to the complexity of the topic.
>> 
>> 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



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

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

[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) 
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 21, 2016, 9:48 AM John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:
+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) 
mailto:phil.h...@oracle.com>> wrote:

+1 for adoption

+1 for Brian's comments

Phil

On Jan 20, 2016, at 14:42, Brian Campbell 
mailto:bcampb...@pingidentity.com>> 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.ietf.org/mail-archive/web/oauth/current/msg15351.html
 will be incorporated.
This document is (should be) intended to provide a mitigation to a security 
problem. As such, it would be nice to see it progress a little faster than the 
typical WG document. The more quickly the document can progress and/or be 
perceived as stable, the better.

On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> 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
adoption of this document as a starting point for work in the OAuth
working group.

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.
 More
time for analysis is provided due to the complexity of the topic.

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 Mix-Up Mitigation

[Nat Sakimura]

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:* 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 21, 2016, 9:48 AM John Bradley  wrote:
>
> +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 
> 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.ietf.org/mail-archive/web/oauth/current/msg15351.html
> 
> will be incorporated.
>
> This document is (should be) intended to provide a mitigation to a
> security problem. As such, it would be nice to see it progress a little
> faster than the typical WG document. The more quickly the document can
> progress and/or be perceived as stable, the better.
>
>
>
> On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> 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
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Note: This call is related to the announcement made on the list earlier
> this month, see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html
> .
> More
> time for analysis is provided due to the complexity of the topic.
>
> 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 for Native Apps

[Anthony Nadalin]

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 standard.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, January 20, 2016 12:11 PM
To: Nat Sakimura 
Cc: oauth@ietf.org
Subject: 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 
mailto:sakim...@gmail.com>> wrote:

+1 for moving this forward.

2016年1月21日木曜日、John Bradleymailto:ve7...@ve7jtb.com>>さんは書きました:
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
 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 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 libraries for iOS and Android to 
how how to best use View Controllers, and PKCE in native apps on those 
platforms.

We do need to update this doc to reflect what we have learned in the last 6 
months.

One problem we do still have is not having someone with Win 10 mobile 
experience to help document the best practices for that platform.
I don’t understand that platform well enough yet to include anything.

John B.

On Jan 20, 2016, at 12:40 PM, Aaron Parecki 
> wrote:

The section on embedded web views doesn't mention the new iOS 9 
SFSafariViewController which allows apps to display a system browser within the 
application. The new API doesn't give the calling application access to 
anything inside the browser, so it is acceptable for using with OAuth flows. I 
think it's important to mention this new capability for apps to leverage since 
it leads to a better user experience.

I'm sure that can be addressed in the coming months if this document is just 
the starting point.

I definitely agree that a document about native apps is necessary since the 
core leaves a lot of guessing room for an implementation.

For reference, 
https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26

And see the attached screenshot for an example of what it looks like.




Aaron Parecki
aaronparecki.com
@aaronpk


On Tue, Jan 19, 2016 at 3:46 AM, 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 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 p

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

[Nat Sakimura]

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 added. How should it look?
>
> Two ideas:
>
> "code_challenge_methods_supported": ["plain", "S256"]
>
> or
>
> "pkce_methods_supported": ["plain", "S256"]
>
>
>
> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> +1
>>
>>
>> Am 06.01.2016 um 18:25 schrieb William Denniss:
>>
>> +1
>>
>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley  wrote:
>>
>>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>>>
>>> John B.
>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <
>>> vladi...@connect2id.com> wrote:
>>> >
>>> > I just noticed PKCE support is missing from the discovery metadata.
>>> >
>>> > Is it a good idea to add it?
>>> >
>>> > Cheers,
>>> >
>>> > Vladimir
>>> >
>>> > --
>>> > Vladimir Dzhuvinov
>>> >
>>> >
>>> > ___
>>> > 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 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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[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-00
> 
> Please let us know by Feb 9th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
> 
> Note: This call is related to the announcement made on the list earlier
> this month, see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
> time for analysis is provided due to the complexity of the topic.
> 
> 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: OAuth 2.0 for Native Apps

[Antonio Sanso]

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

___
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

[Antonio Sanso]

+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 / 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

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

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

[Mike Jones]

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 document.

*   Added the "state" token request parameter.

*   Added examples.

*   Added John Bradley as an editor.

The specification is available at:

*   http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01

An HTML-formatted version is also available at:

*   http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html

  -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1526 and as 
@selfissued.

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

Re: [OAUTH-WG] Call for Adoption

[Mike Jones]

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-mix-up-mitigation was created in 
collaboration with the security researchers who identified the problems in the 
first place, was vigorously discussed in the security meeting Hannes and 
Torsten held in Darmstadt, and has been since refined based on substantial 
input from the working group.  And at least three implementers have already 
stated that they’ve implemented it.  I’m not saying that it’s, but if there are 
things missing or things that need to be improved in our approach, we should do 
it there, rather introducing a competing approach.

Also, standard OAuth deployments register the client and then use the 
information gathered at registration time for subsequent protocol interactions. 
 They do not need all the configuration information for the authorization 
server to be retransmitted at runtime.  The oauth-meta draft goes too far in 
that direction, at least as I see it.  Returning things two ways creates its 
own problems, as discussed in the Duplicate Information Attacks security 
considerations section (7.2) of the mix-up-mitigation draft.

I’ll note that the mix-up-mitigation approach is compatible with existing 
practice in both static and dynamic metadata discovery.  Replying to Justin’s 
comment that “It's the pre-configured discovery document that's at the root of 
the mix-up attack in the first place” – this is not the case.  The attacks can 
be performed without either discovery or dynamic registration.

I would be interested in hearing a technical discussion on whether there are 
aspects of the oauth-meta approach that mitigate aspects of the attacks that 
the mix-up-mitigation approach does not.  That could help inform whether there 
are additional things we should add to or change in the mix-up draft.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 10:37 PM
To: Justin Richer 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption

+1 to adopt this, and I agree with Justin's comments.

On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer 
mailto:jric...@mit.edu>> wrote:
+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 to give more context, at IETF 94, I have done a presentation on discovery.

According to the minutes,


(f) Discovery (Nat)



 Nat explains his document as an example of the work that has to be 
done

 in the area of discovery, which is a topic that has been identified

 as necessary for interoperability since many years but so far there

 was not time to work on it. Mike, John and Nat are working on a new

 document that describes additional discovery-relevant components.



 Poll: 19 for / zero against / 4 persons need more information.


The document discussed there was 
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a simple 
(only 1-page!) but a very powerful document that nudges towards HATEOAS which 
is at the core of RESTful-ness. It also mitigates the Mix-up attack without 
introducing the concept of issuer which is not in RFC6749. It is also good for 
selecting different endpoints depending on the user authentication and 
authorization results and more privacy sensitive than pre-announced Discovery 
document. It also allows you to find to which protected resource endpoint you 
can use the access token against.

In the last sentence of the minutes, it talks about "a new document that 
describes additional discovery-relevant components". This is 
https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for the 
call for adoption. However, it is only a half of the story. I believe 
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was discussed at 
IETF 94 and had support there should be adopted as well.

Nat Sakimura




2016年1月20日(水) 12:05 Nat Sakimura 
mailto:sakim...@gmail.com>>:
Thanks Hannes.

I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which 
was discussed in Yokohama, and was largely in agreement if my recollection is 
correct. Why is it not in the call for adoption?



2016年1月19日(火) 20:39 Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>>:
Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
since some IESG members like to see an updated list of milestones as
well.

Re: [OAUTH-WG] Call for Adoption

[Nat Sakimura]

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 the thing it
solves.

Nat Sakimura

2016年1月21日(木) 16:02 Mike Jones :

> 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-mix-up-mitigation was created in
> collaboration with the security researchers who identified the problems in
> the first place, was vigorously discussed in the security meeting Hannes
> and Torsten held in Darmstadt, and has been since refined based on
> substantial input from the working group.  And at least three implementers
> have already stated that they’ve implemented it.  I’m not saying that it’s,
> but if there are things missing or things that need to be improved in our
> approach, we should do it there, rather introducing a competing approach.
>
>
>
> Also, standard OAuth deployments register the client and then use the
> information gathered at registration time for subsequent protocol
> interactions.  They do not need all the configuration information for the
> authorization server to be retransmitted at runtime.  The oauth-meta draft
> goes too far in that direction, at least as I see it.  Returning things two
> ways creates its own problems, as discussed in the Duplicate Information
> Attacks security considerations section (7.2) of the mix-up-mitigation
> draft.
>
>
>
> I’ll note that the mix-up-mitigation approach is compatible with existing
> practice in both static and dynamic metadata discovery.  Replying to
> Justin’s comment that “It's the pre-configured discovery document that's
> at the root of the mix-up attack in the first place” – this is not the
> case.  The attacks can be performed without either discovery or dynamic
> registration.
>
>
>
> I would be interested in hearing a technical discussion on whether there
> are aspects of the oauth-meta approach that mitigate aspects of the attacks
> that the mix-up-mitigation approach does not.  That could help inform
> whether there are additional things we should add to or change in the
> mix-up draft.
>
>
>
>   -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *William
> Denniss
> *Sent:* Wednesday, January 20, 2016 10:37 PM
> *To:* Justin Richer 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> +1 to adopt this, and I agree with Justin's comments.
>
>
>
> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer  wrote:
>
> +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 to give more context, at IETF 94, I have done a presentation on
> discovery.
>
>
>
> According to the minutes,
>
>
>
> (f) Discovery (Nat)
>
>
>
>  Nat explains his document as an example of the work that has to 
> be done
>
>  in the area of discovery, which is a topic that has been 
> identified
>
>  as necessary for interoperability since many years but so far 
> there
>
>  was not time to work on it. Mike, John and Nat are working on a 
> new
>
>  document that describes additional discovery-relevant components.
>
>
>
>  Poll: 19 for / zero against / 4 persons need more information.
>
>
>
> The document discussed there was
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
> simple (only 1-page!) but a very powerful document that nudges towards
> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up
> attack without introducing the concept of issuer which is not in RFC6749.
> It is also good for selecting different endpoints depending on the user
> authentication and authorization results and more privacy sensitive than
> pre-announced Discovery document. It also allows you to find to which
> protected resource endpoint you can use the access token against.
>
>
>
> In the last sentence of the minutes, it talks about "a new document that
> describes additional discovery-relevant components". This is
> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
> the call for adoption. However, it is only a half of the story. I believe
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
> discussed at IETF 94 and had support there should be adopted as well.
>
>
>
> Nat Sakimura
>
>
>
>
>
>
>
>

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

[Roland Hedberg]

+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-00
>> 
>> Please let us know by Feb 9th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>> 
>> Note: This call is related to the announcement made on the list earlier
>> this month, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>> time for analysis is provided due to the complexity of the topic.
>> 
>> 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



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

[Mike Jones]

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 were 
listened to in Yokohama, but that didn’t necessarily mean that people agreed 
with the approach.  Participants were already aware of the oauth-meta proposal 
in Darmstadt but no one spoke up in favor of it that I can recall.  Rather, I 
think people were thinking that “less is more”.

There have also been discussions in the last day about how dynamically 
returning a resource URL, which oauth-meta does, is both unnecessary (since the 
client initiated the resource authorization already knowing what resource it 
wants to access) and often problematic, since many authorization servers can 
authorize access to multiple resources.  If anything, the client should be 
telling the authorization server what resource it wants to access – not the 
other way around.

I’m not saying that there aren’t some good ideas in the oauth-meta draft – I’m 
sure there are, just as there are in the approach designed by the participants 
in Darmstadt.  While I volunteered to write the first draft of the 
mix-up-mitigation approach, it really reflects something a lot of people have 
already bought into – as evidenced in the passion in the high-volume “Mix-Up 
About The Mix-Up Mitigation” thread, and not just my personal project.

If you think there are things missing or wrong in the mix-up-mitigation draft, 
please say what they are.  That will help us quickly converge on a solution 
that will work for everyone.

  Sincerely,
  -- Mike

From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Wednesday, January 20, 2016 11:17 PM
To: Mike Jones ; William Denniss 
; Justin Richer 
Cc: oauth@ietf.org
Subject: 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 the thing it 
solves.

Nat Sakimura

2016年1月21日(木) 16:02 Mike Jones 
mailto:michael.jo...@microsoft.com>>:
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-mix-up-mitigation was created in 
collaboration with the security researchers who identified the problems in the 
first place, was vigorously discussed in the security meeting Hannes and 
Torsten held in Darmstadt, and has been since refined based on substantial 
input from the working group.  And at least three implementers have already 
stated that they’ve implemented it.  I’m not saying that it’s, but if there are 
things missing or things that need to be improved in our approach, we should do 
it there, rather introducing a competing approach.

Also, standard OAuth deployments register the client and then use the 
information gathered at registration time for subsequent protocol interactions. 
 They do not need all the configuration information for the authorization 
server to be retransmitted at runtime.  The oauth-meta draft goes too far in 
that direction, at least as I see it.  Returning things two ways creates its 
own problems, as discussed in the Duplicate Information Attacks security 
considerations section (7.2) of the mix-up-mitigation draft.

I’ll note that the mix-up-mitigation approach is compatible with existing 
practice in both static and dynamic metadata discovery.  Replying to Justin’s 
comment that “It's the pre-configured discovery document that's at the root of 
the mix-up attack in the first place” – this is not the case.  The attacks can 
be performed without either discovery or dynamic registration.

I would be interested in hearing a technical discussion on whether there are 
aspects of the oauth-meta approach that mitigate aspects of the attacks that 
the mix-up-mitigation approach does not.  That could help inform whether there 
are additional things we should add to or change in the mix-up draft.

  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On 
Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 10:37 PM
To: Justin Richer mailto:jric...@mit.edu>>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption

+1 to adopt this, and I agree with Justin's comments.

On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer 
mailto:jric...@mit.edu>> wrote:

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

[Roland Hedberg]

+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 implementation experience for OAuth on mobile. 
> But we've come a long way since then, we have the experience now and I think 
> there is a need for leadership in this space, and that it makes sense for the 
> OAUTH-WG to continue our work and provide that leadership.
> 
> The risk of not defining a best practice for native apps is dilution of the 
> open standards – if everyone implements OAuth differently for native apps, 
> and RPs have to write IDP-specific code then what is the point of having 
> OAuth as a standard in the first place? Security is a major concern as well, 
> there are a lot of ways to mess this up and the security situation for OAuth 
> in many native apps is not nearly as good as it could be.
> 
> By providing leadership in the form of a working group document, we can 
> present community advice with the hope that IDPs and RPs alike will follow 
> our recommendations, resulting in more interoperability, better usability and 
> higher security.
> 
> The best part about this spec is that it's pure OAuth! Just wrapped with some 
> native app specific recommendations for both RPs and IDPs, to achieve the 
> desired levels of usability and security on mobile.
> 
> I will point out that we have rough consensus and running code. The rough 
> consensus can be seen from the WG votes, and the sentiment on this thread 
> (your dissenting opinion notwithstanding). Regarding running code, my team is 
> in the process of open sourcing libraries that will implement this best 
> practice to the letter (and the code's already running, I assure you). The 
> proprietary Google Sign-in and Facebook Sign-in SDKs are also using in-app 
> browser tabs for OAuth flows in production today, which I think is further 
> evidence that this is a viable pattern.
> 
> This document and proposal was never part of the OpenID working group that 
> you refer to below.
> 
> I'm not saying the document is perfect, and it is definitely in need of an 
> update! But I'm committed to listening to the community and taking it 
> forward. Now that the dependencies have launched, and our library 
> implementations are done, I plan to update the doc with the feedback from 
> this community, and the lessons we and others have learnt from our 
> implementations.
> 
> I hope the working group will consider adopting this document.
> 
> Kind Regards,
> William
> 
> 
> On Thu, Jan 21, 2016 at 12:33 PM, Anthony Nadalin  
> wrote:
> 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 standard.
> 
> 
> 
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, January 20, 2016 12:11 PM
> To: Nat Sakimura 
> Cc: oauth@ietf.org
> Subject: 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 
> 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 
> 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 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 libraries for iOS and Android 
> to how how to best use View Controllers, and PKCE in native apps on those 
> platforms.
> 
> 
> 
> We do need to update this doc to reflect what we have learned in the last 6 
> months.
> 
> 
> 
> One problem we do still have is not having someone with Win 10 mobile 
> experience to help document the best practices for that platform.
> 
> I don’t understand that platform well enough yet to include anything.
> 
> 
> 
> John B.
> 
> 
> 
> On Jan 20, 2016, at 12:40 PM, Aaron Parecki  wrote:
> 
> 
> 
> The section on embedded web views doesn't mention the new iOS 9 
> SFSafariViewController which allows apps to display a system browser within 
> the application. The new API doesn't give