[OpenID] Selectively Redirecting OpenID Traffic To HTTPS

Cameron King cameron at uniquekings.com
Sun Jan 13 14:36:17 UTC 2008


Ok, so let's say that I work at a company that has a network of some 
security level (a) and I am logging into a secure service of a different 
security level (b) with an OpenID.  If we are wanting OpenID to fit into 
this model, then it would need to be provable that a given provider is 
able to operate in these two levels.

I think we wouldn't want to make this a requirement for everyone, 
because it sounds to me like it would defeat the decentralized low 
barrier to entry aspect of OpenID... But it looks like something that 
might be interesting for specialized providers - particularly if 
companies start implementing OpenID internally.

Actually, in the face of so many providers, if one provider could 
implement the things you mention here and provide sufficient 
documentation and be willing to submit to audits - there might be a 
market for a paid service here.  There might be a niche willing to pay a 
fee for the privilage of having their provider meet these requirements - 
I don't know.

Peter Williams wrote:
>
> Im thinking more in terms of standards evolution, than today's deployment.
>
> Lets assume openid takes off as an SSO standard for the web -- and starts to protect even semi-critical infrasrtucture. We have to be able to rationalize the protection mechanisms of openid in standard terms. In the case of the issue you noted, that rationalization will need to address  how one would methodicically demonstrate how 'discovery over https" ensures the policy of the parties relying on one of the given virtual OPs in the multi-policy-domain OP server.
>
>
> ________________________________
>
> From: Cameron King [mailto:cameron at uniquekings.com]
>
> ...
> While I'm not sure that either of these are in the realm of possibility
> for your average net user trying to setup his vhosted blog to delegate
> an OpenID, these options might be very appealing to a larger company who
> wants to SSL enable all their OpenIDs.
>
> Peter Williams wrote:
>> There would seem to be two, obvious architected approaches to the underlying assurance issues for multiple OPs operating in a virtual https context (wildcard SSL certs, vs load balanced clusters relying on SSL session de/multiplexing):-
>>
>> 1. A MISSI-based B3-grade general-purpose server system, in which the crypto of each openid OP is keyed/controlled by a distinct policy authority asociated with one PKI (controlling via certs how reliance is performed in that partitioned distibuted community), with the B3 principles on the virutal host ensuring that protection domains and security domain design principles properly seperate the OPs from each other when handling messages
>>
>> 2. A OpenId Server supportiing virtual OPs addresses the requirements of http://www.niap-ccevs.org/pp/draft_pps/pp_draft_skpp_hr_v0.621.pdf - where crypto is just a bit of signing/verification/keyexchange rather than a control system providing for seperation. The assurance comes from the design of the kernel, upon which one must ultimate rely.
>>
>> Depending which side of the assurance wars you fall into (NSA crypto-based assurance, or DARPA/USNavyHA trusted OS assurance), you can choose your own poison.
>>
>> ________________________________
>>
>> From: general-bounces at openid.net on behalf of Cameron King
>>
>> By vhosts I mean name-based virtual hosting.  Most hosting providers do
>> not give each user their own IP address and certificate.  Often the
>> added cost of a SSL-enabled hosting plan (expecially a wildcard
>> certificate) can be substantial compared to the otherwise low cost of
>> hosting.  We wouldn't want to make SSL a requirement if we are shooting
>> for high adoption rates.
>> ...


-- 
Cameron King



More information about the general mailing list