[OpenID] Continuous OpenID

[Peter Williams]

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