Please see my reply to James's posting and contribute to the Discovery requirements thread.
One think I want to point out: proxying the authz server may help during the initial discovery. Once the Client obtained a refresh token, directly discovering the tokens endpoint (or a revocation endpoint) is as efficient then asking the resource server. But it appears more natural to me. regards, Torsten. Am 04.08.2010 um 07:01 schrieb William Mills <[email protected]>: > At the very least we need to minimize the hoops the client needs to jump > through. The resource server advertising enpoints allows a simple way to > minimize on one path. > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Manger, James H >> Sent: Tuesday, August 03, 2010 8:01 PM >> To: Torsten Lodderstedt >> Cc: [email protected] >> Subject: Re: [OAUTH-WG] OAuth & Protected feeds >> >> Torsten, >> >>>> This example illustrates that OAuth2 discovery needs to >> let a service >>>> explicitly indicate whether a direct and/or >> user-delegation flow is required. >>>> For instance, a "WWW-Authenticate: OAuth2" response could >> define 2 parameters: >>>> 'user-uri' and 'token-uri'. If only one is present, only the >>>> corresponding mode is useful in this interaction. >> >>> In my opinion, this decision is up to the authorization >> server and not >>> the resource server. Or should both be possible? What do you think? >> >> Theoretically, the decision should probably be up to the >> authorization server. >> In practise, however, the decision should be *delivered* from >> the resource server. >> >> It is resources that apps are ultimately interested in. >> It is at a resource where an app should start (unless it can >> skip some steps by using some service-specific knowledge). >> Consequently, delivering the decision from the resource >> server is more efficient. >> It avoids an extra step (resource server -> authz server -> answer). >> >> Separating the authorization server from resource servers is >> useful for restricting the exposure of long-term secrets. It >> is not necessary, however, for the delivery of discovery information. >> >> -- >> James Manger >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
