+1 on all comments, except for some question on 6...
On Thu, Apr 1, 2010 at 11:06 AM, Justin Smith <[email protected]> wrote: > 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). SAML assertions contain the expiry inside, the OAuth "expires" parameter would be redundant, maybe this is way it is optional? But, do we want to make this parameter required in general? Why not leave it optional for all flows? What if an Authorization Server implements some other mechanism to expire them (number of uses for example) and a fixed expiry time does not make sense? > 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 > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
