[OpenID] Continuous OpenID

Fri Jan 4 19:33:17 UTC 2008

In many ways, the flow in that Liberty specification seems quite similar (architecturally) to the practice of cardspace.

Speaking in terms of browser sandbox-based flows rather than SOAP binding discussed in the liberty document:-

1. the browser operating in user mode gets a trusted path to the local kernel's cardspace process (invoked via OBJECT tags)

2. within the protected mode NTCB, the cardspace process talks ws-trust with an IDP STS within some NTCB peer, which performs the "discovery" STS role. The use of ws-trust builds/retrieves the token intended for a particular RP site, which is of course controlled by an STS bound to the particular cryptonet policy to which both IDP/RP belong. 

Being a discovery-class STS, any and all tokens have "B3 policy authorization" semantics in addition to authentication/authorization/attribute assertions, showing that all partitioned components of the network TCB (Cardspace process, object resources at target website, IDP STS, RP STS) are controlled by the same, single, central policy domain associated with cryptonet/pki C.pki.)

3. continuing on within protected mode NTCB code, the cardspace process then uses a second run of ws-trust to relay the token to a second NTCP peer (the RP's STS). The latter does the usual attribute name/value mapping of names and syntaxes, re-signining/enveloping the token before its returned.

4. back in user mode, browser obtains the resigned/enveloped token, and sends it to the target resource attempting to obtain a RP session on some object controlled by the policy domain associated with C.pki. This token may have been enveloped, using keying material controlled by C.pki,  for that particular intended recipient, note, so encryption enforces the originator controls - limiting which RP STS can handle the token. This ensures the token is useless even within its notAfter date, if and ultimately when the _untrusted_ user mode browser sends it to the wrong RP website (or the host is compromised)

-----

The only difference between all that and the liberty model seems to be that SASL is playing the signaling and token-transport role of ws-trust, and SASL's inbuilt mechanism negotiation capability is helping the dialogue contextualize what, for whom, and why tokens are being generated (in addition to completing strong authentication of real users).  In the ws-trust case, that policy context for the information flow between entities is presumably determined from the static metadata retrieved from both the IDP and RP STSs. (Unlike the SASL model, ws-trust reliance on metadata allows for joint contribution of entropy and control to the pairwise keying material used when protecting the information flow).

------------

Dont take any of this as gospel: its just speculative analysis - attempting to read between the lines of a rather barren specifications, typically devoid of rationale and context.

________________________________

From: Peter Williams
Sent: Thu 1/3/2008 11:23 AM
To: John Kemp
Cc: Hans Granqvist; openid-general General
Subject: RE: [OpenID] Continuous OpenID

I read the Liberty document quickly. I think it said:

Be a web service client and engage in a SASL dialogue with a token mint to negotiate the type and value of tokens required...for subsequent presentation to a web service provider using SOAP extension headers.

1. when the SASL provider (aka token mint) is a "discovery" service, the concept of operations is openid-like - controlling via a discovery protocol the issuance of authorization to release and use tokens (including crypto session tokens, presumably).  In openid...one says something similar: without completing XRD-based name discovery before openid auth (or after in the cardspace auth case), the RP is not authorized under the policy (controlling this NTCB) to process the token.

2. when the SASL provider is an SSO (rather than the discovery) service, the service does not seem particularly openid-like.

________________________________

From: John Kemp [mailto:john at jkemp.net]
Sent: Thu 1/3/2008 7:49 AM
To: Peter Williams
Cc: Hans Granqvist; openid-general General
Subject: Re: [OpenID] Continuous OpenID

Peter Williams wrote:
> yup - from the blog, you essentially re-invented the artifact mode of
> reliance. Once invoked, RP goes pick up the assertion token from the
> OP, as deposited there earlier .

There's a little more than that though. I also saw an OpenID-like
authentication protocol between the UA and the IdP - something like the
Liberty ID-WSF Authentication and SSO Service
(http://www.projectliberty.org/liberty/content/download/3439/22943/file/liberty-idwsf-authn-svc-2.0-errata-v1.0.pdf)
which is based on SASL (and thus allows several different authentication
methods).

Cheers,

- John

>
>
> I believe the artifact mode is much under-rated - even in the
> practicising SAML community. While the artifact flow itself has pros
> and cons, the dynamics of the underlying token management are what
> are interesting. Reusing tokens, getting yetersdays tokens, getting
> shared tokens, etc etc. are where the opportunities lie. Its a little
> less compelling in openid, where tokens are signed using the
> association channels' HMAC keying (which limits token resolution
> possisbilities, somewhat!), rather than asymmetric keys and dig sigs.
>
>
>
> ________________________________
>
> From: general-bounces at openid.net on behalf of Hans Granqvist Sent:
> Thu 1/3/2008 6:44 AM To: openid-general General Subject: [OpenID]
> Continuous OpenID
>
>
>
> One of my itches with web authentication is the need to enter
> identity info, be it user/pass or an OpenID URL, everywhere I want to
> be identified. So tedious! I should only have to enter it once and be
> done.
>
> There have been a few attempts at solving this by having the browser
> auto-fill fields for you, but that normally only works so-so (and you
> still have to enter the identity info once).
>
> I've tooled around on a version of authentication that:
>
> * Uses OpenID protocol messages. Existing libraries should work. *
> Lets you enter your OpenID URL once and be done. * Removes all
> redirects from the browser. * Continuously logs you in to every site
> (should you so desire).
>
> It's worth noting that the protocol could be simplified on the RP
> side to not use OpenID at the RP at all, which might be good or bad
> for general OpenID adoption.
>
> Have a look at
> http://commented.org/blog/2008/1/3/continuous-openid.html for the
> full protocol. I'm sure the thoughts are not entirely new and that
> the protocol can be improved.
>
> Thanks, Hans _______________________________________________ general
> mailing list general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
> _______________________________________________ general mailing list
> general at openid.net http://openid.net/mailman/listinfo/general