Hi! Thanks for the feedback! :-)
Am 11.08.10 10:20, schrieb Lukas Rosenstock: > 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. I agree, there is also a client_url which might also be client_uri then. > 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. Except maybe length. It might depend on how much metadata in the end will be transferred from client to server (eventually with a signature) but a good point indeed. > 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. We have that in the push version but not in pull where it probably should be added. > - 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. I wonder if this should be part of the client registration response or maybe part of the general AS metadata as I assume it's more of a global attribute and not one per client. As for temporary/permanent wouldn't the server decide based on the expires_in attribute? In UMA though we are probably more interesting in long term relationships to be able to identify clients over time. cheers, Christian > > Thanks and regards, > Lukas Rosenstock > > [*] http://openidconnect.com/ > > > 2010/8/10 Eve Maler <e...@xmlgrrl.com <mailto: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 -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH http://mrtopf.de/blog Hanbrucher Str. 33 http://twitter.com/mrtopf 52064 Aachen Skype: HerrTopf Tel: +49 241 400 730 0 c...@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf Podcasts: Der OpenWeb-Podcast (http://openwebpodcast.de) Data Without Borders (http://datawithoutborders.net) Politisches: http://politfunk.de/ Technical: http://comlounge.tv/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
