SINP is a protocol based on HTTP(S) and XML that provides you with an identity on the web. You register a so called SINP Identity on a SINP Server of your choice. To address a certain identity, we use an email like notation:
firstname.lastname@example.org is the SINP Identity of the user
bas on the SINP Server
The first big feature of SINP is authentication. If someone claims to be
email@example.com, I can check that by asking
w-nz.com to check it. I’ll redirect that guy to
w-nz.com to let him be checked by his proclaimed SINP Server. If he really is
firstname.lastname@example.org, he’ll have a nice session cookie for
w-nz.com will check that. After that
w-nz.com will redirect him back and I’ll ask
w-nz.com whether he succeeded.
One major application of this authentication is that someone who posts a blog comment as
email@example.com, really is/are the same guy(s) that posted before as
firstname.lastname@example.org, for they are allowed by
The second big feature of SINP is that each identity comes bundled with a XML document, which can store information about the owner like his name, email address, date of birth, etc. The SINP Server stores this document. The identity owner, the guy who owns the identity, can pick an access policy for each little bit of information in this document. You might want to share your real address only to those who you’ve explicitly allowed. Everyone can see the parts of your document you’ve allowed everyone access to. This is the one for email@example.com.
To get specific parts instead of the whole thing, or get to stuff you’ve limited access to, one needs to use SINP Negotiation. To get some specific information from
firstname.lastname@example.org, I ask
w-nz.com for this specific information, in the form of a few xpaths. Along with the xpaths I can send my own SINP address,
email@example.com. The server will respond on each request according to the access policy which the SINP Server has set. There are several possibilities:
- Ok, the requested information will be included in the response.
- Nope, you’re denied access to that.
- Not found, that stuff isn’t in this document.
- You’ll have to ask Noud. Basically you’ll have to redirect Noud to the server, where he will be authenticated and after that he can decide whether to allow you access to it, and you can try again lateron.
- If you’re
firstname.lastname@example.org, you can see it. You’ll have to authenticate, though. This is done via sinp authentication as described before.
Another big feature of SINP is versioning, which allows caching. The version of a specific bit of information is send back on each response in negotiation. In a negotation request, I can specify the current version I already have. In case that specific part of the document hasn’t updated, the SINP server will let me know, instead of sending the whole thing.
One advantage of caching and negotation is that information can be kept synchronized with your document when it updates. A blog, on which you’ve posted a comment, might periodically check whether the information it retreived from your SINP document has changed. This can be done cheaply with negotiation and versioning.
SINP is easy to implement, it is quite simple. It also is portable, it uses widely supported technologies like XML and HTTP(S) as its base.
SINP is under development, but you can already (and really should) take a look to:
SINP is based on things I’ve seen floating around on the web, for instance Zef`s SPTP.
At the moment of writing we’re developing a PHP client, a Python client and continueing development of the PHP server. You’re welcome to participate!
We hope you like it, comments or any other forms of participation would be very welcome.
Bas, Bram and Noud.