Proposal : OpenID UI Extension for RP Proxy

OpenID

1. The additional player of OpenID : "RP Proxy"

The current OpenID Auth spec defines the authentication process between three primary players.

  • Relying Party
  • OpenID Provider
  • End User

I think that there is another player between RP and OP.
Here, I call the the fourth Player "RP Proxy".


The RP Proxy sends the OpenID Authentication request to OP instead of RP.
And they receive an authentication response from OP and hand user data to RP.

RP Proxy helps Identity system implementation of RP by the following points.

  • The support of slightly different OpenID Provider specifications
  • The support of other authentication / authorization protocols(OAuth,Facebook Connect)
  • Improvement of the user experience by unified UI

For example, JanRain's RPX does proxy of Authentication process of various Identity Provider,
and the Web site developer using it can build the ID system with simple APIs.

2. The user's confusion caused by RP Proxy

When user tries to sign in to RP with OpenID via RP Proxy, OP requires user to agree to sign in to "RP Proxy" with own identifier.
OP shows the domain of RP Proxy which is included by return_to or realm parameters to user, and display following messages.

  • Sign in to "RP Proxy" with your OpenID.
  • Sign in to "RP Proxy" with your OpenID and share your attribute info.

User cannot get information about RP.
In other words the user does not agree to share data to "Real RP".

I think that such usecases will increase in future.
When the public organization(e.g. government) site adopts OpenID in an authentication protocol,
I imagine that the reliable RP Proxy connects those site and famous OP.

So, I propose the enhancement of OpenID UI Extension for the improvement of user experience in the case including RP Proxy.

3. Spec

The scopes of this extension are here.

  • The method to know both relations of RP and RP Proxy.
  • The method to agree to each TOS

3.1 Discovery

Each player includes following element in xrds discovery document.

3.1.1 OP

<Type>http://specs.openid.net/extensiones/ui/1.0/rpproxy/op</Type>

By this element, RP Proxy is able to find that OP supports this extension.

<Type>http://specs.openid.net/extensiones/ui/1.0/rpproxy/tos</Type>

By this element, RP Proxy is able to find that OP supports the TOS display.

3.1.2 RP Proxy

RP Proxy shows the RP domain to include in authentication request.

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/extensions/ui/1.0/rpproxy/rpproxy</Type>
  <URI>http://rp.example.com/</URI>
</Service>

If RP Proxy wants to display own TOS, it needs following service description.

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/extensions/ui/1.0/rpproxy/rpproxy_tosurl</Type>
  <URI>http://rpproxy.example.com/defaulttos</URI>
</Service>

This TOS url is "Default URL", and RP Proxy is able to include another TOS url in the AuthN Request.

3.1.3 RP

RP shows that oneself uses RP Proxy.

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/extensions/ui/1.0/rpproxy/rp</Type>
  <URI>http://rpproxy.example.com/</URI>
</Service>

Similar to RP PRoxy, RP is able to show the "Default" TOS URL.

<Service xmlns="xri://$xrd*($v*2.0)">
  <Type>http://specs.openid.net/extensions/ui/1.0/rpproxy/rp_tosurl</Type>
  <URI>http://rp.example.com/defaulttos</URI>
</Service>

OP identifies these elements by RP Discovery.


3.2 Authentication Request

RP Proxy adds some parameters to a AuthN request to send to OP.

openid.ns.ui : REQUIRED. Value : "http://specs.openid.net/extensions/ui/1.0"
rp_domain : REQUIRED. Value : "http://rp.example.com/"
rpproxy_displaytos : (optional) Value : "true" or "false"
rpproxy_tosurl : (optional) Value : "http://rpproxy.example.com/customizedtos"
rp_displaytos : (optional) Value : "true" or "false"
rp_tosurl : (optional) Value : "http://rp.example.com/customizedtos"

OP which received these parameters do the following action.

  • Perform RP Discovery and verify extension support
  • If "displaytos" param is "true", validates "TOS Url" parameter.
  • If "TOS Url" parameter exists, use it as TOS URL by RP Discovery.

RP Proxy TOS URL : http://rpproxy.example.com/customizedtos
RP TOS URL : http://rp.example.com/customizedtos

  • If "TOS Url" parameter is null, OP use default TOS URL by Discovery result.

RP Proxy TOS URL : http://rpproxy.example.com/defaulttos
RP TOS URL : http://rp.example.com/defaulttos

3.3 Consent Page layout

Screen image is here.

3.4 Authentication Response

OP returns the params which means "User agreed TOS url." to include AuthN response.

openid.ns.ui : REQUIRED. Value : "http://specs.openid.net/extensions/ui/1.0"
rp_domain : REQUIRED. Value : "http://rp.example.com/"
rpproxy_tosurl : (optional) Value : "http://rpproxy.example.com/customizedtos"
rp_tosurl : (optional) Value : "http://rp.example.com/customizedtos"

RP and RP Proxy are able to manage "Agreed TOS" on a case by case.

                • -

This is my personal idea.
Please feedback comment if someone is interested in this post.