[OpenID] CX proposal status

Fri Jan 16 03:09:39 UTC 2009

Peter,

I think that after the edits the proposers made on their telecon today (that
unfortunately none of the Specs Council members could attend, though there
wasn't much notice), the OpenID CX (Contract Exhange) charter has now been
scoped tight enough - into a single spec - and defined clearly enough that
it should address any concerns raised by the Spec Council. Whether the final
spec is approved by the community as an OpenID specification is of course up
to the community, but the job of the Specs Council - to make sure the work
meets the basic requirements of being something relevant to the OpenID
community, should now IMHO be a no-brainer.

The proposers are having a telecon with the Specs Council next Thursday that
should conclude the review process. I think this shows that we are slowly
working the kinks out of the OpenID WG process and that we should start
getting progressively faster and smoother and - please God - lighter weight
as we move forward in 2009.

=Drummond 

  _____  

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Peter Williams
Sent: Thursday, January 15, 2009 3:32 PM
To: Nat Sakimura
Cc: general at openid.net
Subject: Re: [OpenID] CX proposal status

I suspect this class of issue is quite important to the specs council
members. But.I'm not speaking authoritatively! The power in such decision
making is always function of who pays the bills!

Of course, there is not a single thing that openid does that other protocols
don't already accomplish  (typically using xml ,dsig and https). But, like
any standards-based product, what matters is not the pure function but the
unique design concept that builds an online community operating a "certain
way". UCI-openid and Shib-SAML could not be more different in operational
concepts, despite having the same functional output.

I suspect spec council people will want the trust networking topic addressed
according to "the openid philosophy". It has to smell like web2.0 in its
culture, not like the kind of material that OASIS (or IEEE) would typically
generate. It also has to avoid smelling like a W3C standard, which tends to
be too far out (like the half billion FOAF files that exist. but no one
uses). Though unstated, any design  may have to avoid "that" which induced
openid in the first place (being merely the nth websso protocol to come out
of the gate in recent years).

The way the high-level criteria are structured suggests that it's a
defensive posture and fundamentally a political process - which will require
canvassing the council members rather than rationalizing the content. Its
rule system design pretty obviously allows the "founders" to hold further
developments true to the founding spirit as they see it - and they get to do
that outside of membership control, with no formal accountability ; needing
only to claim they are upholding the "vision".

From: Nat Sakimura [mailto:sakimura at gmail.com] 
Sent: Thursday, January 15, 2009 3:03 PM
To: Peter Williams
Cc: David Recordon; general at openid.net
Subject: Re: [OpenID] CX proposal status

Well, to be clear, I am not proposing to rubber stamp on JAL implementation.

That's fairly different than what we would come up. 

For example, JAL implementation actually uses XML contract format with XML
Sig. 
I actually prefer that, but I was guessing that this community would want
something not XML nor XML Sig. Of course, if the community wants XML+XMLSig,
I am more than happy. 

It is just the use case from JAL implementation that I am bringing in. 

=nat

On Fri, Jan 16, 2009 at 2:29 AM, Peter Williams <pwilliams at rapattoni.com>
wrote:

I'm guessing culturally, that there are a number of things that need to get
dropped.

The notion of "use-case driven" WG needs to go. I doubt we want to introduce
a distinction between those outputs that are engineered using use-case
methods vs those that are not. Use of one or other method is incidental, and
neither supports or limits the technical work. The WG members should pick
one or more once engaged. There is nothing in a "charter" that has to decide
this issue upfront. (otherwise, it smacks of religion, that introduces
politics,  that induces worry.. that causes delay.).

The notion of that the particular topic (higher assurance protocols for
trust network) demands certain (Security) engineering techniques (e.g.
crypto and signatures) should also go. The WG might want to decide to adopt
an existing apparatus, tune commodity infrastructure (e.g. PKI), posit 2
levels of OPs (just like in IS-IS or OSPF enterprise backbones),.

One should be clear that no additional "profiling" will be required for
interworking. I'm not sure this culture want to adopt the market
fragmentation attitudes present in the SAML adoption space for example. We
have to  remember this is the web, focused on consumers (not B2B). B2B is
secondary, and must be an "overlay" on  the consumer  infrastructure- much
like military folks overlay additional trust on _Commodity_ SSL when needed.

It's an important step for Openid to frontally address trust networking (as
Nate has headed for a year now). But, the charter needs to generic and open
minded, not a rubber stamp of whatever works at JAL today. At the same time,
it needs a practical orientation, so the debate doesn't just become a tech
vendor-fest - each wanting their own stuff to get adopted to help their
mindshare marketing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090115/815b3633/attachment-0002.htm>