Hello again<br><br>This kind of argumentation really helps us to weed problems before we implement them.<br><br>I think that if people have been on war over this issue for years then either both or other party has not been entirely logical. After all in engineering issues it should be possible to deduce how things are and arrive to a conclusion which both parties agree is right and proper. This does not apply to religional disputes like claiming earth is the center of universe. I would not take advice from religious people on engineering.<br>
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
> 2) Server has to store the CAPS URL information to memory or database<br>
> which is extra overhead.<br>
</div>Incorrect. Capability URLs can and are generated on the fly. Look, for<br>
example, at Caps.cs that handles about 1/2 of the Caps we pass to the<br>
client (the other half is spread in several modules that subscribe to<br>
OnRegisterCaps). They are also detracted on the fly. We already do this<br>
dynamic management for the CAPs we pass to the client. That is exactly<br>
the thing that I like the most. It's not just that the authorization is<br>
generated on the fly; the service handle itself is dynamic. So the<br>
service is only there during the appropriate context.</blockquote><div class="Ih2E3d"><br>Do  you mean that the caps url is processed when client invokes it to deduce what is encoded in the url to get capability out of it or do you mean that the CAPS URLs are temporary and have short life time like that of a client session? <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"> > It looks to me that oAuth might be used to authentication as well so<br>

it could replace OpenId entirely.<br>
<br>
</div>I don't think so. The spec for OAuth clearly says that it doesn't<br>
concern the authentication steps, which can be done in a number of ways.<br>
They do suggest, however, that OpenID+OAuth is a good combination.<br>
</blockquote><br>Their statement could be political as well. When I was reading their detailed specification there were user authentication phase as well where there were user token and secret passed which could be user name and passwords. Of course these can be also OpenId generated tokens but it looked a bit like the actual OpenId tokens proposal never got to the specification. The oAuth specification needs closer study or we need an oAuth expert to go deeper. (Or we need to spend some time reading the spec ourselves (Fear))<br>
<br>regards,<br>Tommi<br></div><br>