Hi Peter,<div><br></div><div>In response to:</div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><span class="Apple-style-span" style="color: rgb(31, 73, 125); font-size: 15px; ">What we get from the architecture is immunity from the assumptions the library designer has made in how he/she architected support for multi-tenant processing. DNOI is very web.config centric, from what I understand, being a "native" .NET concept. </span><br>
</blockquote><div><br></div><div>Not to be too defensive of the library, I hope, but I'd like to suggest two counter points to your above statement. First, DNOI only recently added support for reading settings out of a web.config file. By design everything that can be done in a .config file for DNOI can also be done programmatically. In fact, DNOI can even be used quite easily on a backend server without using <a href="http://ASP.NET">ASP.NET</a> at all. If you still have concerns in this area I'd love to hear them.</div>
<div><br></div><div>Secondly, on the Provider side DNOI deliberately stays completely away from making decisions that the host site's policy works. All DNOI asks the host site is "this user claims to be X. Do you agree?" and the site can decide to go through whatever process it wants to determine that, and just answer DNOI's question (which may be much later, after redirects, or dialogs popping up, or whatever). So again, if you can think of a scenario that DNOI doesn't handle because I've architected it too much, or the wrong way, etc, I'd love to hear about it. I definitely want to make this library work for as many people and scenarios as possible.</div>
<div><br></div><div>Cheers. :)</div><div><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">On Wed, Jan 7, 2009 at 3:08 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p><span style="font-size:11.0pt;color:#1F497D">One thing that is VERY appealing about myopenid's domain service
is that it has a last mile + offloading architecture. This matches what
we do today, with SAML-offloading to a websso switch (that we happen to operate
ourselves). I find myself comparing that with investing in DNOI.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> If I look at openid as just another websso protocol, Id be
very tempted to want to talk to a websso switch that does openid auth and ax,
similarly. Ideally, the websso switch would support both protocols (saml2 and
openid), but the nature of switching with url-based routing is that if no such
box exists… its trivial to add yet another forwarding point, which routes
to different switches for different websso outputs. While oneis switching/routing,
of courselots of value-add can be being added (security of deep packet
inspection firewalls with the ability to parse the URLs and HTTP flows at
wirespeed, for example).</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">Think of it as policy based routing for IP, now with URLs. Depending
on the traffic policy (I want high priority treatment for my voice traffic, and
security over a MPLS VPN), the ip packet is routed to gateway X rather than Y. In
the websso world, that translates as: consider the destination endpoint for
websso recovered from metadata; now uses url-routing (rather than IP) as the basis
for routing/forwarding decisions that invokes the right protocol at the local edge
of the network. As the assertion passes across the openid core (or the
saml core),it exits the core at edge switch targeting the SP. At that point, it
gets switched locally, perhaps ending up as an <a href="http://ASP.NET" target="_blank">ASP.NET</a> session with a FormAuth capability
added for support.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">What we get from the architecture is immunity from the assumptions
the library designer has made in how he/she architected support for
multi-tenant processing. DNOI is very web.config centric, from what I understand,
being a "native" .NET concept. As a very large site also using Microsoft
.NET, we are not - intentionally so. Thus native integration with DNOI is not
appealing. If I had DNOI in a box, to be invoked with URL routing, I suspect it
would be appealing. That box could be operating be on our site, sit in a SAAS
location at an intermediate system endpoint, or be on a deep space probe with a
30m transmission delay . Obviously, the security of the routing/switching is
important; and more difficult to achieve (particular when delays get more extreme)
than architectures in which the endpoints are co-located with the server block…
and sit within the block's own protection boundary.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<p><span style="font-size:11.0pt;color:#1F497D">What AX is missing is stronger metadata, that allows the
offloaded switch to easily configure itself with its data sources. While XDI
might be intended to ultimately play that role, it tends to be seen as a control
framework for the interaction of flows between parties , rather than be merely a
convenient/optional repository of ax metadata that works across all vendor
websso swtiches.</span></p>
<p><span style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt">
<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a> [mailto:<a href="mailto:general-bounces@openid.net" target="_blank">general-bounces@openid.net</a>] <b>On Behalf Of </b>Andrew
Arnott<br>
<b>Sent:</b> Tuesday, January 06, 2009 7:23 PM<br>
<b>To:</b> Martin Atkins<br>
<b>Cc:</b> <a href="mailto:general@openid.net" target="_blank">general@openid.net</a><div class="Ih2E3d"><br>
<b>Subject:</b> Re: [OpenID] Myopenid ax</div></span></p>
</div>
</div>
<p> </p>
<p style="margin-bottom:12.0pt">DotNetOpenId supports the full
AX extension, FWIW. Any OP that runs DNOI should be able to easily add
full AX support, including arbitrary push as well as fetch.</p><div><div></div><div class="Wj3C7c"><br clear="all">
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire<br>
<br>
</div></div><p></p><div><div></div><div class="Wj3C7c">
<div>
<p>On Tue, Jan 6, 2009 at 5:02 PM, Martin Atkins <<a href="mailto:mart@degeneration.co.uk" target="_blank">mart@degeneration.co.uk</a>> wrote:</p>
<div>
<p>Peter Williams wrote:</p>
<p>Delegate was probably the wrong term. Host a "private
label op", would probably be a better term, borrowing from the world of
hosted pkis. Myopenid has evidently built a multi tenant op, from what I can
tell, much like we did in mls land: one sass pool of server side functions:
100+ configurations - one per tenant.</p>
<p> </p>
</div>
<p>Okay, I understand what you mean now. I don't think we
actually have a term for an OP that provides service in "your
domain", so "private label OP" works, or perhaps "OpenID
for your Domain" to steal the Google/myOpenID branding. :)<br>
<br>
So I guess what you're looking for is an OP that:<br>
<br>
1. Provides OP services for an arbitrary, user-provided domain.<br>
<br>
2. Fully supports AX<br>
<br>
For 1, the only provider I know of is myOpenID.<br>
<br>
For 2, I know of no provider.</p>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p style="margin-bottom:12.0pt"> </p>
<p style="margin-bottom:12.0pt"><br>
Pbwiki as a sp are obviously trying to go the same way, but I suspect their
openid integration was not designed for the multi tenant model (from my trials,
with <a href="http://wiki.openid.net" target="_blank">wiki.openid.net</a>).</p>
</blockquote>
<p> </p>
</div>
<p>As far as I'm aware, Pbwiki is only an RP, not an OP.<br>
<br>
Even if they do act as an OP somewhere, I'd expect them to do it in the <a href="http://pbwiki.com" target="_blank">pbwiki.com</a> domain rather than on,
say, <a href="http://wiki.openid.net" target="_blank">wiki.openid.net</a>.</p>
<div>
<div>
<p><br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a></p>
</div>
</div>
</div>
<p> </p>
</div></div></div>
</div>
</div>
</blockquote></div><br></div>