[OpenID] Rule of thumb

[Recordon, David]

Peter,

The RP can discover the information in the cert by connecting to the Provider's OpenID Endpoint URL and looking at the certificate there for example.

 

I'd be very interested in you sending an email to specs at openid.net with things you see missing from the PAPE extension draft!

 

Thanks,

--David

 

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Peter Williams
Sent: Friday, July 13, 2007 3:46 PM
To: Eddy Nigg (StartCom Ltd.)
Cc: OpenID - General
Subject: Re: [OpenID] Rule of thumb

 

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/20070721/a85c74a7/attachment-0002.htm>