We think that DotGNU should probably contain a "Virtual ID" system (see below for details on what we mean with that), even if there is currently no such project part of DotGNU. A project in this area which agrees with DotGNU's goals would be very welcome to become part of the DotGNU meta-project.
It has been suggested that DotGNU's native authentication and authorization subsystem could founded on a FOAF-based virtual identities system. In addition, DotGNU could use MACS, the Modular Access Control System for integrating DotGNU with other auth systems, as well as making DotGNU's authentication and authorization subsystem available to non-DotGNU-based applications.
Please use the DotGNU auth mailing list for discussing these and other "auth" ideas for DotGNU.
With a "Virtual ID" system we mean an integrated solution to the following problems:
Basically, a Virtual ID consists in some digital information, and the user must be able to prove ownership of this Virtual ID.
A user who has proved ownership of a Virtual ID may be authorized to access certain information, or perform certain actions. Webservice servers must be able to verify this.
Users should be able to customize their internet experience: There should be a way in which users can communicate their preferences to all webservice servers that want to take user preferences into consideration. This must be set up in a way that avoids violating the user's privacy.
There should be a simple way in which a website can request private information such as email address, postal address, telephone number, fax number, or credit card number from the user. Such private information must never be given to the website without explicit approval from the user, but the user should not be required to enter the information every time.
We must NOT create a passport "portal". That is technically and morally wrong. We must create a framework that can be scaled and deployed at any level desired, whether locally, at an enterprise, or at a portal. Authentication and access to private information should be peer to peer to preserve local storage of those things which should remain in private users hands. The ability to migrate data upward can be provided for, on a selective basis, and controls must be provided as to who may or may not access specific user information.
You are invited to add your comments concerning this at the appropriate page of the DotGNU Wiki
The "Profile Host" / "Profile Owner" / "Service Provider" terminology has been proposed by Albert Scherbinsky in a post on the DotGNU Auth mailing list.
Verbatim copying and distribution of this entire article are permitted in any medium or format, provided this notice is preserved.
This page is maintained by Norbert Bollow <nb@SoftwareEconomics.biz> with support from the DotGNU Developers mailing list.