<br><br><div class="gmail_quote">On Tue, Nov 25, 2008 at 10:20 PM, Manger, James H <span dir="ltr"><<a href="mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The latest OpenID/OAuth hybrid draft REQUIRES the openid.oauth.consumer<br>
parameter, which means an app must be pre-registered with a service before<br>
it can use the protocol.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Requiring per-service pre-registration is not suitable for a web-scale<br>
authentication & delegation solution. </blockquote><div><br></div><div>Agreed. This is a weakness that we share with OAuth, though. We need a solution to this scale-prohibiting problem.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
[Web sites don't require Firefox, IE, Safari, Opera, curl, wget, lynx, search crawlers, feed readers... to be pre-registered]<br>
I don't mind if some service only support pre-registered apps, but pre-<br>
registration really needs to be optional in the *protocol* (even if extra<br>
security considerations apply to that case).<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
A couple of other issues (of lesser importance to supporting un-registered apps):<br>
<br>
<br>
Response:<br>
openid.oauth.consumer is REQUIRED in the OpenID authentication response.<br>
What is supposed to be done with this field?</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Is the app supposed to check that the value in the response matches the value in the request?<br>
Are there security implications of not doing the check?<br>
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).<br>
<br>
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.<br>
I suggest omitting scope from the response.</blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
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.<br>
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.<br>
<br>
<br>
Signing:<br>
The openid.oauth.* parameters in the OpenID response "MUST be signed" [§9].<br>
No reason is offered. It is not clear if this is necessary for security, an arbitrary choice, or adds some value.<br>
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].<br>
I think signing openid.oauth.request_token DOES add value.<br>
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:<br>
(1) openid.claimed_id identifies user1; but<br>
(2) openid.oauth.request_token gives access to user2's resources.<br>
I am not sure how or if this could be exploited.<br>
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.<br>
<br>
<br>
Scopes:<br>
The openid.oauth.scope parameter encodes "one or more scopes" in a way "possibly specific to the Consumer Provider" [section 7 "Requesting Authentication"].<br>
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.<br>
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).<br>
[Poor alternative: define the structure (|-separated relative URIs?, comma-separated alphanumeric strings?).]<br>
<br>
<br>
Access token secret:<br>
Section "3 Purpose" says<br>
"for security reasons, the OAuth access token is not returned in the URL"<br>
A hint as to the security reasons would be helpful.</blockquote><div><br></div><div>That's in the Security Considerations section, where we explain that we don't want long-lived secrets to hit the browser. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
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).<br>
[Changing "in the URL" to "in the OpenID authentication response" might also be clearer]<br></blockquote><div><br></div><div>Agreed. Done.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Request token secret:<br>
Using an empty string for the request token secret [§10 Obtaining the Access Token] is an obvious departure from secret designed for OAuth.<br>
A sentence explicitly describing why this is secure would be helpful.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>Dirk.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
I hope these suggestions are constructive and not just frustrating to the authors.<br>
<br>
<br>
James Manger<br>
<a href="mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.com</a><br>
Identity and security team — Chief Technology Office — Telstra<br>
<br>
<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@openid.net">specs@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
</blockquote></div><br>