Thanks Dick and Evan for the feedback. Responses:
> It looks like you are proposing that ALL rich clients have to have a call back URL to get their Access Token. Would you elaborate on this requirement?
I'm sorry for the confusion; I didn't mean to mix this in with the Rich App Profile. I originally began by copying the Web App profile (5.4), but I suppose in retrospect it's probably better to mix with Rich App.
Frankly, I'd like to separate out desktop apps with access to a browser from desktop apps without; make the callback url required in this profile, and put the weird user-entered token into its own profile. I think that will be pretty rare relative to the other profile usage.
> I do think that the spec needs to describe how the Client gets the Access Token. I found myself wondering how the Access Token
> magically gets from the server where the callback URL is to the client.
I added a section 126.96.36.199, "Choosing a callback URL":
Because the raw Access _Token will be passed back on this Callback URL, it is strongly RECOMMENDED that the Callback URL be HTTPS, or that it include a hash ("#") in the URL to prevent the Access Token from being transmitted over an insecure line.
> I'm confused by 5.5.5 is there (the section on refresh tokens)
The use cases here should certainly be flushed out a bit more; I think Brian mentioned some similar cases on his side. Also, the term "Refresh" token isn't really appropriate because you're not necessarily refreshing a short-lived token; you may exchange it for a longer-lived one, or something.
> Registration and obtaining a client identifier should still be a MAY.
I copied the provisioning section from 5.4.1, the Web App profile:
>> Prior to initiating this protocol profile, the Client MUST have obtained a Client Identifier
>> and Client Secret from the Authorization Server. The Authorization Server MAY have
>> also required the Client to pre-register their Callback URL.
I'm not sure of why that is different from 5.5.1, or which one is most appropriate here. Facebook would still require a client ID regardless.
> Should support an OPTIONAL wrap_username.
I understand the desire for this, but in the interest of keeping it simple, is it really necessary as a core part of the spec? What are some examples of real-world use cases for this?
> Recommendation should be to always use the hash. Just https:// has the problem of leaking token in referrers (I think).
If the callback url doesn't have any included iframes or images, then there is no risk of leaking referers, but I take your point. Since this is just a recommendation, we should think about how complex we want to make it, and perhaps we should just say "use the hash" unless there's a situation where that doesn't work.
> The user prompt should be a MAY. If the user has already granted consent for the app to access data, the authorization server may redirect back with a token without user interaction.
Good point. My initial inclination is to agree with you, as that is the behavior Facebook takes today.
However: in OpenID we have two modes, checkid_setup and checkid_immediate, and many providers implement checkid_setup to always show an auth dialog - even if the user has already authed. Without a clear MUST, the behavior becomes inconsistent as some providers choose to show the dialog and some don't; I'm just curious if people have strong feelings one way or another about this.
Now that I see the other thread, I agree with the addition of a "mode" parameter to distinguish behavior like this.