OpenID/OAuth hybrid - without app pre-registration

[Manger, James H]

The latest OpenID/OAuth hybrid draft REQUIRES the openid.oauth.consumer
parameter, which means an app must be pre-registered with a service before
it can use the protocol.
Requiring per-service pre-registration is not suitable for a web-scale
authentication & delegation solution. [Web sites don't require Firefox, IE, Safari, Opera, curl, wget, lynx, search crawlers, feed readers... to be pre-registered]
I don’t mind if some service only support pre-registered apps, but pre-
registration really needs to be optional in the *protocol* (even if extra
security considerations apply to that case).


A couple of other issues (of lesser importance to supporting un-registered apps):


Response:
openid.oauth.consumer is REQUIRED in the OpenID authentication response.
What is supposed to be done with this field?
Is the app supposed to check that the value in the response matches the value in the request?
Are there security implications of not doing the check?
I suspect it can be omitted (openid.return_to is still present and signed if the app want to confirm the response is meant for itself).

Similarly with openid.oauth.scope in the response. The draft hints that the value in the response is likely to be different from the value in the request. It seems like there is nothing an app can do with the scope from the response without SP-specific knowledge.
I suggest omitting scope from the response.
The OP/SP can define its own structure for openid.oauth.request_token if it wants to provide more details to an app with SP-specific knowledge.
An arbitrary amount of metadata about the delegation (scopes, lifetimes...) would be better communicated separately -- perhaps as extra parameters returned when getting an access token.


Signing:
The openid.oauth.* parameters in the OpenID response "MUST be signed" [§9].
No reason is offered. It is not clear if this is necessary for security, an arbitrary choice, or adds some value.
This seems to contradict the aim of NOT introducing reliance on the security properties of one protocol (OpenID) for the correctness of the other (OAuth) [§11 Security Considerations].
I think signing openid.oauth.request_token DOES add value.
It proves that the authentication and delegation come from the same user. It prevents a strange case of two colluding users constructing a response where:
(1) openid.claimed_id identifies user1; but
(2) openid.oauth.request_token gives access to user2's resources.
I am not sure how or if this could be exploited.
I suggest adding a sentence that openid.oauth.request_token MUST be signed to bind the delegated rights to the user identified by openid.claimed_id.


Scopes:
The openid.oauth.scope parameter encodes "one or more scopes" in a way "possibly specific to the Consumer Provider" [section 7 "Requesting Authentication"].
This complicates any future OAuth discovery. Not only will a protected resource need to indicate a scope value, it will also need to indicate how to combine that with other scope values (separators, escaping...). Yuck.
I suggest avoiding any mention of structure in the scope field (just call it a blob obtained from the SP to represent the context of the delegation, with an expectation that a future OAuth discovery step will supply the blob -- even better if one blob covers scope & consumer key).
[Poor alternative: define the structure (|-separated relative URIs?, comma-separated alphanumeric strings?).]


Access token secret:
Section "3 Purpose" says
  "for security reasons, the OAuth access token is not returned in the URL"
A hint as to the security reasons would be helpful.
The access token is useless without the access token secret that cannot be obtained without the corresponding consumer secret (since the spec requires pre-registration).
[Changing "in the URL" to "in the OpenID authentication response" might also be clearer]


Request token secret:
Using an empty string for the request token secret [§10 Obtaining the Access Token] is an obvious departure from secret designed for OAuth.
A sentence explicitly describing why this is secure would be helpful.


I hope these suggestions are constructive and not just frustrating to the authors.


James Manger
James.H.Manger at team.telstra.com
Identity and security team — Chief Technology Office — Telstra