Peer Authentication

The p2p capabilities in Vista and WCF are going to have a HUGE impact. The chance of leveraging physical proximity for setting up spontaneous meshes is truly mind boggling: imagine what you could do by walking in a crowded waiting room, on a train, in a hotel lobby, at Starbucks… even when you’re in your car, in line on the 520 bridge over Lake Washington (or in tangenziale a Milano…)[:)] Now: what new breed of applications will take advantage of the new model? There will be the obvious chat & content sharing, of course: the avid attention that a rough & primitive system like Toothing enjoyed is symptomatic of the potential of proximity applications. And if you ever tried to use an old projector with the new high res laptops you understand the value of being able to broadcast your presentation directly on everybody’s PC. But I believe that there will be more than that: proximity peer to peer enables an entirely new kind of application, sharing your capabilities with your neighborhood. The possibilities are endless: you could basically wrap in a Service interface your ability of translating from Korean to English, your skills in retouching red eyes in pictures, your knowledge of that part of the city… it would be enough to advertise those capabilities (and the contract associated) in the local mesh and pronto! Upon joining the mesh, I imagine that in a plausible client you would see a list of services currently available on the cloud you just joined and a queue of requests for the service you are offering. A peer 2 peer client would be a frictionless connector between demand and local offer.
There’s more. Instead of exposing your capabilities, you may want to expose the ones of your machine:  think of software packages that, besides being used interactively, they offer the possibility to be accessed via services. Elements of the mesh may concede the use of their packages, of course if the sw license allows that, and maybe amortize their cost by charging a little fee. A truly new model!
That would applies to places, too: a shop may own a node, and expose through it services such as catalogs, special offer notifications, handbooks, advices, etc etc.. An archeological site may broadcast a guide in form of p2p service, and so on…
Many of those services will need some form of payment, a very interesting problem by itself: but in this context I’d rather concentrate on the problem of the peer authentication.
In a pure P2P network, there’s no central authentication authority: furthermore, asking for a premeditated step (obtaining credentials for accessing a certain service) somewhat defies the spirit of P2P, where meshes form and dissolve in complete freedom in accordance to the constraints asserted by every single node. On the other hand, a fully authenticationless model sounds impractical: even before considering the protection of the value of transactions, think of the noise that the sheer soliciting would cause if everybody would be allowed to advertise on every node. That would be real time spam! Then? How can we introduce at least some authentication level, while preserving the full capability of forming completely dynamic meshes/associations?
I believe that also in this case Infocard will come in useful. It will have to reach critical adoption level for being used effectively in this fashion, as it should be reasonable to expect anyone to own an handful, but I believe it won’t take long to get to that point. Let’s try to explain what I mean.
You may for example decide that your application is a low risk one, like a chat, and the only guarantee you want to have is the chance of tracing back one user should he commit a violation; so you may ask that a peer exhibits a card from a known IP (of the caliber of Amazon or eBay, just to give an idea) before admitting it into the cloud. The card issuance did not have anything to do with the current p2p application: you’re not really looking at claims, but just at the fact that an IP of known rating is willing to vouch for the user with an identity (and you can refer authorities to that IP should the guy do something inappropriate). Members of clubs or similar could happily use their membership card like with any other “traditional” service, like an airline website, with the difference that here the relying party would be the cloud itself (or the node owned by the Lounge itself, see below for Services associated to places); and the application may of course be pertinent to the club theme itself (example: members of “the Ornitology club” may gain access to the personal collection of tagged pics of birds shot by every cloud member. Still a p2p app, different clouds will have different content!).
You may be more restrictive when it comes to direct revenue generators: so an alleged translator may need a special card, that implies that he paid whatever taxes he’s supposed to pay for offering a paid service. It’s not hard to imagine that somebody would try to skip that, offering a lower-price-but-higher-risk alternative service, and so on with similar market science fiction. Actually, I think that if such an application model would enjoy some degree of success we’d see the thriving of a special class of IP, the Rankers, dedicated to vouch for the trust level that a subject should be entitled (similar to the eBay ranking system).
While I believe that the idea of reusing cards in peer authentication is the right one, even if at times it stretches a bit the idea of justifiable parties, there are few problems that I haven’t yet well considered. The first and most evident one is connectivity: if I have to use a card, I need to contact the corresponding authority for populating the relative token. I can imagine many situations in which the real value of P2P is given by the fact that the network is purely local, a’ la Bluetooth. There is some case that, at least conceptually, would solve things: for theme based clouds, you may identify an authority with a Maver or in general with anybody that in that specific social topology has a special function-role. The clouds would then condense around those special individuals, who would choose to issue or not issue a token to bearers of a generic card which refers to their role (probably on the base of some multifactor). In practical terms, I don’t know if the current infocard supports issuer URIs on exotic protocol schemes (myp2p://ShoppingApplication/MaverIssuer.SVC) as it would be necessary for embedding a reference generic enough to reuse the same card on different clouds with different Mavers (assuming that there will be one and only one Maver, always at the same URI, per cloud). Of course the Maver is just an example, any individual/node with special property may play the role.
Another point is how to deal with the nitty gritty details of the cryptography. Usually Infocard will expect a special certificate on the server for authenticating it, while here everybody is a client. You can create a dummy one for the purpose, but imposing to every client to be identified by its own certificate would again kill the agility conferred by using a card as an authentication mean. Furthermore: once the interaction goes from the many-to-one catalog/discovery phase (list of the available services/instances/nodes currently reachable), the natural evolution is to a one-to-one phase where a client picks a service and starts interacting. At that point you presumably want to protect the transaction, and you have all the means thanks to WS-Trust & WS-Security… but which session key should you use? The one from the “client” card or the one from the “service” card?
You may think of the last 2 paragraphs as “syntactic sugar”, since the cryptographic material is all there and it’s just a matter of deciding what is the most appropriate way of using it. All of the above is still very rough and not very well pondered yet, but it was useful for me to put the words in line. What I think is interesting is the impact that such a model would have in term of social behavior, new application architectures and unprecedented revenue & licensing models. What’s your take? [:)]