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

[Nat Sakimura]

+1 Those login and logout ceremonies giving false impression of security
probably will diminish its importance pretty quickly. I recon those more as
a privacy feature than security.
2016年2月16日(火) 9:35 Phil Hunt (IDM) :

> +1
>
>
> Phil
>
> On Feb 15, 2016, at 16:50, John Bradley  wrote:
>
> The question is what counts as re-authentication.
>
> It may be that the environment is changing.  Re-prompting for a password
> in many cased just tells you the user has a form filler.
>
> It may be better to use risk based factors such as prompting for a pin, or
> using a local passive biometric, eg has the phone got screen lock and is it
> in proximity to the persons smart watch etc.
>
> What google seems to be doing is using the amr to say how they did the
> last authentication and leave it up to the client to decide if it is good
> enough.
>
> Simple always ask for a password may no longer provide the security that
> most people think it is giving.
>
> Looking at what enterprise customers are asking for, they are becoming
> more concerned with checking the MDM posture of the device at
> authentication.
>
> This is a larger conversation about authentication context and methods.
>
> The establishment of the amr registry will provide a place to document a
> part of this, however authentication context (there is already a registry)
> and amr values themselves are probably out of scope for this WG.
>
> John B.
>
>
> On Feb 15, 2016, at 8:22 PM, Jim Manico  wrote:
>
> Polite comment, Google in general is pretty "open" about session
> management in general - long idle timeout and no apparent absolute timeout.
> For a bank or other organization that produces high risk software, this is
> not standard practice. Re-authentication is a critical security boundary,
> not prompting the user for re-authentication credentials is unacceptable in
> those environments.
>
> I may be jumping in out of context, but fair?
>
> --
> Jim Manico
> @Manicode
> +1 (808) 652-3805
>
> On Feb 15, 2016, at 3:36 PM, William Denniss  wrote:
>
> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID
> Connect), e.g.:
>
>
> https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground_type=code_id=407408718192.apps.googleusercontent.com=openid+profile_prompt=force_type=offline_age=1
>
> The reason we do this is to be explicit about how we are processing the
> "max_age" reauth request, specifically that we don't always prompt the user
> to reauthenticate directly (but do perform in-session risk analysis).
>
> I can see us potentially using the more generic amr values like "user",
> and "mfa" but we will probably avoid very specific ones like "sms" or "otp"
> to avoid brittle relationships with RPs. That said, I don't object to those
> being in the registry, perhaps there is value in some tightly coupled
> enterprise configurations.
>
>
> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi Denniss,
>>
>> out of curiosity: Does Google use amr values?
>>
>> best regards,
>> Torsten.
>>
>>
>> Am 14.02.2016 um 02:40 schrieb William Denniss:
>>
>>
>>
>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones > > wrote:
>>
>>> It's an acceptable fallback option if the working group decides it
>>> doesn't want to register the values that are already in production use at
>>> the time we establish the registry. But add William points out, Google is
>>> already using some of these values. Microsoft is using some of them. The
>>> OpenID MODRNA specs are using some of them. So it seems more efficient to
>>> register them at the same time.
>>>
>>> That would be my preference.
>>>
>>
>> +1, it is also my preference to register the current values.
>>
>> I don't see any harm in the spec that establishes the registry also
>> seeding it with all known values in use at the time of drafting, regardless
>> of the group that originally specified them. Makes the original spec more
>> useful, and avoids the need to submit each value for consideration
>> separately – they can be all be reviewed at the same time.
>>
>>
>> From: Justin Richer 
>>> Sent: ‎2/‎13/‎2016 11:11 AM
>>> To: Phil Hunt 
>>>
>>> Cc:  
>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call
>>> for Adoption Finalized
>>>
>>> Can we just do that, then? Seems to be the easiest way to address
>>> various needs and concerns.
>>>
>>>  — Justin
>>>
>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) 
>>> wrote:
>>>
>>> Yes
>>>
>>> Phil
>>>
>>> On Feb 13, 2016, at 07:59, " 
>>> tors...@lodderstedt.net"  wrote:
>>>
>>> So basically, the RFC could also just establish the new registry and
>>> oidf could feel in the values?
>>>
>>> (just 

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

[Phil Hunt (IDM)]

+1

Phil

> On Feb 15, 2016, at 16:50, John Bradley  wrote:
> 
> The question is what counts as re-authentication.  
> 
> It may be that the environment is changing.  Re-prompting for a password in 
> many cased just tells you the user has a form filler.
> 
> It may be better to use risk based factors such as prompting for a pin, or 
> using a local passive biometric, eg has the phone got screen lock and is it 
> in proximity to the persons smart watch etc.   
> 
> What google seems to be doing is using the amr to say how they did the last 
> authentication and leave it up to the client to decide if it is good enough.
> 
> Simple always ask for a password may no longer provide the security that most 
> people think it is giving.
> 
> Looking at what enterprise customers are asking for, they are becoming more 
> concerned with checking the MDM posture of the device at authentication.
> 
> This is a larger conversation about authentication context and methods.
> 
> The establishment of the amr registry will provide a place to document a part 
> of this, however authentication context (there is already a registry) and amr 
> values themselves are probably out of scope for this WG.
> 
> John B.
> 
> 
>> On Feb 15, 2016, at 8:22 PM, Jim Manico  wrote:
>> 
>> Polite comment, Google in general is pretty "open" about session management 
>> in general - long idle timeout and no apparent absolute timeout. For a bank 
>> or other organization that produces high risk software, this is not standard 
>> practice. Re-authentication is a critical security boundary, not prompting 
>> the user for re-authentication credentials is unacceptable in those 
>> environments.
>> 
>> I may be jumping in out of context, but fair?
>> 
>> --
>> Jim Manico
>> @Manicode
>> +1 (808) 652-3805
>> 
>>> On Feb 15, 2016, at 3:36 PM, William Denniss  wrote:
>>> 
>>> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID 
>>> Connect), e.g.:
>>> 
>>> https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground_type=code_id=407408718192.apps.googleusercontent.com=openid+profile_prompt=force_type=offline_age=1
>>> 
>>> The reason we do this is to be explicit about how we are processing the 
>>> "max_age" reauth request, specifically that we don't always prompt the user 
>>> to reauthenticate directly (but do perform in-session risk analysis).
>>> 
>>> I can see us potentially using the more generic amr values like "user", and 
>>> "mfa" but we will probably avoid very specific ones like "sms" or "otp" to 
>>> avoid brittle relationships with RPs. That said, I don't object to those 
>>> being in the registry, perhaps there is value in some tightly coupled 
>>> enterprise configurations.
>>> 
>>> 
 On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt 
  wrote:
 Hi Denniss,
 
 out of curiosity: Does Google use amr values? 
 
 best regards,
 Torsten.
 
 
> Am 14.02.2016 um 02:40 schrieb William Denniss:
> 
> 
>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones 
>>  wrote:
>> It's an acceptable fallback option if the working group decides it 
>> doesn't want to register the values that are already in production use 
>> at the time we establish the registry. But add William points out, 
>> Google is already using some of these values. Microsoft is using some of 
>> them. The OpenID MODRNA specs are using some of them. So it seems more 
>> efficient to register them at the same time.
>> 
>> That would be my preference.
> 
> +1, it is also my preference to register the current values.
> 
> I don't see any harm in the spec that establishes the registry also 
> seeding it with all known values in use at the time of drafting, 
> regardless of the group that originally specified them. Makes the 
> original spec more useful, and avoids the need to submit each value for 
> consideration separately – they can be all be reviewed at the same time. 
> 
> 
>> From: Justin Richer
>> Sent: ‎2/‎13/‎2016 11:11 AM
>> To: Phil Hunt
>> 
>> Cc: 
>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
>> Adoption Finalized
>> 
>> Can we just do that, then? Seems to be the easiest way to address 
>> various needs and concerns. 
>> 
>>  — Justin
>> 
>>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM)  
>>> wrote:
>>> 
>>> Yes
>>> 
>>> Phil
>>> 
>>> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net" 
>>>  wrote:
>>> 
 So basically, the RFC could also just establish the new registry and 
 oidf could feel in the values?
 
 (just trying to understand)
 
 

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

[Phil Hunt (IDM)]

In older systems, time based logout is all you have if you aren't assessing 
risk. 

I would think over time will quickly diminish in its importance (or as best 
practice) - at least as the single method for determine a session should end 
other than explicit logout. 

Phil

> On Feb 15, 2016, at 16:22, Jim Manico  wrote:
> 
> Polite comment, Google in general is pretty "open" about session management 
> in general - long idle timeout and no apparent absolute timeout. For a bank 
> or other organization that produces high risk software, this is not standard 
> practice. Re-authentication is a critical security boundary, not prompting 
> the user for re-authentication credentials is unacceptable in those 
> environments.
> 
> I may be jumping in out of context, but fair?
> 
> --
> Jim Manico
> @Manicode
> +1 (808) 652-3805
> 
>> On Feb 15, 2016, at 3:36 PM, William Denniss  wrote:
>> 
>> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID 
>> Connect), e.g.:
>> 
>> https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground_type=code_id=407408718192.apps.googleusercontent.com=openid+profile_prompt=force_type=offline_age=1
>> 
>> The reason we do this is to be explicit about how we are processing the 
>> "max_age" reauth request, specifically that we don't always prompt the user 
>> to reauthenticate directly (but do perform in-session risk analysis).
>> 
>> I can see us potentially using the more generic amr values like "user", and 
>> "mfa" but we will probably avoid very specific ones like "sms" or "otp" to 
>> avoid brittle relationships with RPs. That said, I don't object to those 
>> being in the registry, perhaps there is value in some tightly coupled 
>> enterprise configurations.
>> 
>> 
>>> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt 
>>>  wrote:
>>> Hi Denniss,
>>> 
>>> out of curiosity: Does Google use amr values? 
>>> 
>>> best regards,
>>> Torsten.
>>> 
>>> 
 Am 14.02.2016 um 02:40 schrieb William Denniss:
 
 
> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones 
>  wrote:
> It's an acceptable fallback option if the working group decides it 
> doesn't want to register the values that are already in production use at 
> the time we establish the registry. But add William points out, Google is 
> already using some of these values. Microsoft is using some of them. The 
> OpenID MODRNA specs are using some of them. So it seems more efficient to 
> register them at the same time.
> 
> That would be my preference.
 
 +1, it is also my preference to register the current values.
 
 I don't see any harm in the spec that establishes the registry also 
 seeding it with all known values in use at the time of drafting, 
 regardless of the group that originally specified them. Makes the original 
 spec more useful, and avoids the need to submit each value for 
 consideration separately – they can be all be reviewed at the same time. 
 
 
> From: Justin Richer
> Sent: ‎2/‎13/‎2016 11:11 AM
> To: Phil Hunt
> 
> Cc: 
> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
> Adoption Finalized
> 
> Can we just do that, then? Seems to be the easiest way to address various 
> needs and concerns. 
> 
>  — Justin
> 
>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM)  
>> wrote:
>> 
>> Yes
>> 
>> Phil
>> 
>> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net" 
>>  wrote:
>> 
>>> So basically, the RFC could also just establish the new registry and 
>>> oidf could feel in the values?
>>> 
>>> (just trying to understand)
>>> 
>>> 
>>> 
>>>  Originalnachricht 
>>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call 
>>> for Adoption Finalized
>>> Von: Mike Jones 
>>> An: tors...@lodderstedt.net,John Bradley 
>>> Cc: oauth@ietf.org
>>> 
>>> The context that most people on this thread probably don’t have is that 
>>> an IANA registry can only be established by an RFC.  Non-RFC 
>>> specifications, such as OpenID specifications, can *register* values in 
>>> a registry, but they cannot *establish* a registry.  The OpenID 
>>> Foundation inquired about this with the IETF before OpenID Connect was 
>>> finalized and learned that its specifications could not establish IANA 
>>> registries.  Otherwise, they would have.
>>> 
>>>  
>>> 
>>> Instead, RFCs need to be created to establish registries – even for 
>>> values first defined in non-RFC specifications.  This specification is 
>>> one example of doing this.

[OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-07.txt

[Nat Sakimura]

It now shows how to return multiple endpoints in web linking.
Also, added Resource Endpoint response header.

Best,

nat

-- Forwarded message -
From: 
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake , Nat Sakimura , Sascha
Preibisch , Sascha Preibisch <
sascha.preibi...@gmail.com>



A new version of I-D, draft-sakimura-oauth-meta-07.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Name:   draft-sakimura-oauth-meta
Revision:   07
Title:  OAuth Response Metadata
Document date:  2016-02-12
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-07.txt
Status: https://datatracker.ietf.org/doc/draft-sakimura-oauth-meta/
Htmlized:   https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
Diff:
https://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-07

Abstract:
   This specification defines an extensible metadata that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed either as a link header, or
   query parameters.  It will allow the client to learn where the
   members in the response could be used, what is the characteristics of
   the payload is, how it should be processed, and so on.  Since they
   are just additional response header/query parameters, any client that
   does not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to take the
   advantage of the extension.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

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

[John Bradley]

The question is what counts as re-authentication.  

It may be that the environment is changing.  Re-prompting for a password in 
many cased just tells you the user has a form filler.

It may be better to use risk based factors such as prompting for a pin, or 
using a local passive biometric, eg has the phone got screen lock and is it in 
proximity to the persons smart watch etc.   

What google seems to be doing is using the amr to say how they did the last 
authentication and leave it up to the client to decide if it is good enough.

Simple always ask for a password may no longer provide the security that most 
people think it is giving.

Looking at what enterprise customers are asking for, they are becoming more 
concerned with checking the MDM posture of the device at authentication.

This is a larger conversation about authentication context and methods.

The establishment of the amr registry will provide a place to document a part 
of this, however authentication context (there is already a registry) and amr 
values themselves are probably out of scope for this WG.

John B.


> On Feb 15, 2016, at 8:22 PM, Jim Manico  wrote:
> 
> Polite comment, Google in general is pretty "open" about session management 
> in general - long idle timeout and no apparent absolute timeout. For a bank 
> or other organization that produces high risk software, this is not standard 
> practice. Re-authentication is a critical security boundary, not prompting 
> the user for re-authentication credentials is unacceptable in those 
> environments.
> 
> I may be jumping in out of context, but fair?
> 
> --
> Jim Manico
> @Manicode
> +1 (808) 652-3805
> 
> On Feb 15, 2016, at 3:36 PM, William Denniss  > wrote:
> 
>> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID 
>> Connect), e.g.:
>> 
>> https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground_type=code_id=407408718192.apps.googleusercontent.com=openid+profile_prompt=force_type=offline_age=1
>>  
>> 
>> 
>> The reason we do this is to be explicit about how we are processing the 
>> "max_age" reauth request, specifically that we don't always prompt the user 
>> to reauthenticate directly (but do perform in-session risk analysis).
>> 
>> I can see us potentially using the more generic amr values like "user", and 
>> "mfa" but we will probably avoid very specific ones like "sms" or "otp" to 
>> avoid brittle relationships with RPs. That said, I don't object to those 
>> being in the registry, perhaps there is value in some tightly coupled 
>> enterprise configurations.
>> 
>> 
>> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt 
>> > wrote:
>> Hi Denniss,
>> 
>> out of curiosity: Does Google use amr values? 
>> 
>> best regards,
>> Torsten.
>> 
>> 
>> Am 14.02.2016 um 02:40 schrieb William Denniss:
>>> 
>>> 
>>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones >> > wrote:
>>> It's an acceptable fallback option if the working group decides it doesn't 
>>> want to register the values that are already in production use at the time 
>>> we establish the registry. But add William points out, Google is already 
>>> using some of these values. Microsoft is using some of them. The OpenID 
>>> MODRNA specs are using some of them. So it seems more efficient to register 
>>> them at the same time.
>>> 
>>> That would be my preference.
>>> 
>>> +1, it is also my preference to register the current values.
>>> 
>>> I don't see any harm in the spec that establishes the registry also seeding 
>>> it with all known values in use at the time of drafting, regardless of the 
>>> group that originally specified them. Makes the original spec more useful, 
>>> and avoids the need to submit each value for consideration separately – 
>>> they can be all be reviewed at the same time. 
>>> 
>>> 
>>> From: Justin Richer 
>>> Sent: ‎2/‎13/‎2016 11:11 AM
>>> To: Phil Hunt 
>>> 
>>> Cc:   
>>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
>>> Adoption Finalized
>>> 
>>> Can we just do that, then? Seems to be the easiest way to address various 
>>> needs and concerns. 
>>> 
>>>  — Justin
>>> 
 On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) > wrote:
 
 Yes
 
 Phil
 
 On Feb 13, 2016, at 07:59, " 
 tors...@lodderstedt.net 
 " 

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

[Jim Manico]

Polite comment, Google in general is pretty "open" about session management in 
general - long idle timeout and no apparent absolute timeout. For a bank or 
other organization that produces high risk software, this is not standard 
practice. Re-authentication is a critical security boundary, not prompting the 
user for re-authentication credentials is unacceptable in those environments.

I may be jumping in out of context, but fair?

--
Jim Manico
@Manicode
+1 (808) 652-3805

> On Feb 15, 2016, at 3:36 PM, William Denniss  wrote:
> 
> We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID 
> Connect), e.g.:
> 
> https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground_type=code_id=407408718192.apps.googleusercontent.com=openid+profile_prompt=force_type=offline_age=1
> 
> The reason we do this is to be explicit about how we are processing the 
> "max_age" reauth request, specifically that we don't always prompt the user 
> to reauthenticate directly (but do perform in-session risk analysis).
> 
> I can see us potentially using the more generic amr values like "user", and 
> "mfa" but we will probably avoid very specific ones like "sms" or "otp" to 
> avoid brittle relationships with RPs. That said, I don't object to those 
> being in the registry, perhaps there is value in some tightly coupled 
> enterprise configurations.
> 
> 
>> On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt 
>>  wrote:
>> Hi Denniss,
>> 
>> out of curiosity: Does Google use amr values? 
>> 
>> best regards,
>> Torsten.
>> 
>> 
>>> Am 14.02.2016 um 02:40 schrieb William Denniss:
>>> 
>>> 
>>> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones  
>>> wrote:
 It's an acceptable fallback option if the working group decides it doesn't 
 want to register the values that are already in production use at the time 
 we establish the registry. But add William points out, Google is already 
 using some of these values. Microsoft is using some of them. The OpenID 
 MODRNA specs are using some of them. So it seems more efficient to 
 register them at the same time.
 
 That would be my preference.
>>> 
>>> +1, it is also my preference to register the current values.
>>> 
>>> I don't see any harm in the spec that establishes the registry also seeding 
>>> it with all known values in use at the time of drafting, regardless of the 
>>> group that originally specified them. Makes the original spec more useful, 
>>> and avoids the need to submit each value for consideration separately – 
>>> they can be all be reviewed at the same time. 
>>> 
>>> 
 From: Justin Richer
 Sent: ‎2/‎13/‎2016 11:11 AM
 To: Phil Hunt
 
 Cc: 
 Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
 Adoption Finalized
 
 Can we just do that, then? Seems to be the easiest way to address various 
 needs and concerns. 
 
  — Justin
 
> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM)  
> wrote:
> 
> Yes
> 
> Phil
> 
> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net" 
>  wrote:
> 
>> So basically, the RFC could also just establish the new registry and 
>> oidf could feel in the values?
>> 
>> (just trying to understand)
>> 
>> 
>> 
>>  Originalnachricht 
>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for 
>> Adoption Finalized
>> Von: Mike Jones 
>> An: tors...@lodderstedt.net,John Bradley 
>> Cc: oauth@ietf.org
>> 
>> The context that most people on this thread probably don’t have is that 
>> an IANA registry can only be established by an RFC.  Non-RFC 
>> specifications, such as OpenID specifications, can *register* values in 
>> a registry, but they cannot *establish* a registry.  The OpenID 
>> Foundation inquired about this with the IETF before OpenID Connect was 
>> finalized and learned that its specifications could not establish IANA 
>> registries.  Otherwise, they would have.
>> 
>>  
>> 
>> Instead, RFCs need to be created to establish registries – even for 
>> values first defined in non-RFC specifications.  This specification is 
>> one example of doing this.
>> 
>>  
>> 
>>   -- Mike
>> 
>>  
>> 
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of 
>> tors...@lodderstedt.net
>> Sent: Saturday, February 13, 2016 6:37 AM
>> To: John Bradley 
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for 
>> Adoption Finalized
>> 
>>  
>> 
>> We 

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

[Eduardo Gueiros]

+1 Being in the mobile space myself and constantly meeting with native app
developers I've heard my share of horror stories on how OAuth was
implemented, myself being guilty of being "creative" around OAuth.

This draft is be of great value to those of us who are around these
developers, we'll be helping bringing awareness about the correct practices
suggested in the document.

On Fri, Feb 5, 2016 at 8:10 AM, Adam Lewis  wrote:

> +1 that it should be Informational.
>
> Also, I never got to respond to the original request, but I am heavily in
> favor of this draft. I talk with a lot of native app developers who are
> clueless about how to implement OAuth.  The core RFC is very web app
> oriented.  I look forward to having a more profiled RFC to point them to :-)
>
> adam
>
> On Thu, Feb 4, 2016 at 7:13 PM, Justin Richer  wrote:
>
>> I’d like to note that when Tony brought up it being Experimental on the
>> list, several of us (myself included) pointed out that Informational is the
>> correct designation for this specification.
>>
>>  — Justin
>>
>> > On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig <
>> hannes.tschofe...@gmx.net> wrote:
>> >
>> > Hi all,
>> >
>> > On January 19th I posted a call for adoption of the OAuth 2.0 for Native
>> > Apps specification, see
>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15400.html
>> >
>> > There was very positive feedback during the Yokohama IETF meeting to
>> > work on this document in the OAuth working group. More than 10 persons
>> > responded positively to the call on the mailing list as well.
>> >
>> > Several persons provided additional input for content changes during the
>> > call and here are the relevant links:
>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15434.html
>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15435.html
>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15438.html
>> >
>> > Tony also noted that this document should become an Experimental RFC
>> > rather than a Standards Track RFC. The chairs will consult with the
>> > Security Area directors on this issue.
>> >
>> > To conclude, based on the call  will
>> > become the starting point for work in OAuth. Please submit the document
>> > as draft-ietf-oauth-native-apps-00.txt.
>> >
>> > Ciao
>> > Hannes & Derek
>> >
>> >
>> >
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ___
>> 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
>
>


-- 
-- 
*Eduardo Gueiros*
*Director, Mobile B.U.* |  Jive Communications, Inc.
jive.com  |  *eguei...@jive.com *

 


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