OpenID/OAuth hybrid - without app pre-registration

Breno de Medeiros breno at
Wed Nov 26 06:48:23 UTC 2008

On Tue, Nov 25, 2008 at 10:20 PM, Manger, James H
<James.H.Manger at> wrote:
> 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).

The consumer key is an independent issue of pre-registration. Say a
site hosts multiple apps. The realm indicates the site, the consumer
key indicates the app. The presence of the consumer key (even in a
scenario without pre-registration requirements) is useful to indicate
to the user information about the request.

This turns out to be particularly important in the un-registered case,
where the consumer could provide a descriptive key. In the case of
registered consumers, this will probably not be used to describe the
request in a user-visible way, but is useful for other purposes.

Making it optional actually hurts interoperability. The idea is that
it can be a self-reported value in the case of unregistered consumers.

> 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
> Identity and security team — Chief Technology Office — Telstra
> _______________________________________________
> specs mailing list
> specs at


+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

More information about the specs mailing list