[OpenID] Verisign Announces Free OpenID Digital Lockbox

[Peter Williams]

The cascade can be as long as reasonable engineering limits allow.

For a 2 level OP cascade (where the ultimate OP is really acting as a ticket-granting-ticker issuer to the OAUTH-consumer), the architecture is essentially identical  in engineering limits to what MyOpenID does today:


1. goto RP, type in openid
2. RP calls back to MyOpenID using redirect binding
3. MyOpenID OP calls back [further] to cardspace STS using ws-federation binding (whatever happened to the community work replacing the ws-fed binding?with openid auth?)
4. cardspace/openid returns STS claims to MyOpenID OP
5. MyOpenID does claim transformation (ue., change a few names around, and rewrite value syntaxes) returning assertion to RP.
6. RP consumer assertion.

Or in firmware design, a simple 2 level interrupt handler :-) Or in Unix, a 2 level signal handler... in your bourne shell scripts...

The beauty of rp-initiated flows as used in SAML & openid auth is that each event handler gets to switch further upstream, IF it wants (and it does it transparently). In MyOpenID's case , they optionally cascade upstream to a cardspace STS, which MAY cascade up further to Kerberos, which MAY cascade upto ...all of which then unstack on the return leg doing n claim transformations... to finally land on the desired service.

The trick is now to add user-impersonation-tickets for consumption by RPs, so they can mashup with additional data sources that are not _necessarily_ "controlled" by the OP performing the original _user_ auth.

> -----Original Message-----
> From: SitG Admin [mailto:sysadmin at shadowsinthegarden.com]
> Sent: Saturday, February 21, 2009 2:33 PM
> To: Peter Williams
> Cc: general at openid.net
> Subject: Re: [OpenID] Verisign Announces Free OpenID Digital Lockbox
>
> >Using one OP as an authenticator for another OP is really only a
> >variant of what MyOpenID does today (where SSL client certs or
> >cardspace assertions) can be used to user auth to the OP. Rather
> >than a cascade of cardspace assertion -> openid assertion ...I
> >simply advocated using a cascade of openid assertion -> openid
> >assertion.
>
> SSL certs can be cached, though (and only checked for revocation
> *occasionally*), whereas OpenID exchanges cannot. How far can the
> cascades go? How long will the user be waiting, sitting patiently at
> their computer, waiting for an attempted login to go through?
>
> -Shade