Good morning Here are some engineering concerns I see with CAPS URLs:
1) If client is given CAPS URL to access something we need to have access list / ownership and user role information in the database to deduce if the user has the right for capabilities he/she is requesting for. CAPS URLs do not remove need to for ownership, roles and ACLs. ACL is theoretically just a list of subjects who have ability to do given operations to an object. You can not even theoretically eliminate this information. You can deduce it from group memberhsip but groups are just another principal who can be added to ACL. 2) Server has to store the CAPS URL information to memory or database which is extra overhead. 3) CAPS URL does not work from server to client as HTTP requests can reliably traverse only from client to server due to NATs and firewalls. So they work only from client to server and server to server. 4) CAPS URLs are different from authentication tokens. CAPS URLs are authrorization related mechanism which are handed out by the service process like region itself. Region CAPS URLs not help to authenticate or authorize against other service processes like asset providers but you need to first authenticate and authorize against asset provider in which point the asset provider can hand you CAPS URLs. 5) If the life time of the CAPS URL is that of a client session it can be easily be abused by attackers who are sniffing the network traffic. As conclusion CAPS URLs we talk here seem to be a kind of caching mechanism where we do authentication and authorisation on client login and store the authorisation information to CAPS URLs which client can access directly and we do not need to authenticate&authorize anymore. As such CAPS URL is not a competitor to either OpenId nor oAuth. OpenId is authentication mechanism and oAuth is authorization mechanism for consuming services from remote interfaces. It looks to me that oAuth might be used to authentication as well so it could replace OpenId entirely. regards, Tommi
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
