+1 to ensuring that dynamic introduction is possible. I see a lot of discussions that end up saying that this or that can be spec'd in the server docs and the client hard coded to the docs; this is fine for some features but not for very general ones that everybody needs to use.
On Sunday, March 21, 2010, Eve Maler <e...@xmlgrrl.com> wrote: > David, great stuff -- thanks for putting this together! Here are a few > comments and questions from a quick read on the plane down to Anaheim, in > spec order (the weight/priority therefore varies widely). > > Abstract > > - "delegate": The use of this word seems like it's different from how it's > been used in the past, e.g. in "user delegation". It's not a big deal, but > possibly confusing. > > Introduction: > > - I'm glad there's a hint here of "autonomously or on behalf of an end-user", > but I notice the distinction between "user delegation flows" and > "autonomous-client flows" introduced by WRAP seems to have been made more > implicit in this draft. UMA has an interest in understanding very carefully > how flows get distinguished along these lines, and in fact we may need to > define even more flows and types of flows for our own purposes (see our > Lexicon at http://kantarainitiative.org/confluence/display/uma/Lexicon for > more). Hope to discuss this a bit tomorrow. (And see more below in my > comments on 2.5.) > > - "provisioning tokens": I'd say resource owners don't personally provision > tokens, but rather signal that authorization servers should do so on their > behalf. > > - The use of "server" in the intro is very natural. See terminology comments > below for more. > > 1.3. Terminology > > - access token: The client might instead be making requests on behalf of > itself, not "the user", right? > > - authorization server and protected resource: These definitions cry out to > have a formal definition of "server" (or "protected resource server"?) in > this section as well, since "server" is already invoked quite naturally in a > few places to mean the server of a protected resource. Though the definition > of protected resource says it's the resource served by an HTTP server, a few > remaining WRAP-inherited instances of the term elsewhere try to force it to > be both. I have some additional comments below that rely on a nice clean > distinction between the authorization server and the server of a protected > resource, because even though they're often colocated in pure-OAuth use > cases, UMA makes strategic use of the option to separate them. (Oh, also: > s/A HTTP/An HTTP/) > > - client identifier: s/used used/used/ > > - resource owner: "such that it issues...": This is a bit awkward. Maybe say > "to approve the issuing of an access token to a client"? > > 1.3.1. Endpoints > > - "such as via documentation": FWIW, because UMA goes for dynamic > introduction of various parties, we're using hostmeta and XRD to do this sort > of thing. Is there any wider interest in providing a (perhaps merely > advisory) method of documentation that involves these technologies (or > similar), to get greater interop? > > - "API request": Because I'm coming from a mindset that sees all web > resources as possibly being "OAuth-protected", and because we want to ensure > the option of loose coupling between authorization server and protected > resource server, I'm struggling to figure out (a) if calling this "API > request" is too limiting given that maybe every resource on the server (e.g. > every photo in a directory) is subject to a request for access, and (b) if > this is something the protected resource server itself should advertise (vs. > the authorization server), as appropriate. > > - "user authorization request": s/resource owners's/resource owner's/g (the > typo appears in a bunch of places) > > 2. Getting an Access Token > > - "MUST implement at least one...": Are its implementation choices something > the authorization server should advertise in documentation? > > - It would be helpful to give really concrete examples/use cases of all of > the profiles in the intro, so people can determine from this single place > which profiles interest them. > > 2.1. Web Server Flow > > - "without acquiring and end-user's credentials": Is this an obliquely stated > version of "avoiding the 'password anti-pattern'"? I think it could be > useful to mention this phrase here somewhere. Also, it's a little confusing > to mention the resource owner and an end-user without seeming to connect them. > > - oauth_callback_url: It says this is required, but what if the authorization > server already required the client to pre-register this? > > - "MUST first verify the identity of the resource owner": Should this be > followed with "...and seek their approval of the authorization request" or > similar? (This whole thing doesn't seem testable since it's outside the view > of the protocol, so I'm wondering if uppercase MUST is warranted.) > > - oauth_error_reason: Does "user_denied" mean "the user denied the request"? > Since the spec holds out the (slim) possibility of the resource owner not > being an end-user, should this be "resource_owner_denied" or "request_denied" > or something? > > - I'm thinking oauth_error_reason is where UMA could define an extension that > gives an error like "claims_required". I need to sort this out with my gang, > but provide it here as food for thought. Should we be defining our own > parameter instead (and if so, should this spec say something about cases > where this is done by others)? Alternatively, should this spec allow for > extended error codes in some formal fashion? > > - "The server must retain the scope...": I *think* this means the > authorization server, given that it's the one issuing the token, so this > should be explicitly stated. Keep in mind that UMA has reason to keep the > kinds of servers architecturally separate, which means we needed to build a > way for an UMA host (effectively an OAuth protected resource server) to be > able to correlate the client's desired scope (as retained by the > authorization server and baked into the issued token somehow, such that it > can be validated when presented by the client) and the actual type of access > attempted by the client. Actually, I think OAuth has this need too, so > perhaps UMA isn't all that different. > > 2.2. Web Client Flow > > - s/a mobile device/on a mobile device/ > > - "the client is downloaded to the resource owner's user-agent": I *think* I > can make sense of this, but the order just seems weird and backwards. :-) Is > the client, in fact, functioning as an HTTP user-agent itself? Or is the > client downloaded to the user's physical device (in which a separate > user-agent is colocated)? > > - "SHOULD verify that the callback URI provided ... is valid": Why not MUST? > It seems eminently doable. > > 2.3. Device Flow > > - "The client MAY both poll and have...": Cleaner to say "The client MUST > either poll or have an interface element, or both." > > 2.4. Username and Password Flow > > - "The client MUST discard the resource owner's username...": This is > obviously very desirable, but seems untestable. Is the uppercase MUST > warranted? > > - "The authorization server ... MAY verify that the client is authorized to > use this flow": Why and how would this MAY work? I'm not quite understanding > the goal here. > > 2.5. Client Identifier and Secret Flow > > - "This flow is suitable when the client is also the resource owner": I think > this was supposed to be the "two-legged"/"autonomous-client" solution, but > this phrase throws that into doubt for me. What was the intent here? Note > that UMA (like a lot of others) is interested in solving automated > self-registration of an autonomous client at an authorization server. (In > case it's of interest, we've been trying to sort out the legal implications > of parties who are *not* the resource owner seeking authorized access; this > is where our "claims_required" stuff comes in. Sometimes the client > represents "itself", or rather a company or org acting on its own behalf; > sometimes it represents a person different from the resource owner; etc. See > our Lexicon at http://kantarainitiative.org/confluence/display/uma/Lexicon.) > > - Probably this is an effect of needing more time for study, but why does > this profile not use oauth_error_code like the others do, relying only on a > 401? > > 3. Refreshing an Access Token > > - "The authorization server MUST verify that the resource owner...": This > seems untestable. Is the uppercase MUST warranted? > > - "the protected resource MUST NOT allow the user of the corresponding access > token without its secret": This is a case where "[protected resource] server" > would work way better than "protected resource", as resources don't allow or > disallow actions; they just exist. > > 4.1.2. Client Calls Protected Resource Using URL Query Parameter > > - "Prior to making a request": Just FYI, UMA makes use of a key stage prior > to a client making an access-token-bearing request; the client (UMA > requester) can hit the resource out of the blue, and in this way learns the > relevant access token request endpoint from the protected resource server > (UMA host). > > - "the following examples use the HTTP GET method": Should the wording here > and in the next section ("The client constructs an HTTP 'POST'...") be > rationalized to be more similar? > > Look forward to discussing more tomorrow, > > Eve > > On 19 Mar 2010, at 6:28 PM, David Recordon wrote: > >> As I mentioned a few weeks ago [1], I started working on editing the first >> draft of OAuth 2.0 over the past two weeks. While I realize that it's 6pm >> Friday (sorry about that), I hope to have a solid discussion about it at >> Monday's meeting. You can find the current draft of it – plus all of the >> document history – on my public GitHub account a >> thttp://github.com/daveman692/OAuth-2.0. Eran will be doing an initial >> editing pass before Monday and then spend more time with it next week. >> >> I've attached both a HTML and TXT copy to this email and plan to officially >> submit it as an Internet Draft. >> >> The following are highlighted changes from draft-hardt-oauth-01: >> 1. A Web Client flow designed for use within JavaScript. It also >> supports the use cases of the rich app profile so that they're >> not two separate flows. >> 2. A new device flows which is based on the Netflix/Tivo flow (TV >> shows you a code that you type in on your computer). >> http://www.ietf.org/mail-archive/web/oauth/current/msg01346.html >> 3. Remove captchas from the username/password flow. They haven't >> been successfully implemented within this context and create >> complexity especially when we use other signals to detect >> compromised accounts. >> http://www.ietf.org/mail-archive/web/oauth/current/msg01293.html >> 4. Don't allow bearer tokens without either SSL and/or signatures. >> While some providers may offer this ability, they should be out >> of spec for doing so though technically it won't break the flows. >> 5. Abstract the refresh token flow out of each profile into its own >> section. Support the ability to request access token secrets >> when refreshing. >> 6. Support signatures for making API requests but not for getting >> access tokens. If you want to use signatures, you'll get an >> access token and then make a refresh call where you ask for a >> token secret. This causes the auth server to mark the token as >> no longer being valid as a bearer token via SSL. This >> performance tradeoff seems realistic given many use cases focus >> on high-volume API transactions and thus the one additional >> request at the onset should be noise. The signature mechanism is >> currently from OAuth 1.0. >> >> Obviously I couldn't have made so much progress so quickly if it weren't for >> WRAP and I hope that 2.0 both addresses the WRAP use cases as well as those >> we all have been discussing here. I hope that I haven't missed anyone who >> contributed to prior work and am happy to add other authors if I have (and >> they wish to be added)! >> >> Thanks, >> --David >> >> [1] http://www.ietf.org/mail-archive/web/oauth/current/msg01225.html >> > > Eve Maler > e...@xmlgrrl.com > http://www.xmlgrrl.com/blog > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- -- John Panzer / Google jpan...@google.com / abstractioneer.org / @jpanzer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
