Just to clarify. Those attending the meeting did not decide. The chairs asked 
Torsten and Anthony to take the text removed and resubmit it for working group 
consideration. The text discussed is all non-normative, and is meant as a 
helpful guide.

As editor, I don't have any objections and think this is a worthwhile effort.

EHL

> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Mike Jones
> Sent: Monday, April 04, 2011 12:06 PM
> To: Skylar Woodward; Marius Scurtescu
> Cc: Kris Selden; oauth@ietf.org
> Subject: [OAUTH-WG] Guidance on Native Applications in the Framework
> Spec (was Flowchart for legs of OAuth)
> 
> One of the results at the OAuth meeting on Friday was that non-normative
> text describing how to use OAuth with native applications will be restored to
> the framework draft.  We could start with the text from past drafts, but it 
> can
> likely be improved upon as well.
> 
> Marius, as someone who has extensively deployed an OAuth protocol with
> native apps, what would you like the draft to say about this?  (Others with
> actual deployments, please respond as well if you have things to add!)
> 
>                               Thanks,
>                               -- Mike
> 
> -----Original Message-----
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Skylar Woodward
> Sent: Monday, April 04, 2011 11:54 AM
> To: Marius Scurtescu
> Cc: Kris Selden; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
> 
> I agree with Marius' points. We plan to support the auth-code flow for native
> apps as well.  There is no reason why native apps can't perform a successful
> auth-code flow, they just do so without client credentials.  However, the
> spec doesn't make it clear that this is viable option.
> 
> skylar
> 
> 
> On Apr 4, 2011, at 2:29 PM, Marius Scurtescu wrote:
> 
> > On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden <kris.sel...@gmail.com>
> wrote:
> >> A typical iPhone app cannot be shipped with a client secret and rightly or
> wrongly users expect to only have to enter their credentials once.
> >>
> >> What is the best profile to use for an app that can't have a client secret
> and needs a refresh token or a long lived access token?
> >
> > The authorization code grant, aka web server flow.
> >
> > The spec is misleading in this respect IMO.
> >
> > Marius
> > _______________________________________________
> > 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

Reply via email to