Dear Specs Council Representative:

Here is the Proposal for Attribute Exchange 1.1 Working Group creation.
We have reached the substantial consensus on the scope in specs at
Please review it towards the formation of the WG.

Yours Faithfully,

Nat Sakimura

OpenID Attribute Exchange 1.1 Working Group

Charter Proposal

In accordance with the OpenID Foundation IPR policies and procedures
this note proposes the formation of a new working group chartered to
produce an OpenID specification. As per Section 4.1 of the Policies,
the proposed charter is below.

I. Name

Attribute Exchange Extension 1.1 Working Group (AX)

II. Statement of Purpose

Produce an updated version of the Attribute Exchange (AX) and Simple
Registration (SREG) Extensions. The extensions should be
backwards-compatible with AX 1.0.

III. Scope

Update the Attribute Exchange Extension to include support for the following:

Including parameters in fetch requests.
Including privacy information.
Providing short names for common attributes.

IV. Specifications

OpenID Attribute Exchange 1.1

V. Anticipated audience

All those interested in the obtaining attributes about users
authenticated via OpenID.

VI. Language of business


VII. Method of work

Mailing list discussion. Posting of intermediate drafts in the OpenID
Wiki. Virtual conferencing on an ad-hoc basis.

VIII. Basis for completion of the activity

The Attribute Exchange 1.1 final drafts are delivered.

Background Information

IX. Related Work

Attribute Exchange (1.0), and Simple Registration (1.0 and 1.1 Draft).

X. Initial Membership

Allen Tom, atom at Yahoo! Inc (editor)
Mike Graves, mgraves at, JanRain, Inc.
Dick Hardt, dick at Sxip Identity.
Breno de Medeiros, breno at Google, Inc. (editor)
Hideki Nara, hdknr at, Tact Communications
Nat Sakimura, n-sakimura at (editor)
John Bradley, ve7jtb at
Will Norris, will at

XI. Expected contribution


---------- Forwarded message ----------
From: Breno de Medeiros <breno at>
Date: Fri, Nov 20, 2009 at 3:07 AM
Subject: Re: AX and Artifact Binding Charter Proposal
To: John Bradley <john.bradley at>
Cc: Nat Sakimura <sakimura at>, openid-specs at

On Thu, Nov 19, 2009 at 9:46 AM, John Bradley wrote:
I can live with Nat's latest edit based on Dick's input.

Let's call the scope done.

John B.
On 2009-11-19, at 2:39 PM, Breno de Medeiros wrote:

Agree, let's define the scope, create the WG and then we can have
discussions there.
On Thu, Nov 19, 2009 at 7:33 AM, Nat Sakimura wrote:
You are right, but that will be incompatible with AX 1.0, and the
prerequisite of the scope is that it should be backward compatible. I feel
that keeping aliases is a small compromise for keeping the compatibility and
On Thu, Nov 19, 2009 at 12:37 PM, Will Norris wrote:
On Nov 18, 2009, at 7:27 PM, Nat Sakimura wrote:

(2009/11/18 15:04), Will Norris wrote:
On Nov 16, 2009, at 6:42 PM, Nat Sakimura wrote:

(2009/11/17 10:58), Will Norris wrote:
On Nov 16, 2009, at 3:49 PM, Nat Sakimura wrote:

Right. AX 1.1 is to be expedient so that it will remove the current
It should be minimalistic as to the spec change and to the

AX 2.0 will be more generic fix, and that is the place we should
whole bunch of issues.

I agree that there should be discovery way of it in XRD/s for many
but it seems to me to be in the territory of AX2.0.

Attached please find the first cut of AX1.1 Draft01.
It looks like you have policy URL defined as an actual AX attribute?
?How would that work if the RP is sending the URL to the OP. ?Doesn't it
need to be a standalone parameter like update_url is?
In this 1.1 draft, I have added the capability for the fetch request
to include "value"/"parameter".
Thus, you can do something like:
ahh, I missed that. ?This actually brings up a bigger concern regarding
what features go into 1.1 versus 2.0. ?During IIW, we talked about needing a
more robust message format, (even serialized XML or JSON was thrown about).
?I've heard all kinds of ideas for attached metadata to attributes in an AX

?- give me a verified email address
?- give me an email address that was verified using method X
?- tell me if the email address "bob at" belongs to this user
?- give me a payment token authorized for up to $50

and I'm sure folks have many, many more. ?In order to support these
kinds of scenarios, we will almost certainly need something richer than the
extended request format currently included in the 1.1 draft. ?I'm a little
concerned about changing the message format for 1.1, and then turning around
and changing it again for 2.0. ?(If others are okay with this prospect, and
it's just something I need to get over, that's fine)
I understand this concern, but on the other hand, I have got the feeling
that it will not change too much either.
I have got the feeling that it ends up as

ax.type.value.<alias>=[json file]

which is the same as we have now. Only the difference is that we are not
any more using any other <alias>,
and we will not need <alias>.count.

Of course, we have to agree on how to express attributes in json format,
agree on signature, etc. and these are the main things that we should be
dealing with in AX 2.0. Then, the finer semantics / data format / etc.needs
to be addressed in other WGs specifically for that purpose. CX WG is one
example of such thing.

Needless to say, if you wanted to use SAML assertion in it, you could do
something like

ax.type.value.<alias>=[saml assertion]

etc. as well.
If you're going to do that, then why even keep the aliases around? ?Why
not just have =
ax = [json/xml file]

That would be perfectly valid and avoid the overhead. ?Now I'm not
actually suggesting we do this, because I don't think we have a clear
understanding of the requirements for AX 2.0. ?But my point is, we may end
up with something drastically different from AX 1.0. ?I'm actually okay with
that prospect, and kind of like the idea that we have the freedom to make
such a complete departure if we thinking it's warranted. ?I'd hate to make a
hasty decision now, expecting that it will *probably* be compatible with
what we come up with in AX 2.0, only to find that it is actually a
hindrance. ?I don't know that this is going to be a problem, but that's
exactly my point... we don't know. ?So the fewer changes we make in AX 1.1,
the better, I think.


specs mailing list
specs at

Nat Sakimura (=nat)

specs mailing list
specs at


+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
specs mailing list
specs at


+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

Nat Sakimura (=nat)

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupopenid-specs-council @
postedDec 29, '09 at 7:30a
activeDec 29, '09 at 7:30a

1 user in discussion

Nat Sakimura: 1 post



site design / logo © 2021 Grokbase