OAuth WRAP draft spec comments

[Andrew Arnott]

I've been implementing the OAuthWRAP spec version 0.9.7.2 and took down some feedback on the spec itself, which I share below.  I apologize if some of it may be redundant with other emails on the list as I haven't been following the list in the last few weeks. 

In section 1.3, in the paragraph beginning "Web App Profile (5.4)", there's a grammatical error:

other mechanisms than a username and password

In section 5.4.6, the numbered list #1 item states:

1 the Client Secret MUST match the Client Identifer

The last word has a typo . Also, the client secret need not match the client identifier, literally.  It must match the secret the authorization server has on file for the client identifier.

Sections 5.3.1 and 5.5.1 suggests that "the authorization server MAY have required the Client to have obtained a client identifier from the authorization server", but then section 5.3.3 mandates a wrap_client_id parameter.  Are clients allowed to supply the parameter with a blank value when it doesn't have a client identifier?

Section 5.4.8 claims that refreshing access tokens is the same in 5.3, 5.4, and 5.5.  It is not.  For example, 5.3 does not require client_id and client_secret parameters and 5.4 does.  Also, section 5.4.8 describes the refresh_token as the one received in 5.3.4 when it should say 5.4.6.

The Web App and Rich App profiles do not discuss how the redirection occurs.  Is it a 301 Redirect, or a scripted form POST? 

It looks like the Rich App profile provides a way to obtain a refresh and access token using the client_id but without ever knowing or sharing the client secret.  It seems like there's a hole there, since a web app could use the rich app profile to obtain access under the pretense of some other app's name.  Perhaps section 5.5.4 should include a wrap_client_secret parameter?

The access token doesn't have a maximum allowable length, which leaves Clients in a difficult position of guessing what the maximum conceivable length might be when preparing database column sizes.  I believe when Google started issuing their psuedonymous claimed identifiers, that some RPs broke because they were longer than expected.  

And speaking of maximum length, access tokens with complex scopes that use URIs to describe them (as Google OAuth does) might quickly exceed any < 2 KB access token length limit if the token itself contains the entire signed authorization info.  Just a thought.  Probably too late to change this though.  And besides it must fit in the Authorization header.  I suspect the workaround is simply to choose shorter representations of access rights than fully-qualified URIs.  But perhaps another way to go about it is to splinter the access token into different tokens for use in exercising different access.  So accessing Google Mail requires one access token and accessing Google Calendar requires another.  But sending the user through the authorization step multiple times in a row would be a bad UX, so it almost seems like there should be a way to set the scope in a single auth request, but get multiple authz=accesstoken pairs that the Client can use as appropriate.  That definitely comes at the cost of some complexity, however.

Typo in first sentence of section 6.5.

It seems that some error responses are 401's, others are 400's, and some have error_reason parameters and others don't.  I wonder if this is by design or just an oversight?  It seems like having an error_reason more consistently would be less likely to be implemented incorrectly.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Dick Hardt]

Hi Andrew

draft-hardt-oauth-wrap-01/draft-hardt-oauth-wrap-01 is the latest version of the spec and clarifies a number of points. Would you reference it in the future?

On 2010-02-08, at 6:13 AM, Andrew Arnott wrote:

I've been implementing the OAuthWRAP spec version 0.9.7.2 and took down some feedback on the spec itself, which I share below.  I apologize if some of it may be redundant with other emails on the list as I haven't been following the list in the last few weeks. 

In section 1.3, in the paragraph beginning "Web App Profile (5.4)", there's a grammatical error:

other mechanisms than a username and password

In section 5.4.6, the numbered list #1 item states:

1 the Client Secret MUST match the Client Identifer

The last word has a typo . Also, the client secret need not match the client identifier, literally.  It must match the secret the authorization server has on file for the client identifier.

Sections 5.3.1 and 5.5.1 suggests that "the authorization server MAY have required the Client to have obtained a client identifier from the authorization server", but then section 5.3.3 mandates a wrap_client_id parameter.  Are clients allowed to supply the parameter with a blank value when it doesn't have a client identifier?

Section 5.4.8 claims that refreshing access tokens is the same in 5.3, 5.4, and 5.5.  It is not.  For example, 5.3 does not require client_id and client_secret parameters and 5.4 does.  Also, section 5.4.8 describes the refresh_token as the one received in 5.3.4 when it should say 5.4.6.

Are the above now addressed in draft-hardt-oauth-wrap-01/draft-hardt-oauth-wrap-01?

The Web App and Rich App profiles do not discuss how the redirection occurs.  Is it a 301 Redirect, or a scripted form POST? 

Either are allowed per the spec.

It looks like the Rich App profile provides a way to obtain a refresh and access token using the client_id but without ever knowing or sharing the client secret.  It seems like there's a hole there, since a web app could use the rich app profile to obtain access under the pretense of some other app's name.  Perhaps section 5.5.4 should include a wrap_client_secret parameter?

Client secrets are not secret on rich clients.

The access token doesn't have a maximum allowable length, which leaves Clients in a difficult position of guessing what the maximum conceivable length might be when preparing database column sizes.  I believe when Google started issuing their psuedonymous claimed identifiers, that some RPs broke because they were longer than expected.  

And speaking of maximum length, access tokens with complex scopes that use URIs to describe them (as Google OAuth does) might quickly exceed any < 2 KB access token length limit if the token itself contains the entire signed authorization info.  Just a thought.  Probably too late to change this though.  And besides it must fit in the Authorization header.  I suspect the workaround is simply to choose shorter representations of access rights than fully-qualified URIs.  But perhaps another way to go about it is to splinter the access token into different tokens for use in exercising different access.  So accessing Google Mail requires one access token and accessing Google Calendar requires another.  But sending the user through the authorization step multiple times in a row would be a bad UX, so it almost seems like there should be a way to set the scope in a single auth request, but get multiple authz=accesstoken pairs that the Client can use as appropriate.  That definitely comes at the cost of some complexity, however.

Access Token lengths are bounded by the maximum size of HTTP headers.

Typo in first sentence of section 6.5.

It seems that some error responses are 401's, others are 400's, and some have error_reason parameters and others don't.  I wonder if this is by design or just an oversight?  It seems like having an error_reason more consistently would be less likely to be implemented incorrectly.

By design. 401 allows means bad credentials and does not need a reason.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

--
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Andrew Arnott]

On Mon, Feb 8, 2010 at 9:07 AM, Dick Hardt <dick....@gmail.com> wrote:

Hi Andrew

draft-hardt-oauth-wrap-01/draft-hardt-oauth-wrap-01 is the latest version of the spec and clarifies a number of points. Would you reference it in the future?

Thanks, Dick.  I'm using the new draft to respond with some remaining comments inline.

 

On 2010-02-08, at 6:13 AM, Andrew Arnott wrote:

I've been implementing the OAuthWRAP spec version 0.9.7.2 and took down some feedback on the spec itself, which I share below.  I apologize if some of it may be redundant with other emails on the list as I haven't been following the list in the last few weeks. 

In section 1.3, in the paragraph beginning "Web App Profile (5.4)", there's a grammatical error:

other mechanisms than a username and password

In section 5.4.6, the numbered list #1 item states:

1 the Client Secret MUST match the Client Identifer

The last word has a typo . Also, the client secret need not match the client identifier, literally.  It must match the secret the authorization server has on file for the client identifier.

Sections 5.3.1 and 5.5.1 suggests that "the authorization server MAY have required the Client to have obtained a client identifier from the authorization server", but then section 5.3.3 mandates a wrap_client_id parameter.  Are clients allowed to supply the parameter with a blank value when it doesn't have a client identifier?

Section 5.4.8 claims that refreshing access tokens is the same in 5.3, 5.4, and 5.5.  It is not.  For example, 5.3 does not require client_id and client_secret parameters and 5.4 does.  Also, section 5.4.8 describes the refresh_token as the one received in 5.3.4 when it should say 5.4.6.

Are the above now addressed in draft-hardt-oauth-wrap-01/draft-hardt-oauth-wrap-01?

Not all of them.  Section 6.1.1 still says 

Prior to initiating this protocol profile, the Authorization Server MAY have required the Client to have obtained a Client Identifier from the Authorization Server.

Followed by section 6.1.3 which mandates that a wrap_client_id parameter be present.  How can that parameter be present (and non-empty, presumably) if the client MAY NOT have obtained a client_id from the authorization server?  I'm hoping the spec can clarify that.  If it means that wrap_client_id must be present but may be blank, can we call that out, perhaps?

Section 6.2.6 still has the "Identifer" typo in it.

 

The Web App and Rich App profiles do not discuss how the redirection occurs.  Is it a 301 Redirect, or a scripted form POST? 

Either are allowed per the spec.

I actually don't see "301" redirect mentioned at all in the spec, nor form POST near any text describing redirects.  But it sounds like you agree it should be there.  Can you double check that it is? Leaving it unmentioned leaves an ambiguity unresolved regarding what remote parties are obliged to expect and handle.

 

It looks like the Rich App profile provides a way to obtain a refresh and access token using the client_id but without ever knowing or sharing the client secret.  It seems like there's a hole there, since a web app could use the rich app profile to obtain access under the pretense of some other app's name.  Perhaps section 5.5.4 should include a wrap_client_secret parameter?

Client secrets are not secret on rich clients.

I agree.  Perhaps this is a good topic to put into the Security Considerations section: that authorization servers should clearly designate to users that they are authorize what the auth server expects is a rich client app rather than a web server.  Otherwise it seems trivially easy to write a web site that gets authorization on the false premise of being a rich client app the user recognizes and trusts.

The access token doesn't have a maximum allowable length, which leaves Clients in a difficult position of guessing what the maximum conceivable length might be when preparing database column sizes.  I believe when Google started issuing their psuedonymous claimed identifiers, that some RPs broke because they were longer than expected.  

And speaking of maximum length, access tokens with complex scopes that use URIs to describe them (as Google OAuth does) might quickly exceed any < 2 KB access token length limit if the token itself contains the entire signed authorization info.  Just a thought.  Probably too late to change this though.  And besides it must fit in the Authorization header.  I suspect the workaround is simply to choose shorter representations of access rights than fully-qualified URIs.  But perhaps another way to go about it is to splinter the access token into different tokens for use in exercising different access.  So accessing Google Mail requires one access token and accessing Google Calendar requires another.  But sending the user through the authorization step multiple times in a row would be a bad UX, so it almost seems like there should be a way to set the scope in a single auth request, but get multiple authz=accesstoken pairs that the Client can use as appropriate.  That definitely comes at the cost of some complexity, however.

Access Token lengths are bounded by the maximum size of HTTP headers.

That's pretty loose bounds, since HTTP headers are unpredictably large with cookies and other headers.  There's significant incentive to keep them small to avoid unreliable execution.