Thank for the review and comment, Peter, some replies and new questions are inline below.
On Wed, Mar 23, 2011 at 11:05 AM, Peter Saint-Andre <[email protected]> wrote: > I've completed a review of this spec, the bearer token spec, and the > base spec. This is the first WGLC message I found in my inbox, so I'm > posting about this spec first. :) > > Overall I think this short spec is in fine shape. I have a few small > comments. > > 1. The grant type is a URI at oauth.net. Is that a stable URI? Does it > need to be? I honestly don't know the answer to either question. I certainly don't own the domain. I needed *some* URI to identify the grant type and, for lack of knowing any better, just used http://oauth.net as it seemed semi-appropriate and threw on a path that sort of described what it was. I think I might even asked you about it early on in this process and gotten a "it's fine for now" type of response :) Perhaps that now is over and it needs to be something else? > We could define a new URN parameters registry for grant types that are > defined in standards-track RFCs: > > http://www.iana.org/assignments/params/params.xml > > However, that might be perceived as overkill. That does seem a bit overkill but I don't know. Is there some middle ground? > 2. Both the SAML-bearer and v2-bearer specs borrow text from the base > spec when a reference seems better. For example, in Section 2.1 of the > SAML-bearer spec we find this: > > scope > OPTIONAL. The scope of the access request is expressed as a > list of space-delimited strings. The value is defined by the > authorization server. If the value contains multiple space- > delimited strings, their order does not matter, and each string > adds an additional access range to the requested scope. > > However, that's already defined in Section 4.1.1 of the base spec: > > scope > OPTIONAL. The scope of the access request expressed as a list > of space-delimited strings. The value is defined by the > authorization server. If the value contains multiple space- > delimited strings, their order does not matter, and each string > adds an additional access range to the requested scope. > > I think it would be better to reference the definitions in the base spec > so that they don't get out of sync. Up though -12 of the base spec, this spec did use that definition of the scope parameter from the base spec. In those earlier versions, all the base parameters for the token endpoint were defined in one place and it was very natural to 'inherit' scope from it. The way the base spec was reorganized in -13 made that inheritance awkward because each individual type of request redefines all the parameters. In fact, in the base spec, that exact text is repeated in three or four places and slight variations of it show up in several other paces. Generally, I think the re-org made it more readable but it also resulted in more such duplication. Anyway, I digress. Is it reasonable/possible to reference the definition in the base spec when the definition is the same but the context of use is a little off? Can you suggest some text? Or point me to an I-D/RFC that has done something similar? > 3. Regarding "invalid_grant" in Section 2.3, I'll post in the thread > about a possible registry of error parameter values. I'm trying to stay out of the debate regarding additional registries:) But I will say that, from the perspective of this specification, I think that the top level "invalid_grant" error code with optionally more descriptive content in the error_description parameter is probably sufficient. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
