[OpenID] ANN: OpenID Information Cards spec and workingimplementation

[Johnny Bufu]

On 28-Aug-07, at 11:52 AM, Peter Williams wrote:
>> 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.

Yes, SHA256 is not an issue from the OpenID point of view. But SHA256  
doesn't seem to be available for infocards.

We are not trying to add more requirements for selectors / Infocard  
specs, but rather make this work with what's available on the  
infocard level. So if there's an issue with SHA1 (you still haven't  
pointed what could actually go wrong if we're using it), the issue is  
infocard-specific, not related to OpenID Information Cards in  
particular.


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


Not sure what you mean here.. Cardspace is an infocard selector  
implementation, so it can't impose restrictions; it's the other way  
around, no?

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


I see this as an artificial issue. If the IdP needs / wants to  
architect it like that, then it should deal with the security / trust  
issues itself. They are not inherently tied to the protocol(s) we're  
proposing, so I'm seeing them out of scope of protocol specification,  
but implementation / deployment specific.

The same would apply if an STS (or OP for that matter) implementation  
would be split up in a dozen (remote) components that need to  
interact with each other. If you look at the Higgins STS architecture  
and imagine the components there scattered around, the same (or more)  
issues would come up.

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


No, because it can't -- the RP doesn't have the OpenID identifier at  
that point.

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


Yes: as part of the verification process the RP has to perform  
discovery on the OpenID identifier in the received OpenID Auth Response.

This is part of the normal stateless OpenID flow, which is mandatory  
for the RPs.


Johnny