[OpenID] Verisign Seatbelt "vs" ClaimOP/RP -- OpenID notsoopenanymore?

[Peter Williams]

David

Do not for one moment regard me as anti-VeriSign; I've held financial
interest in VeriSign for longer than the company has had the name
"VeriSign Inc"! Until the VeriSign internal events of today, it spent
10+ years as the ONLY commercial power that prevented internet crypto
infrastructure being subverted against the privavy expectations you and
Joe Public actually have. YOU will help decide what policy is adopted in
the next decade, now SAIC controls the Board. I still gave the highest
moral hopes for VeriSign, in the era of user-centric identity systems.

Here is the summary of what follows, [Peter says:]

"Out of interest, can the https endpoint supplying the magic XML file to
the SeatBelt plugin providing added value in the area of anti-phishing
convenience use a certificate from **ANY** CA? incluing a self-signed CA
created using openssl(1)??



-------
 
One of the moans that many, if not all grassroots, open protocol
initiatives suffer  from - once adoption gets to critical mass levels -
is that major "vendors" work to dominate the community momentum by
adding such as a vendor-unique "extensions". 

Ie. Hint hint, nudge nudge, wink wink, Or... Without the enhancement
(from VeriSign & friends), pure OpenID protocol implemnentations
complying exactly with the spec are really not "commercial grade", or
are "not suitable for us by US government agencies", or "banks..."  They
are missing feature X (where X = "phishing protection")

I'm guessing that Boris comment was of this ilk, hinting via the
"notsoopenanymore" tag that SeatBelt is being 'presented as' an
"enhanced" OpenID implementation providing the "missing" anti-phishing
countermeasures. And, VeriSign did not "seek out or actually 'get'
consensus" before launching its added value initiative.

---------

VeriSign's implementation of the OpenID provider (and its complementary
Firefox plugin) seems to  "add value", from your description:-

OpenID Providers opting in to support the new class of "added value"
shall markup a link rel tag, pointing to an extension configuration
file, in some proprietary XML vocabulary. Presumably, the plugin
processes the XML file, and handles its [discovery] semantics. Thse
semantics control an openID protocol run, directly or indirectly.

(a) is this _particular_ link rel tag convention described in any "open"
spec/standard, draft, proposed, or ratified under the conventions of
this community?

(b) is the concept of extending OpenID by private vendor-communities
described in any open proposed or ratified spec./standard?

(c) is the particular extension specified and ratified by the norms of
this community, in an open spec?

(d) do 2 or 3 implementations exist, which have been shown to interwork?

(e) is there a spec of the XML file's syntax/semantics, that address the
discovery protocol

(f) is there a existing community initiatve to incorporate a IDP
discovery protocol into the core OpenID protocol spec, which this
vendor-initiative pre-empts and with which it shall eventuall merge?

(g) has VeriSign disclaimed its rights to seek a patent application or
assert other IP controls on this particular - or this type of -
discovery protocol for the OpenID protocol?

Further material follows.


-----Original Message-----
From: Recordon, David [mailto:drecordon at verisign.com] 
Sent: Tuesday, May 29, 2007 7:12 PM
To: Peter Williams; Boris Erdmann; general at openid.net
Subject: RE: [OpenID] Verisign Seatbelt "vs" ClaimOP/RP -- OpenID
notsoopenanymore?

Hey Peter,
The SeatBelt is a FireFox extension designed to help with convenience
and phishing concerns around using OpenID.  It makes no changes to any
of the OpenID protocols.  The only "protocol" it uses is a discovery
convention (just like RSS or ATOM auto-discovery) where an OpenID
Provider marks-up a link rel tag pointing to an XML configuration file
for the extension.  This provides the ability for the extension to work
with new providers without requiring any changes or certification
process from VeriSign.  As part of this configuration, the provider
exposes an HTTPS endpoint which returns an XML document about the
current logged in user (or that there isn't anyone logged in).

Just to restate this, we're not doing *anything* which changes the
OpenID protocol(s).

--David



[Peter says:]

Out of interest, can the https endpoint supplying the magic XML file to
the SeatBelt plugin providing added value in the area of anti-phishing
convenience use a certificate from **ANY** CA? incluing a self-signed CA
created using openssl(1)??