<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt">Peter,<br><br>> I read the post.<br>> <br>> If the metric or program acceptance were: how are several latent<br>> technologies linked together to solve a problem that is "just holding<br>> back" the floodwall of adoption, (vs., can I have some cash for my<br>> idea, like one might make an investor in your startup), one might well<br>> tie a couple of projects together.<br><br>The focus of the pilot program is to address barriers that have held<br>back adoption: "Pilot Program Focus Area: Building Identity Ecosystem<br>Foundations and Frameworks to Address Barriers".<br><br>> Since you are having the IDP issue a client cert to the SSL module of<br>> a browser, let's remark that said cert is essentially a cookie (in<br>> function). Its not an ID cert, issued by a CA, and its not tied to any<br>>
type of smartcard. Lets call it a IDP's session-cert. <br><br>I wouldn't call it a session-cert because it is long-lived.<br><br>> As the webid<br>> project has shown, in can contain in the URI name field a pointer to<br>> HTML5-marked up file, listing the users XYZ service access points. Of<br>> course, this should sound like openid1 (where the metadata tags in the<br>> users own XRD on his/her blogsite played the role, formally). These<br>> days, it can be a blog post body itself, rather than meta links in a<br>> hard-to-edit HTML header or XRD (XML) file. The links simply point to<br>> the OP endpoint.<br><br>> Nothing "new" in that idea, except that a couple of more relevant<br>> technologies were hooked up, with a custom SSL cert used as some<br>> glueware. Nothing stops a CA's cert also being used directly wit hthe<br>> IDP or the RP, in multiple browsers (tied one day to a national-id<br>> smartcard, or
mobile phone SIM card, or NF device... ).<br>> <br>> 3 things are different - and not just the same old war horse<br>> arguments, repeated over and over and over again. There are different<br>> types of certs, and IDPs can issue them too (for "management/discovery<br>> purposes"). Said certs have an nice auto presentation, due to SSL<br>> sessionid mechanisms, being optionally consumed by requesting<br>> sites. They also have nice consent mechanisms (on first time<br>> release). They can have URIs in them, that solve the type-here<br>> problem. <br><br>I suppose you are referring here to the URI of the OpendID provider<br>endpoint. Yes, my first idea was to include the URI in the<br>certificate. But now I prefer to download it to the browser together<br>with, but outside of, the certificate. That way the<br>one-click/one-button login-with-openid solution also works when the<br>user authenticates to the OpenID
provider with the traditional<br>username and password.<br><br>> The URI can these days be pointing to the bodies of<br>> files/posts, that even I can edit. Various technologies are available<br>> for markup, in the era of HTML5 semantic markup going "consumer".<br>> <br>> this is what Id expect to hear in the rationale for why I want<br>> funding. I would not expect to here about how to solve the nascar<br>> problem (thats not the reason I fund stuff, though other agencies<br>> might on such criteria). <br><br>Sure, I won't talk about NASCAR in the proposal.<br><br>I want to hear how rich is the US national<br>> infrastructure, so lots gets solved. Id perhaps want to here that the<br>> SSL proxy mode of the corporate firewall might be handling this class<br>> of client certs and the https client authn, too (rather than the<br>> browser itself).<br>> <br>> This is just my guess of what they want to hear (not
that I<br>> know...). The art of winning funds to know the mindset of the program<br>> manager. Not to do so is the commonest cause of grant application<br>> failures.<br><br>Thanks for the advice, I'll keep it in mind.<br><br>Francisco<br><br></div></body></html>