On Tue, Apr 6, 2010 at 2:44 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> > > > On 4/6/10 7:04 AM, "Evan Gilbert" <uid...@google.com> wrote: > > > > > > > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav <e...@hueniverse.com> > > wrote: > >> Hi Evan, > >> > >> On 4/5/10 4:28 PM, "Evan Gilbert" <uid...@google.com> wrote: > >> > >>> 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > >>> We should have an OPTIONAL username parameter: > >>> username > >>> The resource owner's username. The authorization server MUST only > send > >>> back > >>> refresh tokens or access tokens for this user. > >>> > >>> This is useful for clients where a user is already logged into a 3rd > party > >>> web > >>> site with a specific account, and the client wants the authorization to > >>> match > >>> the specific user. > >> > >> I think introducing the concept of user identity is more complex than > just a > >> username parameter. I agree that it can be useful but we need a more > >> detailed discussion about this before we add it. > > > > I agree issues around user identity are complex. > > > > Would it help to spin up a separate discussion thread on this one issue? > > That's one way. A more developed proposal is another. > Hah, ok :) Can you give more feedback about what kind of information would help clarify? Te exact meaning of the username needs to be tied to some identity system (similiar to the username + password profile), and I wasn't sure how to expand upon it. Proposal: In 2.4.1 & 2.4.2, add the following OPTIONAL parameter username The resource owner's username. The authorization server MUST only send back refresh tokens or access tokens for the user identified by username. > EHL > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
