[OpenID] ANN: OpenID Information Cards spec and workingimplementation

[Peter Williams]

Longish mail! Be warned. 


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

Can you detail why, or give me a hint on a better approach (ideally  
supported by the infocard layer, of course)?

---- There seems no reason not to use SHA256 at this point. This is new
OpenID feature, and thus no legacy interworking worries should control.
I don't know however if practical windows/cardspace limit us to SHA1. I
was assuming that some OpenID specific dll would be added to cardspace,
to implement the specified referencing scheme. Thus the spec could
control the choice of math.







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

Yes - that's what we have in our implementation :
/TokenService/* for the Higgins STS
/op for the OpenID Provider endpoint

--- It will at least 2 weeks before I build a [demograde]  STS to do
this. I have to make my STS endpoint to go get SAML2 WebSSO tokens (by
initiating its own SAML2 BROWSER SP-redirect session ), get PAOS tokens
(assuming my SAML server vendor will cooperate), and also then get the
new OpenID token.

Hopefully, the MSFT demo-grade code from the Microsoft Press WCF book is
reasonably complete in its implementation ws-federation active. If there
are any cardspace profiles/bindings imposed on ws-fed, let me know; we
need them spec'ed, on the wiki. This would be a traditional
Microsoft-ism.







> (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

True, and that's what the OpenID Higgins token extension does in our  
implementation. The stateless verification functionality / endpoint  
is not baked into the STS itself, though it could be done.

The STS and the OP do need to share the secret (private association)  
used by the former to sign the issued OpenID Auth Responses (so that  
the OP can actually perform the verification when the RP comes asking).


--- So here we differ a fraction, I worry. I had ASSUMED this is what
you were doing, but only as one implementation. The general case is that
the verifying OP and the STS-for-OpenIDTokens were different AND DO NOT
SHARE an association store.

--- if you look again at the phrasing of (iii) the STS may need to
"support" a remote OP performing Verification. Support means something
like....the OP and the STS have some private means of auhorizing the OP
to state that Responses issues by the STS are valid, even though the OP
does not have the STS hmac-signing key. Similarly, the STS does not have
the OP's hmac-signing/verifying key for the consumer trustpoint.

-- Assuming some local means now exists, I forsee that the STS can
support such OP but ONLY when SOME control system ensures it can only
offer said support for tokens/responses IT issued. This will require a
secure binding between the Auth Response and the Wrapping Token. From a
given Response absent its wrapper, the STS must be able to securely
identify that it was the issuer of a wrapper, despite not having the
wrapper during verification support. A private hmac-signature in an AX
extension is the obvious means, here; better still a private RSA
signature.









> 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.

Possible, however in OpenID the discovery mechanism is used for this.


-- So I'm not clear from the spec IF the OpenID Consumer sending the
HTML page with object tags for infocards selection SHALL even be doing
HTML/XRI discovery, before sending off that set of page controls to
cardsapce process.

-- Or, is it now expected that a discovery process will occur, upon
receiving the OP Verification of a positive assertion? ... to confirm
the controls?








the STS/OP can be seen as one (trust) entity, though they can be  
deployed separately (but they are still controlled by the same one  
entity, the IdP, which has full control over them, so any trust  
issues between these can be dealt with internally and not exposed to  
the RP or of influence to the protocol flow)


--- Im seeing a world similar to CAs and OCSP responders. Thus, the IDP
MAY and also MAY NOT control both the validating OP and the STS.

--- If the IDP controls both, the SSL certs will make the control
relationship clear - much as a military CA gives notice of its
authorized OCSP responders via metadata extensions in its CA cert.

--- If the IDP does NOT control both, the RP is free to use any OP
verification agent, that may also do such as added value features above
and beyond OP dumbmode verification: manage the consumers wot,
controlling the OP/STS it is willing to rely upon.