[OpenID] guid openid delegate

[Peter Williams]

Has anyone built a very simple OpenID Auth 2.0 implementation in pure
javascript? Something VERY SIMPLISTIC (but conforming) along the lines
of

 

Browser visits https page  - site landing page sets openid session
cookie http>://<client-ipaddress>/URLsuffix - hypermedia https page also
renders ajax-style https iframe postback to browser - the ajax
javascript in browser sends id_res (immediate, unsolicited) with null
association (over SSL) - postback script handler handles verifies id_res
(no AX attributes) . postback send window-create Javascript and
server-side authorization cookie - browser creates popup instance on
target site.

 

 

Analytically, the above seems to be a legal flow. SP is relying on SSL
nonces. SP is relying on SSL discovery of the OP. SP is relying on SSL
association setup/teardown. SP relies on the ephemeral SSL DH
ciphersuite. SP has controls selection of its DH certificate and thus
the generator

 

On the client side UCI implementation relies on https trust in server
site (e.g. EV certs). UCI then relies on EV assurance so site is trusted
to send ajax javascript GUI that properly allows user to decide whether
or not to allow release of id_res asserting control of the (possibly
NATed) IP address-based OpenID.

 

From: Peter Williams 
Sent: Wednesday, September 12, 2007 3:34 PM
To: Peter Williams; general at openid.net
Subject: guid openid delegate

 

guid:27AC90D2-14EC-45C3-8B34-690CFA378D1B-0

 

Summary: 

 

As RDF models often cite guids in their ?P ?S ?O triple models, allowing
delegate identity to have the guid URL form allows OpenID to nicely and
"natively" integrate with a RDF-based query processor - that uses a
semweb fulfillment of local user auth and attribute resolutions.

 

 

 

Nothing in the text of OpenID Auth 2.0 #12 obviously makes a delegate
OpenID of the guid form (above) be non-conforming.  A Guid URL can then
be presented as a Claimed_ID, in checkid_immediate for example.

 

The flow Im intending to leverage shall have the following form.

 

1.       User visits page on IDP, which links (with querystring =
<openid>) to page on RP site - which when rendering a public landing
page also renders iframe to OpenID Consumer (serving to obtain login
session credentials via OpenID). 

2.       Consumer visits IDP's HTML/XRDS resource to learn IDP's
dynamically generated delegate URL (guid:...)  and OP endpoint. Consumer
presents check_id immediate to OP endpoint, citing the delegate guid
URL.

3.       If the OP endpoint cannot recognize the guid, the sends back
id_res error (converting immediate into setup for that guid, for
example, to let IDP explain the error).

 

As far as I can tell, the above is an expected and "as-intended" flow in
the protocol.

 

As RDF models often cite guids in their ?P ?S ?O triple models, allowing
delegate identity to have the guid URL form allows OpenID to nicely and
"natively" integrate with a RDF-based query processor - that uses a
semweb fulfillment of local user auth and attribute resolutions.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070913/0c12f0ee/attachment-0002.htm>