Request for consideration of AX 2.0 Working Group Charter Proposal

Henrik Biering hb at netamia.com
Tue Dec 30 00:39:44 UTC 2008


A couple of comments to the AX 2.0 WG proposal:

*1. Structs*
Definition of structs as proposed by Nat should definitely be 
considered. They are important e.g. for physical addresses, where token 
based validation will always relate to a complete address rather than to 
its individual parts. For addresses a structure like OASIS UBL2 derived 
from UN/CEFACT should be considered.

*2. Validation of attributes*
I hope that the working group will consider the rather large variation 
in needs - from basic email, phone or address validation relevant for 
the long tail - to the more complex identity validations required by 
large C2C social and trading portals.

While the simple validation requirements appear to be rather invariant, 
there is ongoing development for complex validation, where RP validation 
requirements (for legal as well as practical reasons) may depend on age, 
nationality and a combination of identity and reputation data.

The current dominance of SREG relative to AX also makes it feasible to 
facilitate attribute validation in combination with SREG. Eliminating 
email validation from the registration workflow will be a significant UX 
gain for OpenID.

Therefore it might be appropriate to separate the validation spec from 
the generic attribute exchange and possibly define a "Simple" as well as 
an "Advanced" validation extension compatible with AX 2.0, AX 1.0 and 
SREG. This would make AX more stable, increasing the possibility of 
having generic libraries available.

Furthermore, by separating the specs for validation from the generic 
attribute exchange the validation extension becomes a natural companion 
to PAPE,  exposing similar trust issues between OP's and RP's.

=henrik



Allen Tom wrote:
> I believe that one of the goals of AX 2.0 should be to maintain 
> backwards compatible with AX 1.0 whenever possible.
>
> Allen
>
>
> Mike Jones wrote:
>   
>> Can you add a clear statement to the draft charter that implementations already using AX 1.0 will remain compatible with the output of this working group?  Or is backwards-compatibility with existing AX implementations not a goal of this work?
>>
>>                                 -- Mike
>>
>> -----Original Message-----
>> From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf Of Breno de Medeiros
>> Sent: Thursday, December 18, 2008 6:18 PM
>> To: OpenID Specs Mailing List
>> Cc: dick at skip.com; hdknr at ic-tact.co.jp; mgraves at janrain.com
>> Subject: Request for consideration of Working Group Charter Proposal
>>
>> I would like to submit the following proposal for a new Working Group
>> charter to your consideration, following the OpenID IPR process:
>>
>> The proposal charter is also available at:
>> http://wiki.openid.net/Working_Groups:AX_2.0
>>
>> OpenID Attribute Exchange 2.0 Working Group (AX 2.0)
>>
>>
>> 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 (still liable to change during this
>> feedback period).
>>
>>
>> I. Name
>>
>> Attribute Exchange Extension Working Group (AX)
>>
>>
>> II. Statement of Purpose
>>
>> Produce an updated version of the Attribute Exchange Extension.
>>
>>
>> III. Scope
>>
>> Update the Attribute Exchange Extension to include support for
>> identified needs. Currently identified needs:
>>
>>     * Provide mechanisms for RP to require, and the OP to assert,
>> claims about the quality of the attributes.
>>     * Create an extensible registry of claim types, such as
>> axschema.org for attribute types. The registry should also provide
>> non-normative guidance on how claims can be validated, which will
>> depend on the nature of attribute type as well as claim type.
>>     * Introduce a new request/response mode which, unlike fetch and
>> store, allows for both transmittal of some values and request of
>> others. The transmittal not necessarily has the significance of a
>> "store" request (could be informative, or for requesting validation).
>>     * Introduce a direct communication method in both directions
>> (OP<->RP), supported via discovery, for bulk exchange of attributes
>> about (potentially) multiple users.
>>
>>
>> IV. Specifications
>>
>> OpenID Attribute Exchange 2.0
>>
>>
>> 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 2.0 spec final draft is delivered and the form
>> of management and maintenance of the registry is established.
>>
>>
>> Background Information
>> I. Related Work
>>
>> Attribute Exchange (1.0), and Simple Registration.
>> II. Initial Membership
>>
>>     * Tom Allen, 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)
>>
>>
>>
>>
>> --
>> --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 openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>   
>>     
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081230/ed50cddc/attachment-0002.htm>


More information about the specs mailing list