Hi Justin,
On 4/1/10 11:06 AM, "Justin Smith" <justi...@microsoft.com> wrote: > 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. It's marked as an open issue. I personally don't care much either way but can see the reasons behind those for and against a (short) hard limit. Experience has shown this is a problem as most libraries assume a certain size will work just fine and then blow up. Last time it was debated here it didn't end with a consensus call so feel free to ask the chairs for one or continue debating it. > 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. I removed it (for now) because it was (way way) under specified. The only reason for a spec is interop. This parameter hurts interop because it forces library to implement something they cannot understand, or understand based on one deployment. This debate has been going on for a long time and solving it by simply adding a placeholder for scope without *any* structure or definition is not how well designed protocols are written. I have always maintained that OAuth needs a basic facility to negotiate scope. It can be as simple as an opaque string identifying a set of resources (e.g. HTTP auth realms), a JSON string of key/value pairs, etc. But as present in WRAP and imported by David it is utterly useless (it is and under-specified SHOULD - I am not really sure what it is to be used for). Write a proposal and we can add it back. > 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." What token? The authorization endpoint isn't an OAuth-protected resource. > 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." This isn't the old testament. No need to look for hidden meaning. The spec is about getting access to protected resources, generally dealing with *a* protected resource. How resources are segmented is beyond the scope. I think it is more useful to talk about it using simpler assumptions - it doesn't prevent the more complex use cases. > 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). I didn't really get to that part yet in my full rewrite - just imported it with small changes. The new spec has a simple authorization endpoint and it requires SSL/TLS (or other secure channels). The same applies to this flow. The assertion might not be plain text but the resulting token is. > 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. Yep. On my list. Thanks! EHL > > --justin > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
