This was discussed as the last IIW (see http://self-issued.info/?p=256). The
point of view taken was there are a number of things being introduced that will
be incompatible with OpenID 2.0 by definition, such as OpenID identifiers using
e-mail syntax. Likewise, there are things that are believed to be broken, such
as having two different specifications for delivering attributes (both
optional!).
The consensus was that we'll end up with a cleaner and easier to implement spec
if we don't require backwards compatibility. Just like SAML 2.0 is related to,
but not compatible with SAML 1.1, we expect OpenID v.Next to be related to, but
not compatible with OpenID 2.0. And reusing the SAML analogy, it's common for
installations to support both SAML 1.1 and SAML 2.0 for a transition period
while their partners migrate to SAML 2.0. I expect that a similar migration
strategy to be employed by OpenID installations, in cases where backwards
compatibility is important.
Per the last OpenID summit, there's a reason why RPXNow has custom code for
every major OP. It's a goal for v.Next to make that unnecessary...
-- Mike
From: Paul E. Jones [mailto:[email protected]]
Sent: Monday, May 10, 2010 4:57 PM
To: Mike Jones; [email protected]; [email protected]
Cc: [email protected]
Subject: RE: Draft charter for v.Next Attributes working group
Mike,
Not knowing what discussions took place that led to this decision, I must say
this sounds a bit scary. We're seeing an increase in the adoption of OpenID,
but loss of backward-compatibility seems like it would create quite a problem
in trying to gain further adoption. Software all over would have to be
upgraded (which would take time and never happen all at once) and users would
be left wondering when OpenID might or might not work.
I really wish compatibility with OpenID 2.0 would be a definite goal.
Paul
From: Mike Jones [mailto:[email protected]]
Sent: Monday, May 10, 2010 5:45 PM
To: Paul E. Jones; [email protected]; [email protected]
Cc: [email protected]
Subject: RE: Draft charter for v.Next Attributes working group
It's a statement about v.Next overall.
-- Mike
From: Paul E. Jones [mailto:[email protected]]
Sent: Monday, May 10, 2010 2:42 PM
To: [email protected]; [email protected]
Cc: [email protected]
Subject: RE: Draft charter for v.Next Attributes working group
Joseph,
This sentence troubles me a little:
"Compatibility with OpenID 2.0 is an explicit non-goal for this work"
If users have the right to control what (if any) attributes are exchanged, then
it seems to suggest they could refuse to convey any, in which case there ought
to be a high-degree of interoperability with OpenID 2.0.
Can you elaborate on what that sentence really means? Is this a generate
statement about v.Next (i.e., the larger team is not interested in preserving
backward compatibility), or is this a statement applicable only to this WG?
Paul
From: [email protected]
[mailto:[email protected]] On Behalf Of Joseph Smarr
Sent: Monday, May 10, 2010 2:09 PM
To: [email protected]
Cc: [email protected]
Subject: Draft charter for v.Next Attributes working group
Hey guys, I volunteered to drive the "attributes" working group for OpenID
v.Next, so here's a proposed charter, feedback welcome. Thanks to Mike Jones
for actually writing up the first draft and getting me to act on it! :) js
(a) Charter.
(i) WG name: OpenID v.Next Attributes
(ii) Purpose: Produce attribute transmission and schema
specifications for OpenID v.Next that address the limitations and drawbacks
present in the OpenID 2.0 attribute facilities that limit OpenID's
applicability, adoption, usability, and interoperability. Sharing basic data
about the user has become a common enough requirement that OpenID needs to take
a more hands-on role in specifying common fields and also more tightly/actively
working on how to propose and accept new standard fields going forward.
Specific goals are:
* define how to ask for and get rich, consistent, common and extensible data
attributes,
* define schemas for common attributes,
* define a mechanism and process for using attributes not in this common set,
* enable user control over what attributes are released,
* enable aggregation of attributes from multiple verifiable attribute sources,
* enable the use of attributes by non-browser applications
* enable the use of attributes both with and without employing an active client,
* seamlessly integrate with and complement the other OpenID v.Next
specifications.
Compatibility with OpenID 2.0 is an explicit non-goal for this
work.
(iii) Scope: Produce a next generation OpenID attribute
specification or specifications, consistent with the purpose statement.
(iv) Proposed List of Specifications: OpenID v.Next Attribute
Transmission and Attribute Schema specifications and possibly related
specifications.
(v) Anticipated audience or users of the work: Implementers of
OpenID Providers, Relying Parties, Active Clients, and non-browser applications
utilizing OpenID.
(vi) Language in which the WG will conduct business: English.
(vii) Method of work: E-mail discussions on the working group
mailing list, working group conference calls, and face-to-face meetings at the
Internet Identity Workshop and OpenID summits.
(viii) Basis for determining when the work of the WG is completed:
Work will not be deemed to be complete until there is a consensus that the
resulting protocol specification or family of specifications fulfills the
working group goals. Additional proposed changes beyond that initial consensus
will be evaluated on the basis of whether they increase or decrease consensus
within the working group. The work will be completed once it is apparent that
maximal consensus on the draft has been achieved, consistent with the purpose
and scope.
(b) Background Information.
(i) Related work being done in other WGs or organizations: OpenID
Authentication 2.0 and related specifications, including Attribute Exchange
(AX) and Simple Registration (SReg). ICF Schemas working group. Portable
Contacts.
(ii) Proposers:
Joseph Smarr, [email protected]<mailto:[email protected]>, Google (chair)
Additional proposers to be added here
(iii) Anticipated Contributions: None.
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
