RE: Position Paper for W3C Workshop on Identity

I don't find the openid argument at all convincing (even it its 100
handoffs). Its not a relevant factor. I have every intention of accepting
openid (from google), via the Microsoft ACS bridge for a year (to see if
anyone cares about using Google IDs in real estate, understanding that
Google just exited its real estate business venture, which lost money). That
bridging adds several more handoff steps... and thus the metadata resolution
that assures the endpoint of the bridge adds several more, too. The
connection and packet load on the consumer PC with broadband is trivial
compared to the connection and packet of the average blog page, and is lost
in the noise. (I have 100 logins a minute to process.. and have to calculate
accurately)

In a metadata driven world, its just not relevant to count pings in an
handshake. One accepts that the first token delivered to setup a crypto
session is relatively expensive (and then one uses token caching for
subsequent method calls, based on crypto sessions, as in
ws-secureconversation at layer 7 - or SSL at layer 4). This is what SSL
engineering proved as effective (where the SSL sessionid is just a token).
In the web world, that token is the cookie (of course).

The analysis is not even correct. In openid, to be *assured*, the IDP has to
ping the RP's XRDS file (i.e. impacting my server farm's TCP queue) - to
test from the metadata that the audience is STILL authorized to receive the
IDP's assurance. Then, it has to verify the XRDS endpoint's assurance (using
https cert chain, which means walking the cert chain and pinging the
OCSP/CRL endpoints of each element, in the general case). If DANE was used
instread of OCSP, n UDP pings have to be made against the DNS server
instead... to walk the zone chain(s), which requires n pings against the
root servers.... So the count suggested for openid is not even accurate. Its
not a valid characteristic. 

We are passed scoring points. 


If one wants to compare, discuss the core differences between any and all
websso scheme and their use of metadata for assuring endpoints. The websso
world solves the browser inadequacies by making the browser irrelevant (as
the signaling is site to site, using the browser as a communication bearer,
only). WebiD believes (right or wrong) in the browser as king (not as a
transfer agent between sites). This is what you need to be saying. Whether
or not that argument is convincing... is a different issue.


-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Thursday, April 21, 2011 5:41 AM
To: Kingsley Idehen
Cc: public-xg-webid@w3.org
Subject: Re: Position Paper for W3C Workshop on Identity


On 20 Apr 2011, at 23:08, Kingsley Idehen wrote:

> Henry,
> 
> Very nice!
> 
> Observations re. diagram:
> 
> 1. step #2 is missing arrow (inbound) from "resource server" to Bob's 
> browser is missing re. authentication challenge 2. step #3 is missing
arrow (outbound) indicating what happens after "OK" button is clicked.
> 
> Re. OpenID, accentuating OpenID+WebID will help i.e., implying that OpenID
implementers benefit immediately from WebID. It's less politically thorny
than implying OpenID is inadequate (even though we know it is etc..).

yes, that us because it all happens in 1 TLS connection. 

Is this better?

Received on Thursday, 21 April 2011 13:33:15 UTC