• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

OpenID Authentication 2_0 Errata

Page history last edited by Martin Atkins 11 years, 11 months ago

This page is for collecting additional requirements that are not made clear in the published OpenID Authentication 2.0 specification, for reference in the short term and for possible incorporation into the next version of OpenID Authentication in the longer term.


Signed extension fields must have a signed namespace declaration

Extension fields may be included in the signature of a positive assertion. In this case, the namespace declaration (openid.ns.prefix) MUST also be signed. If it is not signed, then any fields declared with that prefix cannot be considered to be signed, as an attacker could tamper with the namespace declaration to change the meaning of the extension fields.

setup_needed responses must contain user_setup_url

OpenID 1.1 had a user_setup_url argument in this case, which told the RP where to send the user for setup. This was removed in OpenID 2.0 since it was perceived to be redundant: the RP should just do a checkid_setup request. In practice, OpenID RP libraries have been unable to implement this without breaking API compatibility, since they don't know the base URL in order to synthesize a setup URL. Therefore a number of OpenID 2.0 RP implementations actually fail if user_setup_url is not present, and therefore most OP implementations include it, in many cases setting it to be their own checkid_setup URL.

While this is actually an RP bug, it's widespread enough that at this point it might as well just be put back into the spec again so that the spec describes reality.

When using HTML-based discovery, separate out OpenID 1.1 and OpenID 2.0 links

For interoperability, folks publishing HTML links for OpenID discovery should separate out the OpenID 1.1 and OpenID 2.0 links, despite the fact that merging them is allowed in HTML. There are many RPs that do not process HTML as per the HTML specification. For example:

<link rel="openid2.provider" href="http://factoryjoe.com/blog/?openid_server=1" />
<link rel="openid2.local_id" href="http://factoryjoe.com/blog/author/factoryjoe/" />
<link rel="openid.server" href="http://factoryjoe.com/blog/?openid_server=1" />
<link rel="openid.delegate" href="http://factoryjoe.com/blog/author/factoryjoe/" />

Comments (0)

You don't have permission to comment on this page.