oid2d5 - comment - Rich Client

[John Merrells]

I hope that you find the following comment of value, and that you will
carefully consider the merits of what I am proposing here. It's offered
up in the spirit of solving a shared problem - so long as the problem
is solved I don't really care what the solution actually looks like in
terms of the details.

I'm looking forward to the conversation.

John


--- Rich Client ---

Definitions

A Rich Client is a HTTP User Agent that is aware of an identity  
protocol.
This could be implemented as a browser plugin or extension, within
the browser itself, or as part of a none browser application that uses
HTTP/HTML.

Goals

Ease of Adoption - We want an identity protocol that is very easy for
User's and Relying Parties to adopt. Hence we aim for a zero footprint
solution for the User.

Internet Scale - We want an internet protocol that is universal and
ubiquitous, so we build a messaging layer on top of a transport layer.
And we first develop bindings for the most ubiquitous protocol and
client software - HTTP and the web browser. We want the solution
to work for all web browsers.

Problems

An IdP as a website solution gets us zero footprint, but perhaps not
with the greatest user experience.

An IdP as a website solution gets us ubiquity as everyone has access
to a browser on every device (pretty much), but bandwidth is limited
on some devices. For example, browsing the web with a phone over a
GPRS connection is not fun.

Validation

These problems have been gathered from many conversations,
specifically with mobile phone handset manufacturers and web
browser developers.

Solutions

A Rich Client provides an improved user experience by reducing
bandwidth requirements and latency, whilst improving the user
interface and preventing common phishing attacks.

A Rich Client makes browsing on a phone and making use of an
identity protocol more viable.

Requirements

The login user interface components must be specified and must
be marked in a well-known way for Rich Clients to detect them.

The Relying Party must be able to negotiate the services it requires
without having to access a website, it must communicate inline
with the Rich Client.

The Relying Party should be able to include it's request message
in the login user interface so that the Rich Client may process
the request and respond with the response message directly.

Solutions

My suggestions for extending oid2d5 to address these issues
would be to:

Extend the request message to include parameters for the RP
to state which services are required of the RC, and also which
services are optional.

Further specify the login user interface and include a marker to
flag the UI component as an oid2d5 login form. I'd suggest having
the CLASS attribute on the FORM element contain a well known
value. e.g. open_id.20d5_login_form.

Allow the request message to be embedded in the login FORM
so that when the RC browses to the login page it is able to
handle the request directly.