[OpenID] ANN: OpenID Information Cards spec and workingimplementation

Tue Aug 28 01:04:28 UTC 2007

Johnny: Some comments and initial conclusion following, merely trying to comprehend what I am reading.

(1)	It makes sense that the MSFT CardSpace process on the WinNT host acts as trusted relay between two web sessions. This make better sense __in assurance terms__ than making an OP using a general thread pool perform less-trustworthy layer 7 gatewaying.

a.	However, the overall security concept places an even higher trust burden on the OP, charged with issuing a dumb-mode verification token attesting to its belief that the OpenID Auth Response provided by the STS is valid. 

b.	The trust burden placed on an OP mitigates against the assurance rationale offered in (1), unless it’s a specific design intent to separate the roles of STS and OP (similar to how Authenticode CAs perform an entirely different role to the role performed by Authenticode’s so-called timestamp authorities)

(2)	All webSSO communications involving an infocard both to and from a RP website MUST use infocard-defined protocols and signaling (hidden form fields, object tags, XHTML behaviors, object properties for claimset requirements)

a.	The specification would seem to limit itself to HTML-capable, MIME capable, HTTP systems.

(3)	By referencing attached and unattached OpenID tokens, the infocard protocol implementation uniquely shall decide which communications security services shall be applied to token passing, if any.

a.	The strength of the reference  is dependent on the strength of SHA1, a suspect candidate.

(4)	Communications between the cardspace trusted process and the STS MUST use ws-federation active

(5)	The OP SHALL support two endpoints: (i) OpenID Auth and (ii) ws-federation active

(6)	A “stub” OpenID Auth 2.0 protocol handler MUST be co-resident with the STS handler supporting the ws-federation active endpoint.

a.	The protocol engine of the OpenID Auth 2.0 handler MUST be limited to 
i.	manufacturing OpenID tokens
ii.	manufacturing OpenID Auth Response messages to be wrapped in OpenID Tokens, and 
iii.	possibly  “supporting” dumb mode verification procedures for OpenID Auth Response messages it knows it has previously wrapped

b.	OpenID Tokens MUST wrap only OpenID Auth Response messages by the thread operating the ws-federation active endpoint.

(7)	A complete OpenID Auth protocol handler shall be listening on the OpenID Auth endpoint. 

a.	It MUST NOT be able to manufacture OpenID Tokens
b.	It MUST NOT be able to perform dumb mode verification procedure on any Auth Response message that has ever been wrapped in an OpenID Token
c.	The Message queues shall be compartmentalized from queues supporting the stub OpenID Auth protocol handler. 
d.	The protocol engine may support any version of OpenID Auth

(8)	An RP MUST rely on SSL to authenticate an OP Provider performing dumb-mode verification of Auth Response messages.
a.	An RP may rely on PKI/certs signals to determine that a given OP Provider is entitled to speak for the verification of tokens issued by a given STS.

b.	A PKI control system may obviate the need for 6a(iii) when the RP can be trusted to handle PKI signals in a conforming manner

Initial conclusions:-

A.	It’s complicated set of trusted channel and trusted process relationships.

B.	The purpose of doing all what follows is to eliminate “the "Rogue Relying Party Proxying" attack described in the Security Consideration section of [OpenID.authentication2.0] (Recordon, D., Hoyt, J., Fitzpatrick, B., and D. Hardt, “OpenID Authentication 2.0 - Draft 11,” January 2007.) <> .” 

C.	Several protocols must be integrated – protocols that were not designed as a family: ws-fed, Openid Auth, https/SSL/PKI, infocard.

D.	It is critically dependent on trustworthy http channels: e.g. https, SSLVPNs, IPSEC VPN, or equivalent. https is also a critical security enforcing function in authenticating the validity of claims.

E.	There is not a lot left of OpenID Auth, apart from the definition of KV Form of Auth Response, and dumb mode verification flow. 

F.	The role of OpenID AX seems mostly unchanged

G.	The control relationship between infocard authority (service discovery), token authorities  (claim provider), token verification authorities (current validity of claims), and critical https endpoints will require advanced, highly coordinated PKI.

H.	The RP-centric discovery and locating process (via HTML and XRI metadata) is eliminated in favor of card-discovery and server-location processes mediated by the Cardspace process on the browser host, as directed by the infocard protocol.

I.	The implementer of an OP must implement several SOAP and WS* vocabularies in order to process an RSTR

		   xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity"
               xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
               xmlns:wsa="http://www.w3.org/2005/08/addressing"
               xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
               xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"
               xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070827/9cf79e34/attachment-0002.htm>