Credentials, Not Business Cards

Phil Windley, in an article titled Lightweight Identity, recently wrote a good piece about LID that outlines one of my favorite strengths of SXIP… in a neat negative space kind of way:

“In the real world, I may be having a business meeting with you and you give me a business card. For purposes of getting in touch with you, I believe your assertions because the stakes aren’t that high. On the other hand, I may want to know, with some degree of assurance, what your name is. I’d ask for your driver’s license. In that case, you’re not asserting a value for your name, the government is. Or at least asserting that the person in the picture has a particular name, address, etc. That’s the missing piece. LID let’s me build business cards, not credentials.”

As Phil stated, it is not a problem to trust somebody about information with little risk involved, like contact information, but there is considerable risk in trusting somebody’s word on whether they have a degree or driver’s license and systems like LID don’t offer a solution for that problem; SXIP does.

At a very conceptual level, SXIP solves the problem of trusting somebody about a given fact by allowing them to offer proof that somebody else, somebody you trust like a school or the government, says the fact is the truth.

Already functional in the current SXIP specs, all open and available for download as PDFs at, are the concepts of assertions, tokens given to a user by an authoritative source that a site may choose to place trust in, and delegations, authority given to a site by another authoritative source. Both of these requirements for a system that can build credentials instead of business cards have already been implemented and are in use both on this site, my wiki and my development blog — which, incidentally, has a new HOWTO for those interested in configuring an internal Membersite for non-public, use — and for the internal tools used at Sxip (Bugzilla, etc.). Some more demos can be found at, for the interested. My apologies for that scary sentence above, but at least I didn’t drop semicolons everywhere.

To illustrate how this might work let’s use the example of a university library website, a student, and the university’s main registration site. Now the student has never been to the library website before, but his buddy asked him to reserve a study room before the big exam next week, so he is about to sxip in to make the reservation. Because he is a registered student at the university, he had been given an assertion from the main university registration site when he registered, stored on his Homesite as a digitally signed xml token, that says the person associated with that account, the GUPI actually, a big long unique number that can be, since I know you were worried about this, transfered to another Homesite should you want/need it to be, is a student at the university.

The university library is a very security conscious sort of place and doesn’t trust many people, in fact, it only trusts the main university registration website. Luckily for it, the main site has a tight grip on an SSL certificate, of which the library website has the public key. This allows the library to verify any data that is sent by the main site has truly been sent by the main site.

The student sxips in to the library, the library asks for proof that he is a student, and the Homesite provides the stored token for the student to provide to the library, the library verifies that the Homesite is a valid authority for the student’s GUPI, that the token provided by the main site is valid for the GUPI that belongs to the student, and that the token provided by the main site and its content is really from the main site. And, of course, it all checks out and our friendly student gets his study room.

A delegation is a similar concept, except that in this case it is being used by the Homesite to prove that the Homesite has authority over the student’s GUPI, and was issued by the network to the Homesite when the student registered his account on the Homesite. So, a delegation works as a hand-off of trust, an authoritative site trusts another site to speak for it regarding some property. It is important to keep in mind that at no point are you required to trust a given assertion or delegation; if you so choose, you could decide that your site will only accept things asserted by your own site.

For the extremely technical-minded (this stuff can get deep), or even those with casual interest, to pick my brain and those of the community around SXIP about any of the things I mentioned, get on the discussion mailing list. Besides, it is a bit of a personal goal of mine to be able to make anything work with SXIP, so challenges are very welcome.

Leave a Reply

Your email address will not be published. Required fields are marked *