[OpenID] Rule of thumb

[Peter Williams]

Ok. You and I are on the same page in a vital area. I intended to say a variant of the same thing last week, in the discussion on NIST levels.
 
The authnContext signal (saml world) or http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html#examples values (openid world) have to convey more than “it satisfied level 3 of NIST SP800-63.” RPs need to have some more details (e.g. the name of the CA used by the OP Provider).
 
I you recall last week, I gave an example. Value = 800-63-level-3: 802.1x-RSAEAP
 
This was an example (in a non cert, no-SSL user-auth sphere) where the IDP is signaling detailed technical-security-policy  to the RP, saying: yes I used Ethernet wired 802.1X, using the RSA-EAP mechanism (RSA’s OTP-grade user auth, for 802.1X).
 
 
 
I create an openid provider that accepts ssl client certs from cacert. It issues openid assertions, using signed-mac security mechanisms.
 
Are you advocating that now the the major RPs now refuse to accept that OP provider - because of its earlier association with the unacceptable cacert?
  

It might be...Or it might depend on what you advertise...You see, this is already something which the organization/body I envision has to decide and provide the mechanism to set the level a RP might require/request. Similar to the examples from her: http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html#examples
So one level might be GPG and web-of-trust verified authentication. There is nothing wrong with that, except there should be a mechanism which would the RP to accept/allow it or not. The important issue is, that your claims (whatever they are) have been verified and you don't advertise something wrongfully. Even the fact of having undergone a certain verification process will prevent a rough IDP from operating.



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070713/29231ff4/attachment-0002.htm>