It looks like the OpenID Authentication
specification has finally been released, along with OpenID Attribute
there are some questionable features in the new specification (namely
XRIs), it seems like a worthwhile improvement over the previous
specification. It will be interesting to see how quickly the new
specification gains adoption.
While this is certainly an important milestone, there are still areas
Best Practices For Managing Trust Relationships With OPs
The proposed Provider Authentication Policy
allows a Relying Party to specify what level of checking it wants the
OpenID Provider to perform on the user (e.g. phishing resistant, multi
factor, etc). The OP can then tell the RP what level of checking was
What the specification doesn't cover is why the RP should believe the
OP. I can easily set up an OP that performs no checking on the user but
claims that it performed "Physical Multi-Factor Authentication" in its
responses. Any RP that acted on that assertion would be buggy.
This isn't to say that the extension is useless. If the entity running
the RP also runs the OP, then they might have good reason to believe the
responses and act on them. Similarly, they might decide that
JanRain are quite trustworthy so believe
responses from myOpenID.
What is common in between these situations is that there is a trust
relationship between the OP and RP that is outside of the protocol. As
the specification gives no guidance on how to set up these
relationships, they are likely to be ad-hoc and result in some OpenIDs
being more useful than others.
At a minimum, it'd be good to see some best practices document on how
to handle this.
Trusted Attribute Exchange
As mentioned in my previous article on OpenID Attribute
Exchange, I mentioned that attribute values provided by
the OP should be treated as being self asserted. So if the RP receives
an email address or Jabber ID via attribute exchange, there is no
guarantee that the user actually owns them. This is a problem if the
RP wants to start emailing or instant messaging the user (e.g. OpenID
enabled mailing list management software). Assuming the RP doesn't
want to get users to revalidate their email address, what can it do?
One of the simplest solutions is to use a trust relationship with the
OP. If the RP knows that the OP will only transfer email addresses if
the user has previously verified them, then they need not perform a
second verification. This leaves us in the same situation as described
in the previous situation.
Another solution that has been proposed by Sxip
is to make the attribute values self-asserting. This entails making the
attribute value contain both the desired information plus a digital
signature. Using the email example, if the email address has a valid
digital signature and the RP trusts the signer to perform email address
verification, then it can accept the email address without further
This means that the RP only needs to manage trust relationships with the
attribute signers rather than every OP used by their user base. If there
are fewer attribute signers than OPs then this is of obvious benefit to
the RP. It also benefits the user since they no longer limited to one of
the "approved" OPs.
Canonical IDs for URL Identifiers
I've stated previously that I think the
support for identifier reuse with respect to URL identifiers is a bit
lacking. It'd be nice to see it expanded in a future specification
[...] James Henstridge gives an in depth account of the differences
in his blog post titled “OpenID 2.0”, with some additional information
in his more recent post titled “OpenID 2.0 Specification Approved”.