Nice to see this draft! I've just read it and would like to provide some feedback:
1) redirect_url vs. redirect_uri: In different flows, different terms have been used. I think that should be consistent and it should be uri. 2) Data formats for requests: This spec uses JSON for everything. The core OAuth (draft 10) uses encoded forms for the request and JSON for the response. Why not make it consistent with that? I don't see any requirement to actually POST in JSON as well. 3) The OpenID Connect proposal* includes something similar. For the response, they have added a few more parameters along with client_id and client_secret. To quote it: - expires_in - The number of seconds that this id and secret are good for or "0" if it does not expire. - flows_supported - A comma separated list of the OAuth 2.0 flows which this server supports. The server MUST support the Web server (web_server) and User-Agent (user_agent) flows. Don't you think those would be useful?! Also, so far there's no information (or I didn't see it ...) on whether dynamic registration should be considered temporary or permanent. Thanks and regards, Lukas Rosenstock [*] http://openidconnect.com/ 2010/8/10 Eve Maler <e...@xmlgrrl.com> > Folks-- The UMA group has produced the following I-D as input to the OAuth > discovery/registration/binding discussion. We wanted to set forth our > requirements (knowing that there may be other requirements from the wider > community) and propose some solutions that meet them. If further discussion > seems to warrant an updating of this draft, we're happy to do that. (If you > have interest in getting involved in UMA-specific work, feel free to drop me > a note.) > > Eve > > http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
