> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Foiles, Doug > Sent: Sunday, May 02, 2010 8:41 AM > To: OAuth WG > Subject: Re: [OAUTH-WG] Autonomous clients and resource owners > (editorial) > > I wanted to poke on the idea of not allowing Refresh Tokens for the > assertion flow.
How not leaving this up to the server to decide a bad thing? Clearly not all assertions will map directly to the OAuth token and expiration, so the token is already a different trust relationship. The current draft has a SHOULD NOT for refresh token. > And I am wondering if the assertion flow where the client is acting on behalf > of a user is on the list of things to be added??? This is a problem with the autonomous grouping, not the flow. > And I still don't see the corresponding flow in OAuth 2.0 for an OAuth 1.0 - 2 > Legged use case where clients are acting on behalf of a resource owner that > is not themselves. Will there be a flow to support this??? I can actually > see > how another type of "end user credentials flow" would work where the > credential is something different than the username and password. No. The 1.0 2-legged use-case was really an abuse of the OAuth signature method to make signed requests using a username and password (client credentials) instead of using Basic auth. In OAuth 2.0, you have to go through an additional step: the client first uses its client credentials to get a token (over HTTPS) and it uses that token to make requests (signed or not). EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
