> -----Original Message----- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Sunday, May 09, 2010 10:29 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt > > > >>> > >>> Right now it depends on the server. > >> > >> The spec should clarify that. Suggested wording: > >> > >> > >> If the client has previously registered a redirection URI with the > >> authorization server, the authorization server MUST verify that the > >> redirection URI received matches the registered URI associated with > >> the client identifier. The components of the redirection URI that > >> must match the registered URI is authorization server dependant. > > > > I don't see how that helps... I also don't see why we can't just profile > > this > and decide on how the matching should be done. We have the state > parameter to help too. > > Don't need to take my wording. We do need to explain the matching.
I agree we need to. Would you like to suggest more detailed rules? > > > >>>> 7. Refreshing an Access Token > >>>> > >>>> I would suggest to add an optional "scope" parameter to this request. > >>>> This could be used to downgrade the scope associated with a token. > >>> > >>> That would be the wrong way to do it given that people will expect > >>> to also > >> be able to upgrade scope. > >> > >> Would you elaborate? Would not providing a scope parameter enable any > >> potential change in scope to the access token? The change may be > >> neither an upgrade or downgrade, just different. > > > > Downgrading scope is the only modification allowed without getting the > end-user involved again (or using any of the flows from the beginning). > When you refresh a token, you can ask to get a new token with less scope > because that will not conflict with the access grant. > > The client could downgrade and then upgrade again later, which would not > change the delegation granted by a user. I think that will cause more confusion and problems than help. I am also not sure if there are real use cases for this limited capability. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
