[OpenID] Myopenid ax

Wed Jan 7 15:59:25 UTC 2009

Hi Peter,
In response to:

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.

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 ASP.NET at all.  If you still have concerns in this
area I'd love to hear them.

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.

Cheers. :)

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - Voltaire

On Wed, Jan 7, 2009 at 3:08 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  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.
>
>
>
>  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).
>
>
>
> 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 ASP.NET session with a FormAuth capability added for support.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> *From:* general-bounces at openid.net [mailto:general-bounces at openid.net] *On
> Behalf Of *Andrew Arnott
> *Sent:* Tuesday, January 06, 2009 7:23 PM
> *To:* Martin Atkins
> *Cc:* general at openid.net
> *Subject:* Re: [OpenID] Myopenid ax
>
>
>
> 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.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - Voltaire
>
>  On Tue, Jan 6, 2009 at 5:02 PM, Martin Atkins <mart at degeneration.co.uk>
> wrote:
>
> Peter Williams wrote:
>
> 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.
>
>
>
> 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. :)
>
> So I guess what you're looking for is an OP that:
>
>  1. Provides OP services for an arbitrary, user-provided domain.
>
>  2. Fully supports AX
>
> For 1, the only provider I know of is myOpenID.
>
> For 2, I know of no provider.
>
>
>
>
> 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 wiki.openid.net).
>
>
>
> As far as I'm aware, Pbwiki is only an RP, not an OP.
>
> Even if they do act as an OP somewhere, I'd expect them to do it in the
> pbwiki.com domain rather than on, say, wiki.openid.net.
>
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090107/a2cd70f4/attachment-0001.htm>