[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