AX and Artifact Binding Charter Proposal

[John Bradley]

I can buy the argument that without a signed request, getting the URI  
from the RP's XRDS via https or even http is preferable.

Is there an argument for following the SREG pattern of putting it in  
the request.

Other than the RP perhaps not publishing a XRDS for some reason. (if  
they don't do that they are not that likely to publish a privacy  
policy ether.)

While we are at it do we want to also publish a TOS URI?

John B.
On 2009-11-13, at 9:28 PM, Breno de Medeiros wrote:

> s/legal/privacy/g
>
> On Fri, Nov 13, 2009 at 4:28 PM, Breno de Medeiros  
> <breno at google.com> wrote:
>> Keeping the requests short is a Good Thing, but I have heard  
>> arguments
>> that showing a legal policy from an untrusted source A and claiming
>> that it is the policy of party B (remember that the request could be
>> forged) could be a non-starter for some OPs.
>>
>> On Fri, Nov 13, 2009 at 4:24 PM, John Bradley <john.bradley at wingaa.com 
>> > wrote:
>>> That could easily be done via a new element in the XRDS.  That  
>>> requires RP
>>> discovery, not a bad thing.
>>> You are thinking about keeping the request size down?
>>> John B.
>>> On 2009-11-13, at 8:22 PM, Allen Tom wrote:
>>>
>>> Agreed - it would be great if we could make the RP's privacy  
>>> policy URL
>>> discoverable.
>>>
>>> Allen
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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)
>>
>
>
>
> -- 
> --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/cd424022/attachment.bin>