> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Peter Saint-Andre
> Sent: Wednesday, June 01, 2011 11:43 AM
> Throughout the document, the various parameters (e.g., client_secret and
> client_id) are essentially undefined. There is no text about the length of
> these parameters, the allowable characters (e.g., alpha and digits only, all
> ASCII characters, full Unicode), internationalization considerations,
> preparation and comparison of strings, etc. I don't see how developers will
> build interoperable implementations without clear guidance here.
We have no consensus on string sizes.
I can add a note that all strings are UTF-8 encoded unless specified otherwise.
Access tokens, for example, are defined by each profile.
> Also, the scope parameter still strike me as extremly vague. Can we at least
> define the word "scope" and provide a few examples of how the parameter
> might be used?
Please suggest text.
> No rules are provided for URI matching (e.g., in Section 4.1 the redirection
> URI received needs to be checked against the URI used to redirect the client,
> but not guidance is provided). Perhaps a reference to RFC 3986 is in order
> here. Here also internationalization concerns might need to be covered (e.g.,
> are IRIs allowed?).
Added reference to 3986. As to IRIs, as long as they are encoded as URIs, but
last I checked, that was implicit by default.
> 4.1.2. Authorization Response
>
> OLD:
> If an
> authorization code is used more than once, the authorization
> server MAY revoke all tokens previously issued based on that
> authorization code.
>
> NEW:
> If an
> authorization code is used more than once, the authorization
> server SHOULD revoke all tokens previously issued based on that
> authorization code.
>
> RATIONALE: MAY seems weak here.
This was changed to MAY because most large scale implementations will not be
able to revoke access tokens at all (typically a self-encoded token good for
one hour). A SHOULD would be good but impractical advice. I changed it to
'SHOULD attempt' for now.
> OLD:
> The authorization server SHOULD issue access tokens with limited
> scope and duration to clients incapable of authenticating.
>
> NEW:
> If the authorization server issues access tokens to clients
> that are incapable of authenticating, the scope and duration of
> such tokens SHOULD be limited.
>
> RATIONALE: We're not actively RECOMMENDING authorization servers are to
> issue such tokens, are we?
I removed the sentence are a result of the wg discussion that followed.
> 10.3. Access Token Credentials
>
> The client SHOULD request access token credentials with the minimal
> scope and duration necessary.
>
> Is this enfoced by the authorization server?
Not sure how this would be possible. The server can later review what is being
used, but not predict.
> 10.9. Authorization Codes
>
> Authorization codes SHOULD be short lived and MUST be single use. If
> the authorization server observes multiple attempts to exchange an
> authorization code for an access token, the authorization server
> SHOULD revoke all access tokens already granted based on the
> compromised authorization code.
>
> Is there a good reason why the authorization server would not revoke all the
> access tokens? If not, change to MUST.
See above.
Changed it to 'SHOULD attempt' for now.
> MINOR ISSUES...
>
> 1.4.1. Authorization Code
>
> OLD:
> Before directing the resource owner back to the client with the
> authorization code, the authorization server authenticates the
> resource owner and obtains authorization. Because the resource owner
> only authenticates with the authorization server, the resource
> owner's credentials are never shared with the client.
>
> NEW:
> Before directing the resource owner back to the client with the
> authorization code, the authorization server authenticates the
> resource owner and obtains authorization. Because the resource owner
> only authenticates with the authorization server, the resource
> owner's credentials at the resource server are never shared with the
> client.
>
> RATIONALE: could the resource owner have credentials at the authorization
> server?
The credentials are always with the authorization server, and the resource
server either has access to the credentials, to the server for validation, or
relies on cookies and other non-standard credentials replacements.
> 4.1.2.1. Error Response
>
> OLD:
> error_description
> OPTIONAL. A human-readable text providing additional
> information, used to assist in the understanding and resolution
> of the error occurred. [[ add language and encoding information
> ]]
>
> NEW:
> error_description
> OPTIONAL. Descriptive text providing additional information,
> used to assist in the understanding and resolution of the
> error that has occurred. If included, it MUST be used only
> to provide descriptive or diagnostic information that
> supplements the meaning of an existing HTTP error code. It
> MUST NOT be interpreted programmatically by an application and
> MUST NOT be used as the error message presented to a human
> user, but MAY be used by application developers for debugging
> purposes.
>
> RATIONALE: If the error_description is not intended for humans and is to be
> used only by developers for debugging purposes, then we don't need
> language tags. (As explained in RFC 2277, "internationalization is for
> humans";
> yes, developers are people too...)
Is this much normative text necessary? We currently have:
OPTIONAL. A human-readable UTF-8 encoded text providing
additional information,
used to assist the client developer in understanding the
error that occurred.
> 4.2. Implicit Grant
>
> This section uses the term "web server"; I suggest "resource server" for
> consistency.
Actually, this is not the resource server. I changed the term to web-hosted
client resource to make it clear who is hosting this resource (the client).
> 8.1. Defining Access Token Types
> 8.2. Defining New Endpoint Parameters
>
> Mention that the ALPHA and DIGIT rules come from RFC 5234.
I don't think this is necessary for rules coming directly from 5234 (which is
referenced).
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
