AX and Artifact Binding Charter Proposal

John Bradley john.bradley at wingaa.com
Fri Nov 13 17:39:10 UTC 2009


I am OK with calling out the 9 SREG ones in 1.1 is fine.

I think a solution where RP's need to discover what URI to use for  
those attributes is too ambitious for 1.1.

I am guessing that someone is going to chime in asking for short names  
for the URI rather than the ones that are currently in use.

Nat will point out that if we have artifact binding we don't ned short  
names etc.

It should be an interesting discussion for 1.1 but hopefully not a  
long one.

John B.


On 2009-11-13, at 2:10 PM, Breno de Medeiros wrote:

> On Fri, Nov 13, 2009 at 4:05 AM, John Bradley  
> <john.bradley at wingaa.com> wrote:
>> +1 Fixing the missing policy URL and an agreement on a base set of  
>> AX URL
>> need to be a priority.
>
> Such agreement may be hard to achieve, but a set of URLs to support
> discovery of supported attributes would be good. I am inclined to give
> on on URL registry at this moment and support baking them into the
> spec directly, for expediency reasons.
>
>>
>> In the work I am doing with RP's having to preconfigure what they  
>> ask for
>> based on the OP is an adoption barrier.
>>
>> I have added myself to the list of proposers.
>>
>> John B.
>> On 2009-11-13, at 2:34 AM, Breno de Medeiros wrote:
>>
>>> +1 and also a vote for the spec to define a URL which can be used to
>>> publish the policy URL in the XRD(S) document as well.
>>>
>>> On Thu, Nov 12, 2009 at 8:42 PM, Allen Tom <atom at yahoo-inc.com>  
>>> wrote:
>>>>
>>>> +1
>>>>
>>>> Definitely would love to see AX 1.1 released, hopefully  
>>>> eliminating any
>>>> need
>>>> for SREG.
>>>>
>>>> To reach parity with SREG, AX 1.1 needs to have a standard way  
>>>> for RPs to
>>>> pass their privacy policy URL, and it would be great to have a  
>>>> standard
>>>> schema with very short attribute names.
>>>>
>>>> It's very costly for OPs (and RPs) to support dual SREG and AX
>>>> interfaces,
>>>> when only one interface is necessary. It also hurts the interop  
>>>> story if
>>>> there's no standard and widely implemented way to share basic  
>>>> profile
>>>> data.
>>>>
>>>> Allen
>>>>
>>>>
>>>> Dick Hardt wrote:
>>>>
>>>> +1!
>>>> On 2009-11-12, at 8:05 AM, Nat Sakimura wrote:
>>>>
>>>> Hi.
>>>> In anticipation of the Working Group creation process gets  
>>>> simplified in
>>>> a
>>>> couple of days, I have edited AX charter proposal to add "1.1"  
>>>> for a
>>>> quick
>>>> fix of things like privacy policy url and fetch parameters, which
>>>> requires
>>>> only few lines of additions, so that we can finish it quickly and  
>>>> then
>>>> work
>>>> more substantial 2.0, which includes the data structure change.
>>>> Also I have created Artifact Binding Charter, which will allow  
>>>> the use of
>>>> OpenID in limited browsers (e.g., mobile) and improves security.  
>>>> Please
>>>> feel
>>>> free to add your names to the list of proposers.
>>>> Best,
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> http://www.sakimura.org/en/
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>> ________________________________
>>>> _______________________________________________
>>>> specs mailing list
>>>> specs at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>> _______________________________________________
>>>> 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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091113/2897b2fa/attachment.bin>


More information about the specs mailing list