Hi @all! Here is my feedback to the current version (-10) of the draft. So far it looks really promising to me. Just a view thoughts/ideas/questions:
1.4: Is it necessary for an authorization server to support all client profiles in order to be standard complaint? 1.4.1. Wording: Profile "Web Server" sounds kind of misleading to me. What do you think of "Web Application" as a name for this profile? 4.2. refresh_token: With respect to 4.1.3. the authorization server SHOULD NOT issue a refresh token when the access grant type is set "assertion" (and not only "none"). 5.1.1. In my opinion the access token in this example is (unrealistic) short. Can you think of anyone using tokens this short? 5.2.1. I suppose "The resource server includes ..." not "The authorization server includes ..." is meant in the first sentence here. What I'm still missing in the draft is a way of distinguishing different protected resources when authorizing access. All I can see is a 1:1 relation between AS and PR. Nit-pick: o 1.4.4. para. 2, second sentence: "an assertion". o I would prefer one notation; either "access token" or "access-token", not both in the whole document. Keep up the good work. Regards, Christian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
