[OpenID] ANN: OpenID Information Cards spec and workingimplementation

Gerald Beuchelt beuchelt at sun.com
Tue Aug 28 19:03:13 UTC 2007


Johnny -

If I am reading this correctly, then (one of) the biggest difference 
between a SAML payload and an OpenID token is that additional 
user-specific communication between the RP and the OP/STS (in accordance 
with the OpenID specs).

This seem to me as breaking Kim's laws on Directed Identity and 
Justifiable Parties, by allowing the OP/STS to create a log of visited 
RPs. I know that that is not necessarily a problem within OpenID 
(especially if you run your own), but the Infocard model - and 
especially the Windows CardSpace UI - were designed with most limiting 
disclosure in mind. This has started to sink into the collective 
mindset, so that every time a user participates in the "Infocard 
ceremony" the expectation is that the IdP will not be able to correlate 
RP visits.

If the OpenID token changes this kind of behavior, this should be very 
clearly indicated to the user before he/she can use it.

The other problem that I still seem to have with this spec is that I do 
not exactly see what benefits over SAML it really has.

Thanks,

Gerald

Johnny Bufu wrote:
>> 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.That's the general OpenID approach. The flow we're proposing is  
> "OpenID wrapped into Infocard".
Which is somewhat different from the Infocard model where the STS does 
not necessarily know about the RPs the User visits.
> 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).
>   
This makes them - from a trust perspective - essentially a single entity 
with different access modes, yes?

> However I don't think the modified flow we're proposing changes the  
> trust relationships:
>
> - the RP trusts the authoritative OP for the OpenID it receives
> - 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)
>   
You should probably add that the User has to trust the OP/STS to not 
correlate data from its logs.



More information about the general mailing list