Eran, Good progress. A few comments below:
Sec. 2.2. Flow Parameters: Comment 1: The recommendation to keep access tokens less than 255 chars seems bizarre. I'd like to remove it entirely. Previous threads have discussed this. General comment on the flows: Comment 2: The scope parameter (from WRAP) is missing from all of the flows. How does the client indicate which protected resource it intends to access? In WRAP this was an optional parameter, but it seems important when a single AS controls access to many resources. Sec. 2.3. Client Credentials: "When requesting access from the authorization server, the client identifies itself using its authorization-server-issued client credentials." Comment 3: This isn't the case when the client is presenting a token issued by another server. I suggest a change to something like the following: "When requesting access from the authorization server, the client identifies itself using client credentials known to the authorization server." Sec. 2.4. User Delegation Flows: "Instead, the end user authenticates directly with the authorization server, and grants client access to its protected resources." Comment 4: This is a minor nit, but the AS may not grant access to all of the PRs it controls access to. I suggest a change to something like the following: "... and grants client access to the requested protected resources." Sec. 2.6.2. SAML Assertion Flow: "Since requests to the authorization endpoint result in the transmission of plain text credentials in the HTTP request and response, ..." Comment 5: In the case of the SAML assertion flow (or an assertion of another format), it isn't necessarily the case that the assertion is plain text. You might want to change it to: "...authorization endpoint may result in the...". Comment 6: why is expiration optional in the response? It seems like it should be mandatory (as it is in the other flows). Sec. 2.6.1 Client Credentials Flow: Comment 7: Why require a refresh token? Assumedly the client has to keep the client_id and client_secret, so why not just present them to the AS again for an access token? Brian/Marius/Dick brought this up earlier - you just might not have gotten there yet. --justin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, March 31, 2010 6:22 PM To: OAuth WG Subject: [OAUTH-WG] Draft progress update I'm making good progress working off David's draft and bringing text from WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far it is largely in line with David's proposal and the majority of changes are purely editorial. The only significant change I have made (which is of course open to debate) is renaming all the authorization flows parameters. I dropped the oauth_ prefix (no real need since these are purely OAuth endpoints, not protected resources), and made most of the parameter names shorter. I am not done so they are not consistent yet. You can follow my progress (changes every few hours) at: http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth .txt Please feel free to comment on anything you like or dislike. I will publish the whole thing as an I-D once it is feature complete for the WG to discuss before we promote this to a WG draft. I hope to be done with the initial draft by middle of next week (I'll be flying most of Fri-Sat so no progress over the weekend). 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
