[OpenID] RP Discovery

[Peter Williams]

> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net]
On
> Behalf Of Jack
> Sent: Friday, August 31, 2007 12:33 AM
> To: general at openid.net
> Subject: [OpenID] RP Discovery
> 
> Hi,
> 
> Draft 12 of the Authentication spec says that an OP SHOULD verify the
> RP's return_to by means of YADIS discovery, and SHOULD NOT send a
> positive assertion unless this succeeds.
> 
> I must have misunderstood something; this seems broken. For example, a
> user follows a link that would lead to a protected resource at the RP,
> so the RP challenges. Successful authentication should take the user
> directly to that resource. Suppose there are many such resources? For
> example, if the entire site is protected, any URL at the site might be
> a
> valid endpoint. Must the RP publish every URL on the site in the XRDS?
> 
> Suppose that the URLs of those resources are dynamically-generated?
> 
> --
> Jack.
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general


[Peter Williams] 

That got me thinking, and re-reading. The document is more interesting
the more I read it, as it's an inverted spec. You can determine its
scope by seeing the possible relationships between its various
procedures. Very web2.0/RDF :-) Its scope is that which results from
some bundling of the functional units of the protocol, unlike SAML2.o
whose spec is specifically use-case driven. Furthermore, it
self-extending/self-describing.

[Silly aside. One can see on those grounds alone why there would be a
culture clash between SAML/liberty and OpenID! It's like two different
software engineering schools: Stanford(SAML) vs MIT(openid) -  a
distinction which nicely parallels the culture clash between IETF and
W3C) ]

(a) The realm matching rule has the same issue of # vs. fragment ids, as
we discussed in the other section. Easy fix, too.

I had not realized (as I have not read the reference implementation code
for this pending-final OpenID Auth 2.0!!) that all consumers shall now
have an XRDS file. Its mandatory.

(b) Mandatory RP discovery does make sense tho. If you are going to base
assurance properties of a handshake on secure name resolution, you want
that resolution both ways - so you can confirm the properties of the
intended token-recipient (before you release the sensitive value).

ON Jack's point, it perhaps not as many XRDS document as it might imply.
It's one per return_to; not one per token-using party behind that secure
endpoint

(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.

We have to remember this is an identity2.0 spec, and think like the
designers. It's supposed to be paradigm-shifting!

(d) offloading security endpoints to a central server is something that
of course we saw happen in the shift from SAML1 to SAML2. Rather than a
website add the SAML1 handlers of sourceid.org, the website cooperate
with a SAML2 server (via _some_ or other  "offloading" mechanism)  The
shift from OpenID1 to OpenID2 parallels that, in ways I had not
realized. I get it, now you point it out.

The nice thing about that property of SAML2/OpenID2 is that the
centralizing endpoint means that the OP proxying and RP proxying use
cases all come into play. You can build chains of handoffs. Want a
token? Go beg an OP for one! ... where that OP asks for a token from an
upstream OP... not that you know the RP know that fact. (This parallels
my earlier OP/IDP-gatewaying experiment of using SAML to fulfill an OP
TokenRequest, where then my SAML server only then asked ASP2.0 to
discover and have its login form fulfill the request... which asked
cardspace to do its thing, which asked an STS....which asked another
STS....  Then reverse path, of course, for which an OpenID hop REQUIRES
YASID discovery.)


Anyways, getting back on topic: The same can happen with realms on the
return_to path. 

Cute.


(e) "If neither value is present, the assertion is not about an
identifier, and will contain other information in its payload, using
extensions (Extensions)."

Once one has the token passing protocol, managed possibly by two
offloaded OpenID servers working for their respective OP "legacy
website_s_" and RP "legacy website_s_" ... the tokens need not be about
identity, as the document CAREFULLY points out.

(f) association formation, via DH, is suspiciously weak, in OpenID1.0. 

For designers of this class, this does not make any sense. These guys
are not dumb, and have clear secure protocol design experience. But,
they are specifically not using standard security engineering practices
or writeup formulas - probably because of the identity/2.0 hypothesis.
Yet the spec, is inordinately precise in critical ways, the more I look
at it. You'd have to invert the pyramid and do things assbackwards - to
get what web2.0/rdf/identity2.0 is really all about, especially if you
are aiming to bring down the SAML dinosaur with just a pointed stick.

As we see in some of the proposed standard extensions for OpenID 2.0,
token passing using the property of (e) can be about sharing DH keys...
etc to distribute the keys with assurance - so associations derived from
the key agreement are on a sound footing. For all we know, in the
future, further specs could leverage the token passing to be a complete
re-implementation of the entire IKE v2 flow.

(g) SSL is only a handshake, and a set of control procedures.

If you view OpenID 2.0 Auth and its various extensions now as a toolkit
of token-passing procedures, can one imagine building now a complete
secure handshake from bundling of those token-passings?

Yes, I can see this in the architecture IMPLIED BY the spec, now.

You have to look at OpenID Auth2.0 req/resp itself as the equivalent of
the SSL record layer protocol - a connection or connectionless bearer
with framing and security context management.

Then you look at each token-specific leveraging of (c) as each of the
various SSL handshake phases. E.g. (1) do the session handling. (2) do
the key agreement. (3) handle key wrapping controls (4) control
finalization. (5) use session keys to apply flow controls now to any
application-layer secure flow.

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

Ok. I like this all the more.

Now I can see what Microsoft is upto. And, that explains the patent
negotiations within the silicon valley club.

There had to be something driving THAT DEGREE of manipulation of the IP.