During the course of the conversations SXIP and digital identity came up, leading to some very exciting subjects for me. Most people who are in positions that have some say over things are rightfully wary of accepting new ideas, especially those that have a large amount of hype involved, but I felt the conversations did a good job of assuaging the challenges they presented.

Two of the final challenges brought up that still appeared to leave some doubts in the minds of those presenting them did not have a chance to be fully discussed before the end of the dinner, so I will address them here.

A Unified System of Exchange

The Argument:

A unified system for exchanging personal data presents a large target for malicious applications and spyware, creating the opportunity for more powerful data collection programs based on the unified protocol. In the current system of many non-interoperable formats a hacker can only target a specific section or format of data at once, requiring more effort to steal such data.

The argument assumes that a malicious application or spyware has full access to any data passed through the user’s computer and is likely to be attempting to collect values from specific fields and forms in the user’s web browser.

The Response:

SXIP is more than single sign-on and a unified system for exchanging data, it improves upon the ‘quality’ of the data that can be sent by supporting much more granular data. Finely grained data allows users to assert specific qualities about themselves, their age, for example, without disclosing their name, government identification number, or even birthdate. While the assertion of the user’s age could be intercepted by somebody who had complete access to your browser, it couldn’t be used at another sxip-enabled site without going through the user’s Homesite. (To read about why this works, I just wrote an entry about it: ‘Credentials, Not Business Cards‘)

Furthermore, because the data can be as finely grained as required, a website such as a car rental company’s could be asking only for proof that the user’s age is above 25, that the user has a valid driver’s license and that the user has a clean driving record before making a reservation. Even were an attacker to gain access to that data, how much use would it be to them? With SXIP the user actually has the option of providing proof of something without providing the actual item, meaning even in the event of interception there is no data usable for impersonation.

But paranoia still shows its ugly head. Even if an attacker can’t use the information without going through the user’s Homesite, and even if the data they get is of minimal outside use, what if they intercept the username and password as they go to the Homesite?

The main risk becomes that of the user’s authentication credentials for his or her Homesite being stolen, as important information provided by the Homesite will only be accepted if provided by the Homesite. The solution SXIP provides is that of decoupling the authentication method used, in other words, a Homesite can increase the strength of their authentication in any way they choose. Some possible methods include public key authentication, like SSH, or multi-level authentication, think of how a credit card company will call if somebody is attempting to make a very large purchase. A Homesite can be set up along the same lines, with graduated levels of authentication for more secure data.

The other point to be made here is that those most concerned with security of their data will sign up for the most secure Homesites that require the most to release their data. The Homesite has to gain the user’s trust, the best Homesites will certainly provide stronger authentication methods for those who want them.

An Open Protocol

The Argument:

At a large company the authentication infrastructure will sometimes rely upon a certain amount of security through obscurity, secret components to the authentication infrastructure that the company’s security people would not feel comfortable having publicly known. Because SXIP is a completely open protocol the large company would not adopt it because it would mean giving up the secrets they feels makes them safe.

The Response:

One of the reasons I was unable to properly address this at dinner was because it took me a bit by surprise; I have always looked upon security through obscurity as being eventually doomed. Accepting that it is a valid concept — especially because the man making the argument certainly knows more about the workings of large corporations than I — and that many large corporations rely on it, a company can still include obscurity in their process if they wish. Take the following example:

A company, BigCo, has a section on their website in which employees can check their schedule and company memos. This section is obviously something they want to keep very safe. BigCo feels they will be better protected by making sure aspects of the authentication are secret and available only to their employees, so they force their employees to use BigCo’s custom Homesite.

At BigCo’s employee login section their request tries to fetch a property that is not defined in the public SXIP schemas, /bigco/employeeAuth. Requesting this from a normal Homesite would not result in a proper response, as any Homesite other than BigCo’s would not have any knowledge of the property or how to fill it; however, BigCo’s Homesite knows to fill it with a signed assertion containing some values based on algorithms and data known only to BigCo’s servers.

To add more security to the process, BigCo’s Homesite will, if it gets a request for the /bigco/employeeAuth property, add a second level of authentication beyond the typical username and password it uses for general Homesite access. After entering their username and password (or right away if the user was previously authenticated in the session), BigCo’s Homesite asks the user to attach a… USB dongle — come on, I’m just trying to illustrate that any form of authentication is fine, no matter how paranoid one might want to be. Once it verifies that the user is an employee with good standing in the company, the response is sent back to the requesting section at which point it is verified against BigCo’s SSL certificate and whatever other magical secret data only BigCo would have access to.

Conclusion and Further Discussion

I had a great time at the conference and getting a chance to talk with all the speakers was amazing. Plus, I can finally add the third of the triumvirate of P language power to the list of people I have eaten lunch with.

For further discussion about the above topics, I have sent this entry to the sxip-discuss mailing list, and it can be found at http://listserv.sxip.org/pipermail/sxip-discuss/2005-January/000045.html. Please feel free to join in the discussion and refine these arguments and responses.

Tags: [tag:sxip], digital identity, [tag:php]

“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 https://sxip.net/docs, 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 https://sxip.org/Demo, 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.