Category Archives: openid

The Use and Abuse of Identifiers

In my line of work at TrustBearer, we work with a number of different identifiers, be they OpenID URIs, usernames, or email addresses. In this way, I probably don’t have an realistic appreciation for how most people using such identifiers think and feel about their email addresses,  usernames, or twitter handles. And for this reason, I’ve found the research of doctoral student Ben Gross (@bengross) quite interesting and valuable.

In short, Gross has found that people have rather personal feelings about the identifiers that they are assigned and used, and they have a hard time using these identifiers how they would like, or how their employer expects them to.

Much of this research was discussed in a recent presentation at BayChi San Francisco (a chapter of the ACM Special Interest Group on Computer-Human Interaction).

Gross’s research involved talking with people in two types of companies, financial and creative, about the identifiers they use at work and in their personal life. His findings help explain why people often accidentally (and purposely) misuse identity systems:

  • Most people are managing a few email addresses, dozens of usernames and passwords, and several other identifiers, and they make very complex social decisions about how and why they use these identifiers.
  • The people Gross talked with wanted their identifiers to be their own name—even John Smith— or something meaningful and easy-to-remember.
  • People want to use personal and other identifiers at work; if they have trouble with identity and communications  systems at work, they use personal ones, e.g. their Hotmail.
  • Everyday use of identifiers can involve technical concepts, which are foreign to most users.
  • Some people Gross talked with started using an identifier in a certain way, but they don’t remember the initial reason or preference for this.
  • People usually don’t understand and often dislike and avoid identity system policies and rules.

Gross also has looked into what people know and don’t know about their privacy related to identifiers. Like something you are or something you have, the things that you are assigned, such as a IP address, a location, or a web cookie, act as identifiers. And it is these identifiers that are most often used on the web for tracking people’s behavior and information (See Kim Cameron’s recent post about browser fingerprints). In this case, Gross looks forward to better applications and tools that allow average web users to control their privacy and for more transparent policies with regard to what information companies or other entities store and track.

Gross’ dissertation and published writings are available on his website. He has written about OpenID and OAuth on his blog at The Messaging News.


Online web mail provider adds OpenID support

I hadn’t heard of this web mail provider until a recent blog post from their site where they discuss security options for OpenID. Thanks for the mention, LuxSci. 

Secure ID Card or USB Token: With one of these devices, you authenticate yourself by having the device in your possession and connecting it to your computer when you want to login.  This is very secure and can be combined with a password for two-factor authentication and strong hardware-based security

TrustBearer is the leading company providing OpenIDs that work with such hardware devices.  They also sell their own device.

Biometrics: Perhaps the most secure way of authenticating is the use of Biometrics.  The most common way to do this is to have a USB device which will read your fingerprint and verify it so that only you can login to your OpenID.

TrustBearer supports this.  The account is free. All you need is the fingerprint reader.

via Extreme WebMail Login Security with OpenID | LuxSci FYI.

A note on the biometrics device support: Currently, TrustBearer OpenID supports the Privaris plusID personal fingerprint reader and the Precise Biometrics 200MC & 250MC with a PIV smart card with Match-On-Card support. We’ve received a few emails about supporting the IBM/Lenovo ThinkPad fingerprint readers. We do not yet support these biometric readers.

Building on the OpenID PAPE specification

When we decided to launch our TrustBearer OpenID provider, we were excited that there was an extension to the OpenID specification that would allows us to convey the strength with which we authenticated our users. The OpenID Provider Authentication Policy Extension (PAPE) appeared to provide us with a way to tell Relying Parties (RP) that we were using arguably one of the strongest methods of user authentication available: PKI challenge-response with the user’s private key stored in a hardware device and protected by a passphrase.

PAPE allows OpenID Providers (OP) to describe their authentication policies to RPs using the following 3 categories:

  • Phishing-Resistant Authentication: An authentication mechanism where the End User does not provide a shared secret to a party potentially under the control of the Relying Party.
  • Multi-Factor Authentication: An authentication mechanism where the End User authenticates to the OpenID Provider by providing more than one authentication factor.
  • Physical Multi-Factor Authentication: An authentication mechanism where the End User authenticates to the OpenID Provider by providing more than one authentication factor where at least one of the factors is a physical factor such as a hardware device or biometric.

There is some overlap between these categories, and if an OP supports more than one policy, they should all be asserted. (e.g. Using a hardware-based key with PIN would typically include all 3 of these policies)

For TrustBearer OpenID we assert all three of these policies. This would appear to say to RPs that we are providing the strongest authentication techniques available. And it does.

But there is a problem.

Many other OPs, using arguably less-strong authentication techniques could also assert the exact same policies. How? Consider the following scenarios.

Phishing-Resistant Authentication

This policy states that if a shared secret is not passed from the user to the OP, then this authentication method is considered to be phishing resistant. Does this include a password that is sent over an SSL channel? What about a one-time-password? Depending on their opinion, an OP could probably make the case that they support or don’t support phishing-resistant technology. The decision is subjective.

Multi-Factor Authentication

The policy states that the user authenticated using more than one factor (something you have, know, or are). The problem is that all kinds of multi-factor authentication are not treated equally. One OP could authenticate its users using client authentication with SSL and a password-protected private key, while another OP could use a password + visual grid card. These types of multi-factor authentication are not equivalent, but this policy could imply that they are equal.

Physical Multi-Factor Authentication

The policy states that the user authenticated using multiple factors where one of the factors is a “hardware device or biometric.” Like the multi-factor authentication case, specifying “physical” still opens a wide range of levels of authentication. A biometric device that unlocks a password that is sent to the website is far less secure than using PKI-based smart card authentication with PIN protection.

The PAPE authors intentionally avoided defining specific authentication methods. Instead, they stuck to these higher-level policies to describe classes of authentication that were used. While I understand the motivation of this decision (high-level policies change less than authentication technology), I feel that it will lead to OPs and RPs subjectively interpreting how the user was actually authenticated.

A Solution

A few members of a related industry group, the Initiative for Open Authentication (OATH), got together and discussed the PAPE specification. Together we came to the conclusion that specific assertions about how a user authenticated to an OP were needed. This group is tentatively calling our suggested changes OpenID Provider Authentication Policy Extension – Authentication Mechanisms (PAPE-AM).

Even though specific authentication methods change more often than the higher-level policies presented in PAPE, they are much more definitive. Consider the following OP response parameters presented in PAPE-AM (Note: These are all in a draft stage and have not yet been accepted by any official OpenID specification working group) :

  • method = {password, otp, pki, biometric}

    The authentication method must contain one or more of these elements in the set. We chose 4 of the most common authentication methods today. This set could be expanded in the future.

  • = {mode, token_type, consent, length, encoding, algorithm}

    This parameter contains detailed information about the type of One-Time Password token and service that was used during authentication. Consent is defined by the additional factor of authentication needed to use the OTP (such as a passphrase or biometric).

  • = {storage, algorithm, policy, consent}

    This parameter contains detailed information about the private key used in a challenge-response with PKI authentication. (e.g. “hardware”, “RSA_1024”, “not exportable”, “passphrase”)

Each of these response parameters are clearly defined. This gives both the OP and RP the ability to objectively assert and verify what method of authentication was used.

Who would use this? The same OpenID Providers & Relying Parties that would use PAPE. Here’s a couple use cases:

  1. Online banking website that supports government-issued ID smart cards

    Consider an online banking website that has adopted support for OpenID, but wishes to restrict access to users who have been issued a citizen ID smart card by government authorities that the bank trusts. In this case, the online banking website would use PAPE-AM to ensure hardware-based PKI authentication was used with the OP. The banking website would also use PAPE-AM to get information about who issued the user’s digital certificate.

    These additional request/response parameters provided by PAPE-AM help ensure that the bank’s users will not fall victim to hijacking attempts since client authentication using PKI with a hardware-based token was used. The information about the issuer of the certificate could help the bank prove the real-life identity of the user, also.

    By using PAPE-AM request/response parameters such as method,, pki.cert.revocation_check, and an online bank RP could be assured that the OP is authenticating its users as described above.

  2. Online Brokerage Supports OTP

    An online brokerage supports OpenID as a RP. However, when enabling users to authenticate via third-party OpenID Providers, they want to make sure that the user is using a hardware OTP token where the length of the OTP is at least 8. The RP can request additional PAPE-AM attributes during the OpenID exchange and thereby can be assured that the user and the OpenID provider meet the requirements.

    By using PAPE-AM request/response parameters, including method and, an online brokerage RP could be assured that the OP is authenticating its users as described above.

Next Steps

I created this post because the PAPE-AM authors and I wanted to engage the community that is impacted by both PAPE and the suggested changes that I outlined above. The authors and I felt that we could help OpenID gain adoption amongst Identity Providers & Relying Parties providing secure online services by improving the existing PAPE specificaiton. We have created an early draft of a PAPE-AM specification, and are searching for the best way to publish this draft – whether it is part of PAPE or as a standalone extension.

We would like feedback from the OpenID community. Do you think the high-level PAPE policies are sufficient? Do you see value in some of the proposed PAPE-AM request/response parameters? Should the PAPE-AM policies be merged into PAPE?

Please add your comments to this post or contact me directly.

We have enough OpenID providers?

Aaron Topance on big league OpenID providers that don’t accept OpenIDs from other providers:

There seems to be a trend, as of recently, for large companies to become OpenID providers, but now allow logging into their service with your OpenID account. The trend I’m noticing, is everyone wants to be a provider, but no one wants to support OpenID logins. Well not “no one”, but not the major players. Consider the following major corporations or web sites that are OpenID providers:

  • America Online
  • Orange
  • LiveJournal and Vox
  • Yahoo!
  • Blogger
  • Verisign
  • … and more

Supposedly, news has hit the front that Microsoft will be supporting OpenID as a provider, and rumors have it that your GMail account can be used as an OpenID identity. But what about logging into these providers with an existing identity? Here’s the question posed: Can I login to AOL, or create and AOL account, with an already existing OpenID identity? What about LiveJournal? WordPress? Yahoo!? Blogger? etc.

Killer App for OpenID

There’s an interesting discussion on Mark Evan’s blog about the potential of a killer application for OpenID:

One of the biggest challenges facing OpenID is it’s a solution (universal identity management) looking for a problem to solve.

Sure, it’s a pain having to remember different usernames and passwords (unless you lazily use the same ones for everything) but most people don’t see it as a huge issue, which means OpenID has failed to gain much traction. And to be frank, that won’t change much even with major players such as Google, Yahoo and AOL starting to climb on the OpenID bandwagon recently.

One of the applications the Evan’s points to with some enthusiasm is PageOnce, which is a universal dashboard for the web.

Yahoo Offers OpenID a Compelling Business Case

Johannes Ernst’s discuses the business ramifications of Yahoo joining the OpenID space:

Instead of being a technical curiosity, web businesses can now assume that the majority of their visitors have an OpenID. Okay, Yahoo and AOL and Blogger and all of the existing implementations don’t add up to more than 50% of internet users, but you can bet that more telcos become OpenID providers for their broadband customers, as Orange showed, and that all major internet portals, Microsoft and Google included, will offer OpenIDs with each of their accounts shortly. (It’s easy for them to do, and they don’t want to lose even one of their subscribers for the reason that they didn’t add a small bit of code to their site, that, boy, might even benefit them strategically, and not just create competitive parity.) It’s a very safe assumption for web businesses that by the time they can do anything about OpenID, regardless how fast they move, more than 50% of their visitors will have an OpenID, and Yahoo!’s move yesterday made that a virtual certainty.

Portable Social Networking

As OpenID gains recognition, how will other standards be developed to cooperate with decentralized single-sign-on?

Scott Kveton considers portable social networking and solutions that make it viable along side OpenID:

Social network fatigue is getting worse with every new site that comes along and it doesn’t have to. I should be able to sign up for a site with my OpenID and be prompted to import my contacts/friends accordingly. Ideally I could import them based on some criteria or tag; friends, colleagues, co-workers, etc. In the very near future, you won’t go to social networking sites to interact with your friends … every single site will have social networking built in.

There are a couple of solutions coming down the line. Tom and the folks at Barnraiser have been working on a portable social network solution that is based on OpenID. Videntity and claimID have also been working on ways to share contacts based on XFN. Both of these solutions adhere strictly to the limited format defined for XFN. These solutions suffer from the fax problem; faxes weren’t interesting until everybody had them … so how did they take off? There are also several other efforts as well.

Kveton post also touches on an interesting profile exchange protocol for OpenID, SREG.