On Tue, Nov 25, 2008 at 10:20 PM, 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).
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 > [EMAIL PROTECTED] > Identity and security team — Chief Technology Office — Telstra > > > _______________________________________________ > specs mailing list > [email protected] > http://openid.net/mailman/listinfo/specs > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
