I'm currently finishing an extension spec for client-to-client access delegation based on the assertion profile. I believe it will use the client secret and return a refresh token, because the assertion is meant to be temporary, at least in its current form. If the assertions are moving in a different direction I will need to refactor to follow suit. (btw, expect a url to my draft by the end of the week, I hope) ---- -- Justin Hart -- [email protected]
On Jul 7, 2010, at 3:18 PM, Eran Hammer-Lahav wrote: > I don't have time to go dig through the list archive. > > > On 7/7/10 2:02 PM, "Brian Eaton" <[email protected]> wrote: > >> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav <[email protected]> >> wrote: >>> It is pretty much the same as originally proposed. Any recent changes are an >>> oversight, not any intentional change. Since it was proposed, the only >>> change made (with full consensus) was to allow client authentication as an >>> optional request parameter, as well as allow a refresh token as an optional >>> response parameter. >> >> Can you point me to the e-mail threads that reached consensus on using >> client authentication? > > This was requested a few months ago and was included in -05 as optional. I > did not see any feedback requesting to remove this. > >> Can you point me to the e-mail threads that reached consensus on >> returning a refresh token? > > I raised this a long time ago about making the token endpoint output > consistent across all request types. At the time, consensus was that there > was no reason not to allow it, but that in general is should not be done > (refresh token when using assertions). > > The current language has a SHOULD NOT issue a refresh token. It is not a > MUST NOT because someone recently asked for the ability to issue a refresh > token when the client nature prevents it from retaining the original > assertion used. > > If you have an objection to the SHOULD NOT (vs. MUST NOT), please raise it > the the group will discuss. > > EHL > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
