>>> >>> 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. > >>>> 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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
