Foaf+ssl/UseCases
FOAF+SSL Use Cases
Here is a place to put down use cases for FOAF+SSL. These are ideas to try out.
Replacing e-mail with foaf+ssl and Atom
E-mail spam is killing e-mail. Service providers have to deal with more and more e-mail on their networks. E-mail is also insecure. PGP encrypted e-mail will never take off. The solution is to think of blogging as an improved e-mail that for the moment is 1-world. With foaf+ssl it would be possible to make blogging one to one, just as email is, whilst adding security in by default as an extra benefit. See the thread replacing email with atom and foaf+ssl on the atom-protocols mailing list.
Web site personalization
A Web site has a foaf+ssl login button. The site authenticates the user when he clicks it, finds his personal profile and can greet the user by name, know some of his interests, and his claimed public friend network. This can be used to make the user feel more at home. For example when Henry Story first logged into foaf.me by clicking the login button on the top right it returned a personalized page put together from his detailed public foaf profile. (Of course one need not make so much available publically)
Comment authentication
Currently when leaving comments on blogs, people can often type in the email of anyone. No verification is done. Here with foaf+ssl an authentication can be as easy as clicking a link for the user, so there is no need even to type an email address.
The server can then gather information about the user from the foaf file, and present this information (logo, name,...) next to the post, for when other people read it.
If the person publishing the comment specifies his blog in his foaf, the blog server can use this information to check if the blog really does point back to the foaf. This can help automate the verification process. So the initial blog post writer, will have information about the alleged poster, with some information about which attributes could be verified.
Also WebIds that were accepted once by a blog server can then be accepted automatically the next time. Or even lighter policies, such as allowing friends of owners of WebIds to post could be put in place.
Account provisioning
A Web site has a foaf+ssl login button. The web site creates a user account for that person tied to his URL, using his claimed name, and other information. He can always login with that same button.
Advantages:
- on click account provisioning
- the user has only one file to keep up to date when he changes address, or habits or interests
- beta sites can easily grow by social connections. People who know people already using the service get prioritized access
Distributed Access Control
All these enable the data about people and their relations to be spread across the web, in the control of the groups with the most interest in maintaining the information. The Access Control can then use this information to give access to a number of resources by crawling the web.
Group access control
A web site allows people to give access to certain resource to members of a group. The group is specified via a URL naming a foaf:Group The URL can be anywhere on the web. This enables the separation of the job of the resource owner, and the job of the person determining the group membership.
For example a group can be generated automatically by a mailing list. All members of that mailing list would be given access to that set of resources just by logging in with foaf+ssl (that is clicking that button)
Rule Based Access Control
Same as 1, but the group is defined by a rule, such as friends of people who are using the service. As those people add friends to their foaf files, those people get access. This requires crawling the web for
( FOAF and OpenID: two great tastes that taste great together but without using OpenId, though it can be tied in with OpenId too )
Description based Access Control
This is similar to what is known in other circles as Attribute Based Access Control. Using description logics one can define a group quite easily.
One could therefore use description logic, to describe a class of agents allowed access to a resource. This could be done like this:
@prefix : <#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
:JulietFriends a owl:Class;
owl:equivalentClass [ a owl:Restriction;
owl:onProperty [ owl:inverseProperty foaf:knows ];
owl:hasValue :juliet ] .
foaf:foaf a owl:Class;
owl:propertyChainAxiom ( foaf:knows foaf:knows );
:JulietFOAF a owl:Class;
owl:equivalentClass [ a owl:Restriction;
owl:onProperty [ owl:inverseProperty foaf:foaf ];
owl:hasValue :juliet ] .
:TrackablePeople a owl:Class;
owl:unionOf ( :JulietFriends :JulietFOAF ) .
The group TrackablePeople is the group of Juliet's friends and the friends of her friends. The server using this will need to be able to get Juliet's FOAF file, and crawl it to one level depth. Once such a group is defined, it is easy to define other groups of resources that that group can access.
Files need of course not be crawled. Some intermediary could set itself up with the task of doing just that. It may not have as much access though, given that is will be an intermediary, and that it may not be trusted by all.
SPARQL Endpoint Protection
When a user or company publishes an sparql endpoint, they can use foaf+ssl deliver smart ACL and session policies / rules.
Secure Enterprise Linked Data
When combined with the Relationship ontology (which just adds sub-properties to foaf:knows), an enterprise can protect against inadvertent de-referencing of sensitive data such as salaries across departments.
In similar vein, it can provide policy based access to shared calendars, blogs, wikis, and other distributed collaborative applications across organization structures (subsidiary companies, divisions, departments, projects etc.).
OAuth Like Access Control
It should be possible to give access to a Relying Party, such as a photo printing service, to which one has never been to parts of one's photo collection. This has been initially described in Sketch of a RESTful photo printing service.
Social Network like services
Distributed Activity Stream via RSS
A user on a website can create a stream of activities. This information can distributed out to the wider web using RSS. FOAF+SSL can be used to restrict access to a given group of people, on other web sites (say members of their friends list only).
Instant Messenger Login and Roster
FOAF+SSL can be used to authenticate a user on an instant messager system such as Jabber/XMPP. A roster can be generated from their public friends list, and they are immediately able to see who from their friends is online.
Publishing FOAF profiles for members of a company
A company could publish public profiles for its employees - they can decide what to make public. This would allow people externally to have a reference for the user's identity, so if they change office or move people who are in contact with them can be up to date and link to them. Pieces of the profile can be public others can be protected and visible only to that agent's friends, colleagues, etc..
Distributed Social Networks: Controlling our Data
Currently tools such as LinkedIn only allow one to find profile information for friends on one site. Their information is protected by a username/password pair. Because FOAF+SSL enables global authentication one should be able to go to a profile of someone on a remote site, and if one can authenticate in one click, immediately get to see more information as a member of a specific group.
- As an anonymous public person one can access:
- public key (for authentication)
- a form to send a message to
- a picture or logo perhaps
- Anything that can be public - blogs, wiki results, top art photos, etc..
- As a non anonymous user
- geolocation information
- TimeZone information (before calling this can help)
- town information: this can help if one is travelling to make happy encounters
- geolocation information
- richer profile, with photo, CV, etc....
- As a friend one could have access to:
- party wikis: organise a party
- party photos
- party videos
- list of friends identified by WebID, or indirectly as a description
- As a family one could have access to:
- family pictures
- family event calendar
- birthdates
- public phone number and address
- list of parents, children and siblings
- As a colleague one could have access to:
- business phone number
- sales leads (as WebIds)
- colleagues
- working timetable
- emergency contact numbers