OAuth Discovery 1.0 Draft 2 addresses this issue through the Static
Consumer Identity allocation
(http://oauth.net/discovery/#static_alloc).
For example:
<Service>
<Type>http://oauth.net/discovery/1.0/consumer-identity/static</Type>
<LocalID>0685bd9184jfhq22</LocalID>
</Service>
I would assume compatibility with OAuth Discovery is something that
will be desirable within the hybrid specification as well.
-
darren bounds
cliqset.com
On Wed, Nov 26, 2008 at 1:20 AM, Manger, James H
<[EMAIL PROTECTED]> 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).
>
>
> 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
> [EMAIL PROTECTED]
> Identity and security team — Chief Technology Office — Telstra
>
>
> _______________________________________________
> specs mailing list
> [email protected]
> http://openid.net/mailman/listinfo/specs
>
--
darren bounds
[EMAIL PROTECTED]
_______________________________________________
specs mailing list
[email protected]
http://openid.net/mailman/listinfo/specs
