[OpenID] RP Discovery

[Peter Williams]

> > (c) Let's assume that NONE of the RP websites in some single realm
> > HOST THEIR OWN OPENID ENDPOINT. Rather, they "offload" a common
> > token-accepting endpoint (per realm) to a central server, acting for
> > all the resources in the realm.
> 
> One may *have* to assume that; because I can't see how you could host
> an
> arbitrary number of protected resources, without either providing
> dynamically-generated XRDS, or alternatively having a "smart" endpoint
> URL that already knows where the user wants to go. But the latter
would
> involve maintaining even more state at the RP, which I'm pretty sure
> isn't what's intended (it's supposed to be straightforward to overlay
> OpenID on an existing website).
> >
> > We have to remember this is an identity2.0 spec, and think like the
> > designers. It's supposed to be paradigm-shifting!
> 
> Evidently I am finding that kind of thinking something of a challenge.

[Peter Williams] 

Standards tend to be a hodge podge of the folks who get together to form
them. The best ideas, that define the camel. Each has a motivation.



The SAML2 spec is a bit different, as it is dominated by Scott Canter's
incredible clarity of expression, when writing. And, his dogma. The two
tend to go together.

OpenID is the cultural-opposite of SAML2 - take the experience of what
it took to PRACTICALLY succeed with SAML2 within those dogmatic
constraints, and then run with the best bits. Now you have finally
identified the best bits, you can even drop the dogma, entirely. Swap
the dogma furthermore, for the openness hypothesis of web2.0/interne2.0
- where EVERYTHING is only a mashup.

(I'm deliberately using story telling to make the point, rather than
declarative statements that the examiner would prefer. That's the
point.)


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


I remember SAML when it was its early stages, 5 years ago. I ignored it;
in fact, I disparaged it. It looked like a client cert, in a XML string.
Said I: if SSL client certs don't a-have what it takes to be a-doptable,
a-changing the en-coding to a string ain't gonna make na'w difference.

I changed my mind a year ago. 

4 years later, someone had invented the "SAML offloading" pattern. Now
SAML protocols (with all the wonderful engineering clarity of late model
SAML2) spoke for themselves, in a package I could easily _deploy_ on a
large sscale. Rather than my website(s) worrying about SAML, there is a
handshake between my websites (plural) and MY SAML server (which then
speaks SAML to my business partners). My 1 SAML server speaks for my 120
realty listing web sites. Think of it as a multiplexor!

OpenID has the same concept. 1 XRDS per "resource" domain, fronting n
resources which are subordinate URLs satisfying the URL pattern of the
"resource" descriptor.

Of course, that OpenID/SAML "offloading server" speaking for 120 of my
RP websites shall only speak unto another OpenID/SAML server on the OP
side of the fence, which can itself be acting for several legacy
websites that *could* have been OpenID-enabled directly -- but rather
chose to offload to their responsibilities to THEIR centralized
offloading (OP-side) OpenID server.

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

If another metaphor helps.... in 1993, every corporate LAN conformed of
100 IT systems still only had 1 EDI gateway, regardless of how many
ANSI/EDIFACT EDI flows were passing across the two EDI gateways facing
each across the B2B interworking space. The EDI gateway was a
multiplexor (using message handling protocols). If you could not manage
operations of your own EDI gateway, you might even have outsourced it to
edi-signon.com, run by Sprint/GEIS/AT&T.

Of course, the internet had blown that model away, by Aug 1994.

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


Now we are not discussing protocols or benefits here; we are discussing
"methods" of __effectively__ making a standard solve a problem, in real
world operating theatres. That means patents.

As someone else already said, the big IT companies all have patents on
these patterns - framing the potential market.

Before any one of them allows the other to leverage its patents, silicon
valley IT companies do a backroom deal - that allows each of them to
share the market that results. Often, the deal is brokered by the
venture capital community.

VeriSign was itself the perfect case of this. By the time of its
corporate-round of startup funding on 1996, it was in reality just a
deal between VISA, AT&T, HP, Cisco and Microsoft - to split the PKI
market so they all had the share they wanted. Then, they pooled the IP,
and allowed VeriSign to fly as their front company - via  investement
instruments such as the Microsoft warrants we imposed on Microsoft.
(Another partner was US Federal govt, which got what it wanted, too. NSA
didn't pool its patents, it pooled its accord to release us all from the
COCOM crypto-regulation -- but only when VeriSign and the other silicon
valley companies agreed to facilitate the (legal) spying business.)

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

Nothing happens in _viable_ and _marketable_ US IT security standards
for the technical reasons stated in the spec!