Migrating from HTTP to HTTPS OpenID

Session: Tuesday Space 2 Session F

Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes

The basic concept to upgrade an HTTP OpenID to an HTTPS OpenID is to leverage the OpenID discovery step over SSL to identify the equivalent HTTP based OpenID. Some thoughts and examples below.

Type URI:

  http://specs.openid.net/auth/2.0/httpMapping

When validating an OpenID via discovery and XRDS

Example mapping for XRDS

 <XRD> 
   <Service xmlns="xri://$xrd*($v*2.0)">
     <Type>http://specs.openid.net/auth/2.0/httpMapping</Type>
     <URI>http://openid.aol.com/chattingchuck</URI>
  </Service>
 </XRD>

Example mapping for XRD

   <?xml version='1.0' encoding='UTF-8'?>
   <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
       <Subject>https://openid.aol.com/chattingchuck</Subject>
       <Link rel=openid' href='https://openid.aol.com/gffletch'>
           <Property type=’http://specs.openid.net/auth/2.0/httpMapping’>http://opened.aol.com/chattingchuck</Property>
       </Link>
       <Link rel='describedby' href='http://profiles.aim.com/chattingchuck' type='text/html' />
   </XRD>

OP defines <Type> URI in XRDS/XRD specifying that it implements the HTTP->HTTPS upgrade path.

  http://specs.openid.net/auth/2.0/httpMapping

Processing rules for the OP

1. When the discovery request is made over HTTPS, then return the alias type and associated http OpenID.
2. If the initial request for the OpenID flow come in over HTTP, then 301 to the HTTPS identifier

Processing rules for the RP

1. When the OpenID assertion contains an HTTPS OpenID the RP first looks to see if this OpenID is known. If found, then done.
2. If the HTTPS identifier is NOT found, look in the discovery document for an "alias" type in the discovery document
3. If the Alias is found, the RP looks for that OpenID in their store
4. If found, then update the user id in the RP data store from the HTTP version to the HTTPS version
5. If not found, then this is a new user. Add them with their HTTPS OpenID

Roll out/deployment

1. OP updates discovery documents to provide alias in documents retrieved over SSL but still returns the HTTP OpenID
   • this allows RP's to run "batch" jobs to upgrade the user
2. After some period of time, the OP stops returning HTTP identifiers and only returns HTTPS identifiers

Questions:

1. How to protect against from rogue OP returning a mapping for a different OP?

Alternate proposal (John Bradley)

• RP's assume that an HTTPS identifier is the same as the HTTP identifier and do an "autoupgrade" if the identifiers are exactly the same except for scheme.

1. OP MUST move to HTTPS OpenIDs permanently
2. OP MUST 301 HTTP requests to HTTPS
3. If the RP has an existing HTTPS identifier for the user, it MUST NOT consider the HTTP version to be the same
4. Upgrading the HTTP OpenID to HTTPS MUST only occur for users that do NOT have an existing HTTPS OpenID identifier