Migrating from HTTP to HTTPS Open ID

From IIW

Tuesday - Session 2 - F

Convener: George Fletcher

Notes-taker(s): George Fletcher

A. Tags for the session - technology discussed/ideas considered:

OpenID, HTTP OpenIDs, HTTPS OpenIDs, Upgrading


B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

XRDS: https://api.screenname.aol.com/auth/openid/xrds XRD: http://www.aol.com/.well-known/host-meta

Type URI: 

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

When validating an OpenID via discovery and XRDS 

 <XRD> 
   <Service xmlns="xri://$xrd*($v*2.0)">
     <Type>http://specs.openid.net/auth/2.0/httpsUpgrade</Type>
     <URI>http://openid.aol.com/gffletch</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/gffletch</Subject>
   <Link rel=openid' href='https://openid.aol.com/gffletch'>
       <Property type=’http://specs.openid.net/auth/2.0/httpMapping’>http://opened.aol.com</Property>
   </Link>
   <Link rel='describedby' href='http://profiles.aim.com/gffletch' 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

Retrieved from "https://iiw.idcommons.net/index.php?title=Migrating_from_HTTP_to_HTTPS_Open_ID&oldid=1768"