[OpenID] One-Click OpenID: A Solution to the NASCAR Problem

[Francisco Corella]

Peter,

> I read the post.
> 
> If the metric or program acceptance were: how are several latent
> technologies linked together to solve a problem that is "just holding
> back" the floodwall of adoption, (vs., can I have some cash for my
> idea, like one might make an investor in your startup), one might well
> tie a couple of projects together.

The focus of the pilot program is to address barriers that have held
back adoption: "Pilot Program Focus Area: Building Identity Ecosystem
Foundations and Frameworks to Address Barriers".

> Since you are having the IDP issue a client cert to the SSL module of
> a browser, let's remark that said cert is essentially a cookie (in
> function). Its not an ID cert, issued by a CA, and its not tied to any
> type of smartcard. Lets call it a IDP's session-cert. 

I wouldn't call it a session-cert because it is long-lived.

> As the webid
> project has shown, in can contain in the URI name field a pointer to
> HTML5-marked up file, listing the users XYZ service access points. Of
> course, this should sound like openid1 (where the metadata tags in the
> users own XRD on his/her blogsite played the role, formally). These
> days, it can be a blog post body itself, rather than meta links in a
> hard-to-edit HTML header or XRD (XML) file. The links simply point to
> the OP endpoint.

> Nothing "new" in that idea, except that a couple of more relevant
> technologies were hooked up, with a custom SSL cert used as some
> glueware. Nothing stops a CA's cert also being used directly wit hthe
> IDP or the RP, in multiple browsers (tied one day to a national-id
> smartcard, or mobile phone SIM card, or NF device... ).
> 
> 3 things are different - and not just the same old war horse
> arguments, repeated over and over and over again. There are different
> types of certs, and IDPs can issue them too (for "management/discovery
> purposes"). Said certs have an nice auto presentation, due to SSL
> sessionid mechanisms, being optionally consumed by requesting
> sites. They also have nice consent mechanisms (on first time
> release). They can have URIs in them, that solve the type-here
> problem. 

I suppose you are referring here to the URI of the OpendID provider
endpoint.  Yes, my first idea was to include the URI in the
certificate.  But now I prefer to download it to the browser together
with, but outside of, the certificate.  That way the
one-click/one-button login-with-openid solution also works when the
user authenticates to the OpenID provider with the traditional
username and password.

> The URI can these days be pointing to the bodies of
> files/posts, that even I can edit. Various technologies are available
> for markup, in the era of HTML5 semantic markup going "consumer".
> 
> this is what Id expect to hear in the rationale for why I want
> funding. I would not expect to here about how to solve the nascar
> problem (thats not the reason I fund stuff, though other agencies
> might on such criteria). 

Sure, I won't talk about NASCAR in the proposal.

I want to hear how rich is the US national
> infrastructure, so lots gets solved. Id perhaps want to here that the
> SSL proxy mode of the corporate firewall might be handling this class
> of client certs and the https client authn, too (rather than the
> browser itself).
> 
> This is just my guess of what they want to hear (not that I
> know...). The art of winning funds to know the mindset of the program
> manager. Not to do so is the commonest cause of grant application
> failures.

Thanks for the advice, I'll keep it in mind.

Francisco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20120216/83605b1e/attachment.html>