Draft charter for v.Next Attributes working group

[Paul E. Jones]

Mike,

 

The OpenID spec isn't that hard to read.  It's a fairly straight-forward
protocol.  There are a few places in the text that made me scratch my head,
but it was primarily due to the fact that it was the first time I read
through the document.

 

Adding support for email-style addresses is something I like, but something
that can be provided via webfinger.  Thus, no change to the base protocol.

 

I really like the idea of being able to provide a lot more information,
which could be done through artifact binding.  That would require an
addition to the protocol, but would not necessitate a change that would
break backward-compatibility with the base 2.0 spec.  Further, I think that
addition, if done right, might address the issue with long URLs and future
requirements for various pieces of metadata.

 

I am curious about the interop issues with various OPs.  But, given how
trivial the base OpenID spec is, it seems like we ought to be able to
identify the faulty implementation and fix it without declaring the need for
something entirely different.

 

I appreciate you sharing the details with me, but I still feel a bit uneasy
about breaking backward-compatibility. :-(  I wish there was a way to avoid
that.

 

Paul

 

From: Mike Jones [mailto:Michael.Jones at microsoft.com] 
Sent: Monday, May 10, 2010 9:46 PM
To: Paul E. Jones; jsmarr at stanfordalumni.org; openid-specs at lists.openid.net
Cc: tech-comm at openid.net
Subject: RE: Draft charter for v.Next Attributes working group

 

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:paulej at packetizer.com] 
Sent: Monday, May 10, 2010 4:57 PM
To: Mike Jones; jsmarr at stanfordalumni.org; openid-specs at lists.openid.net
Cc: tech-comm at openid.net
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:Michael.Jones at microsoft.com] 
Sent: Monday, May 10, 2010 5:45 PM
To: Paul E. Jones; jsmarr at stanfordalumni.org; openid-specs at lists.openid.net
Cc: tech-comm at openid.net
Subject: RE: Draft charter for v.Next Attributes working group

 

It's a statement about v.Next overall.

 

                                                            -- Mike

 

From: Paul E. Jones [mailto:paulej at packetizer.com] 
Sent: Monday, May 10, 2010 2:42 PM
To: jsmarr at stanfordalumni.org; openid-specs at lists.openid.net
Cc: tech-comm at openid.net
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: openid-specs-bounces at lists.openid.net
[mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Joseph Smarr
Sent: Monday, May 10, 2010 2:09 PM
To: openid-specs at lists.openid.net
Cc: tech-comm at openid.net
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,  <mailto:jsmarr at google.com> jsmarr at google.com, Google (chair)

Additional proposers to be added here

(iii)              Anticipated Contributions:  None.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100510/01002ee6/attachment.htm>