OpenID/OAuth hybrid - without app pre-registration

Fri Nov 28 19:33:45 UTC 2008

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

Well, technically speaking, it requires the parameter, not that the consumer
be pre-registered. Perhaps in the future there will be a way to
automatically obtain consumer keys. I agree that today and in practice, this
means that consumers have to be pre-registered.

> Requiring per-service pre-registration is not suitable for a web-scale
> authentication & delegation solution.

Agreed. This is a weakness that we share with OAuth, though. We need a
solution to this scale-prohibiting problem.

[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).
>

See above. I don't think the protocol requires pre-registration. It's just
that today the only way to get one of the parameters required by the
protocol, you have to pre-register.

>
>
> 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?

This follows the OpenID tradition to parrot back to the Consumer the
parameters it sent to the Provider. I'm sure more paranoid crypto geeks than
me can come up with a reason why that's important for security, but here is
a non-security reason: Imagine the Consumer controlling more than one
consumer key, and also imagine that the consumer is implemented as a server
farms of thousands of machines. The machine receiving the response is not
necessarily the same machine as the machine that made the request, and it
response-receiver needs to know the context of the request.

>
> 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.

See above. If the parameter is in the request, I think it should also be in
the response. There are those that argue that scope doesn't need to be
talked about at all in a protocol like this, and can be encoded in other
places (like the consumer requesting different scopes by contacting
different endpoints on the provider, etc.). But it seems that those that
want to see a scope parameter have won this time.

>
> 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.

That's in the Security Considerations section, where we explain that we
don't want long-lived secrets to hit the browser.

>
> 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]
>

Agreed. Done.

> 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'm not sure a spec should get into too much detail explaining its
rationales. It should just explain what the protocol looks like (although we
do have the security considerations section). My understanding is that
request tokens are there in OAuth to support desktop apps. Desktop apps
don't make sense for the hybrid protocol (there is no such thing as OpenID
for a desktop app - desktop apps would just use OAuth). Hence, no need for a
request token in the sense of OAuth. We're just re-using the term (and bits)
for a token that identifies the request context.

Dirk.

>
>
> 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
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081128/7e590f65/attachment-0001.htm>