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 openid.net.
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

English.

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.com. Yahoo! Inc (editor)
Mike Graves, mgraves at janrain.com, JanRain, Inc.
Dick Hardt, dick at skip.com. Sxip Identity.
Breno de Medeiros, breno at google.com. Google, Inc. (editor)
Hideki Nara, hdknr at ic-tact.co.jp, Tact Communications
Nat Sakimura, n-sakimura at nri.co.jp (editor)
John Bradley, ve7jtb at ve7jtb.com
Will Norris, will at willnorris.com

XI. Expected contribution

http://lists.openid.net/pipermail/openid-specs/attachments/20091117/c5754ef7/attachment-0001.html

=============================================


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


+1
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:
Will,
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
flexibility.
=nat
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
acute
pain.
It should be minimalistic as to the spec change and to the
implementation
change.

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

I agree that there should be discovery way of it in XRD/s for many
use
cases,
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:

openid.ns.ax=http://openid.net/srv/ax/1.1
openid.ax.mode=fetch_request
openid.ax.type.policy_url=http://axschema.org/policy_url
openid.ax.value.policy_url=http://examplerp.com/data_usage_policy.html
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
request...

?- 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 example.com" 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.<alias>=http://openid.net/spec/ax/2.0/json
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.<alias>=http://openid.net/spec/ax/2.0/saml/2.0
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

ns.ax = http://openid.net/specs/ax/2.0
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.

-will

_______________________________________________
specs mailing list
specs at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs


--
Nat Sakimura (=nat)
http://www.sakimura.org/en/

_______________________________________________
specs mailing list
specs at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs


--
--Breno

+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 lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs


--
--Breno

+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)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupopenid-specs-council @
categoriesopenid
postedDec 29, '09 at 7:30a
activeDec 29, '09 at 7:30a
posts1
users1
websiteopenid.net
irc#openid

1 user in discussion

Nat Sakimura: 1 post

People

Translate

site design / logo © 2021 Grokbase