[OpenID] ANN: OpenID Information Cards spec and workingimplementation

Peter Williams pwilliams at rapattoni.com
Tue Aug 28 22:49:57 UTC 2007


SO, I think you've hit the nail on the head, speaking as a likely buyer
of OpenID servers acting for about 150 high-throughput websites dealing
with

I think I do want my OpenID server being the thing the cardspace process
talks to. I don't think I want my websites knowing anything about
openid, cardspace+saml, cardspace+openid, SAML, SAML2, Shibboleth,
WebAuth, or RSA cross-domain cookies. 

Whichever one is used, I want the records retention facility storing the
legal data in a common format. I also want per the agreement more or
less of the same legal data available to the IDP - to equalize the
balance of power between initiator and recipient. 

This offloading to a RP-side "Federation Server (with n protocol
support)" is similar in rationale to why we want IDP/OP login portals -
so they insulate the RP website from the vagaries of a M authentication
mechanisms. 

Ideally, the assurance of the IDP's act of user authentication would
come in a standard form - a digital signature on the assertion. But, it
can come from an https ping on a validation server too. The server can
simply store the SSL handshake these days, anyways. It's probably
shorter than a VeriSign certificate chain 

:-)

-----Original Message-----
From: Johnny Bufu [mailto:johnny at sxip.com] 
Sent: Tuesday, August 28, 2007 3:19 PM
To: Peter Williams
Cc: Gerald Beuchelt; OpenID List
Subject: Re: [OpenID] ANN: OpenID Information Cards spec and
workingimplementation


On 28-Aug-07, at 3:11 PM, Peter Williams wrote:

> And yes - when issuing an OpenID Information Card the OP/STS should
> make it clear that it's an "auditing" one (just in case that the
> "auditing" aspect of OpenID is not clear to the Infocard user).


> ---Note to Journalists: a critical difference between OpenID webSSO  
> and
> other schemes is that OpenID requires users always accept the
> possibility that the OP will be auditing.

Not to be mean, but you are implying here that *all* other webSSO  
schemes are *not* requiring the auditing mode. Which I don't think  
it's true and hence the above statement not entirely fair (if it were  
written by a journalist).

>> 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.
>
> What are the benefits of SAML tokens over OpenID tokens? :-)
>
> ... one can sign the assertion using RSA; one can verify using public
> key distribution. One doesn't need the verification via https.

And why is this better? Without more details one could easily argue  
the opposite for the direct verification case.


> ...If the RP is storing the assertion for records keeping, the SAML
> assertion comes with its own integrity mechanism for record retention.
>
> ...In the case of offloading to a SAML2 server, the receiving SAML
> server does both the signature assertion checking (any https checking)
> and the records retention, locally-encrypting the assertions it stores
> in the records retention stores, as required.

And why wouldn't a similarly-featured OpenID Provider (server) do  
exactly the same? These look like nice-to-heave features that are not  
really protocol related.

> ...Remember, SAML distinguished between signing the SAML Response
> envelope vs signing the assertion.
>
> ...Does InfoCard's delivery of SAMLTokens require or permit the STS to
> issue (RSA) signed SAML assertions?


Johnny






More information about the general mailing list