[OpenID] OpenID Providers Invited to Join in an NSTIC Pilot Proposal

[Francisco Corella]

Peter,

> I  do  have a technical/political question.
>  
> It took me nearly 5 years go finally figure why certain design
> principles of openid were held (as it took 5 years for them to be
> realized in the likes of blogspot.com, and display their
> "breakthrough" benefits). Folks would say certain things to me over
> and over again (but it didnt get through, probably as the properties
> were yet to be realized in both a mainstream and then a tangible
> form).
>  
> ON the topic you raise I have conjecture. It concerns the topic of
> only the issuer ever relying on the client cert (and then minting a
> openid assertion). This tying of cert issuing and cert relying and
> then openid assertion minting concerns me. This tying goes against
> what I was taught (that CAs MUST be distinct from any online agent).
>  
> Let's say the issuer on certissuer.com access its own cert repository,
> when relying on the cert, taking 1 uS. But it breaks the rule, and now
> allows 3 other domains (certissuer.uk, certissuer.fr, certissuer.de)
> to also relyon the client cert (and mint openid assertions). These 3
> have "special" access to the principal issuers cert repository, when
> relying on the cert, taking 1mS of delay (say). Perhaps the 4 sites
> have MPLS-VPN connecting them, and are federated legally (so the certs
> each issued can be relied upon by the others, reciprocally). Perhaps
> they are really manifestations of 1 multi-national company (operating
> in 4 jurisdictions).
>  
> Im getting the feeling that im bucking the trend by wanting to break
> free of the constraints being imposed - (1) that only an IDP minting
> assertions can mint the certs (which is the exact opposite of what I
> was taught 20 years ago), and (2) that only the IDP can rely on certs
> (that only it issued).
>  
> Are these constraints "fundamentals" of the NSTIC-profile of openid?

"NSTIC-profile of openid" is a bit premature, the blog post is just an
idea for a proposal for a pilot :-)

> Is it absolutely fundamental and critical that these constraints are
> upheld (or it is just a "easy" first step, for convenience, say)?

This is a very good question.  Neither constraint is fundamental. 

(1) is not fundamental.  You can think of the openid assertion as an
alternative way of conveying the identity information in the
certificate to the relying party.  In the blog post I asked for OpenId
providers who, in effect, would like to become CAs.  I should also
have asked for CAs who would like to become identity providers.  Of
course if some relying parties verify the certificate themselves, then
the CA will have to issue CRLs, or provide an OCSP service.  So things
wouldn't be any simpler for the CA, they would be more complicated.
But things would be simpler for those RPs that do not verify the
certificates themselves nor check the CRLs.

(2) is not fundamental either.  As long as the IdP has access to the
certificate repository, it doesn't need to check a CRL.  So
certissuer.uk, certissuer.fr and certissuer.de would fit the purpose.
It even makes sense to have an IdP that's associated with a particular
CA but does not have access to the certificate repository because the
repository is tightly coupled with the CA software and it is
impractical to provide external access to it.  In that case the IdP
could verify certificates using a CRL obtained from the CA.  Again
this complicates the CA/IdP entity but may greatly simplify the RPs.
Notice that the IdP only has to deal with CRLs from one CA, which is
easy, whereas each RP may have to deal with CRLs from an unlimited
number of CAs, which is difficult or impossible.

> Im seeing the constraint popup, almost in concert, in 4 forums
> now. Either there is some central coordination group manipulating, or
> there is a "movement afoot" based on some valuable realization (that
> Im too dense or too fossilized to be picking up).

It's just an idea whose time has come, I would think.  Could you tell
us what those forums are?

Francisco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20120212/35e3eefb/attachment.html>