Right. AX 1.1 is to be expedient so that it will remove the current acute pain. <div>It should be minimalistic as to the spec change and to the implementation change. </div><div><br></div><div>AX 2.0 will be more generic fix, and that is the place we should consider </div>
<div>whole bunch of issues. </div><div><br></div><div>I agree that there should be discovery way of it in XRD/s for many use cases, </div><div>but it seems to me to be in the territory of AX2.0. </div><div><br></div><div>
Attached please find the first cut of AX1.1 Draft01. </div><div><br></div><div>I am still using <span class="Apple-style-span" style="font-family: verdana; "><a href="http://axschema.org">axschema.org</a> but shorter ones in the spirit of <a href="http://bit.ly">bit.ly</a> would be preferable. Also, perhaps we should replace all <a href="http://example.com">example.com</a> to this URI (whether it be axschema or a short one) because that would drive people to a standard set of uris. </span></div>
<div><br></div><div>=nat<br><br><div class="gmail_quote">On Tue, Nov 17, 2009 at 8:25 AM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com">john.bradley@wingaa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">OK if there is a real use case for per request privacy policy.<div><br></div><div>I think we need it in the RP XRDS for unsolicited assertions and active selectors. </div><div><br></div>
<div>I can see overriding a default privacy policy with one in the request. </div><div>I suspect that >90% of the RPs are just going to have one and can reduce there request size by not putting it in the request.</div>
<div><br></div><div>I did say re-using the sreg parameter would work but I am not super comfortable with using a parameter from one extension in another. I don't think that is a good practice.</div><div><br></div><div>
It would be expedient though.</div><div><br></div><div>John B.<div><div></div><div class="h5"><br><div><div>On 2009-11-16, at 8:03 PM, Nat Sakimura wrote:</div><br><blockquote type="cite"><div><br></div><div>Inline: <br><br>
<div class="gmail_quote">On Tue, Nov 17, 2009 at 2:30 AM, John Bradley <span dir="ltr"><<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We don't have it in the request now.<br></blockquote><div><br></div><div>SREG does send it in openid.sreg.policy_url. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I would prefer to only add one new way. Adding two and deprecating one immediately sounds a touch silly.<br>
<br>
If someone can think of a reason why passing it in the request is better I would be more interested in considering it. </blockquote><div><br></div><div>Depending on what you are requesting, you might want to change the privacy policy. Indeed, in Japanese and I believe EU privacy law, you need to be so specific to the point that a general statement url given in XRDS probably does not work. For instance, stating that you are "using the data for marketing purpose" is too broad and illegal. This kind of consideration actually rules out the discovery way of doing it. The policy is linked to the request, and not the host/domain/company etc. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We know it is worse because it could be spoofed with an unsigned request. </blockquote><div><br></div><div>I anticipate that in openid v.next, the requests are going to be signed. </div><div>In the artifact binding proposal that I wrote, it is signed. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Unless we are proposing using openid.sreg.policy_url for both we wind up with RP's sending the privacy policy URI twice in every request. We could reuse the same parameter for SRAG and AX but that is not too clean.<br>
<br>
For short names if we want to keep with URI we could use URN eg.<br>
urn:ax:fullname<br>
<br>
Though I don't give us much of a chance of getting the IANA to register a NID for us.<br>
<br>
I am slightly uncomfortable making it a space separated list of strings and URI.<br>
<br>
RP's code may need to be reworked to allow strings.<br>
<br>
The unregistered URI scheme ax: is also possible. It just depends on who we want mad at us:)<br>
<br>
I suppose we could use ax:fullname and call it a string that just happens to look like a URI:)<br>
<br>
John B.<br>
<div><div></div><div>On 2009-11-16, at 1:45 PM, Breno de Medeiros wrote:<br>
<br>
> On Sat, Nov 14, 2009 at 7:15 PM, Nat <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<br>
>> I am taking a crack at editing the spec.<br>
>><br>
>> Observing the discussion, there are couple of questions I would like to ask.<br>
>><br>
>> 1. Privacy Policy URL.<br>
>><br>
>> We are discussing about the privacy policy URL in RP XRD. That's fine but<br>
>> we might also want to consider it being included in the request parameter as<br>
>> in SREG. Do you want to drop it? I think we should keep it.<br>
><br>
> We could keep it for parity with SREG but recommend using discovery instead.<br>
><br>
>><br>
>> 2. Default Attributes<br>
>><br>
>> Do we want to do it in AX way or creat a special set which is compatible<br>
>> with SREG so that the request URL will be a little shorter?<br>
><br>
> +1 for introducing bult-in aliases for the commonly used URLs.<br>
><br>
>><br>
>> =nat@Tokyo via iPhone<br>
>><br>
>> On 2009/11/14, at 12:29, Allen Tom <<a href="mailto:atom@yahoo-inc.com" target="_blank">atom@yahoo-inc.com</a>> wrote:<br>
>><br>
>>> Let's just keep it simple, and put a single link for the privacy policy in<br>
>>> the discovery document, which would be enough to have parity with SREG. A<br>
>>> link for ToS is fine too.<br>
>>><br>
>>> The UI Extension is going to define a discovery mechanism for RPs and OPs<br>
>>> to publish their icons (and presumably their names/descriptions) so we<br>
>>> should try to make it consistent.<br>
>>><br>
>>><br>
>>> <a href="http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor6" target="_blank">http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor6</a><br>
>>><br>
>>> Allen<br>
>>><br>
>>><br>
>>> John Bradley wrote:<br>
>>>><br>
>>>> We could do a template for lang and jurisdiction.<br>
>>>><br>
>>>> The other way of dealing with lang is is via content negotiation or links<br>
>>>> in the HTML documents.<br>
>>>><br>
>>>> I don't know that it is worth complicating the simple case with<br>
>>>> templates.<br>
>>>><br>
>>>> Having different elements is also a path to madness.<br>
>>>><br>
>>>> Is this a feature that OP would use?<br>
>>>><br>
>>>> John B.<br>
>>>> On 2009-11-13, at 11:30 PM, Allen Tom wrote:<br>
>>>><br>
>>>>> Keeping the request size small and having RPs implement discovery are<br>
>>>>> both good things.<br>
>>>>><br>
>>>>> Also privacy policies, as well as other RP metadata (icons,<br>
>>>>> descriptions) all make sense to put into discovery.<br>
>>>>><br>
>>>>> If the RP is behind a firewall and isn't accessible to the OP, then<br>
>>>>> hopefully OPs that care about RP metadata can just indicate to the user that<br>
>>>>> the metadata was not found.<br>
>>>>><br>
>>>>> The proposed XRDS schema looks reasonable. We might want to have<br>
>>>>> different urls for different languages/jurisdictions, although that's<br>
>>>>> probably overkill.<br>
>>>>><br>
>>>>> Allen<br>
>>>>><br>
>>>>><br>
>>>>> John Bradley wrote:<br>
>>>>>><br>
>>>>>> See folks spec work can be fun:)<br>
>>>>>><br>
>>>>>> John B.<br>
>>>>>> On 2009-11-13, at 10:29 PM, Breno de Medeiros wrote:<br>
>>>>>><br>
>>>>>>> Going once, going twice ...<br>
>>>>>>><br>
>>>>>>> On Fri, Nov 13, 2009 at 5:26 PM, John Bradley<br>
>>>>>>> <<a href="mailto:john.bradley@wingaa.com" target="_blank">john.bradley@wingaa.com</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>> Any preference for a namespace?<br>
>>>>>>>><br>
>>>>>>>> We could reuse the openid one that we have for openID 1.1 delegate.<br>
>>>>>>>><br>
>>>>>>>> xmlns:openid="<a href="http://openid.net/xmlns/1.0" target="_blank">http://openid.net/xmlns/1.0</a>"<br>
>>>>>>>><br>
>>>>>>>> <Service><br>
>>>>>>>> <Type><a href="http://specs.openid.net/auth/2.0/return_to" target="_blank">http://specs.openid.net/auth/2.0/return_to</a></Type><br>
>>>>>>>> <URI><a href="http://consumer.example.com/return" target="_blank">http://consumer.example.com/return</a></URI><br>
>>>>>>>><br>
>>>>>>>> <openid:Policy_url><a href="http://example.com/privacy-policy.html" target="_blank">http://example.com/privacy-policy.html</a></openid:Policy_url><br>
>>>>>>>> <openid:TOS><a href="http://example.com/terms-of-service.html" target="_blank">http://example.com/terms-of-service.html</a></openid:TOS><br>
>>>>>>>> </Service><br>
>>>>>>>><br>
>>>>>>>> I should note that this wont work for RP's behind a firewall being<br>
>>>>>>>> accessed<br>
>>>>>>>> from a LAN or VPN.<br>
>>>>>>>><br>
>>>>>>>> I am going to observe that if you are all ready on the LAN the<br>
>>>>>>>> privacy<br>
>>>>>>>> policy can be dealt with out of band if necessary.<br>
>>>>>>>><br>
>>>>>>>> I am not emotionally attached to the namespace or element names if<br>
>>>>>>>> someone<br>
>>>>>>>> has something else they like.<br>
>>>>>>>><br>
>>>>>>>> John B.<br>
>>>>>>>> On 2009-11-13, at 9:51 PM, Breno de Medeiros wrote:<br>
>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> While we are at it do we want to also publish a TOS URI?<br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Don't see why not.<br>
>>>>>>>>><br>
>>>>>>>>> --<br>
>>>>>>>>> --Breno<br>
>>>>>>>>><br>
>>>>>>>>> +1 (650) 214-1007 desk<br>
>>>>>>>>> +1 (408) 212-0135 (Grand Central)<br>
>>>>>>>>> MTV-41-3 : 383-A<br>
>>>>>>>>> PST (GMT-8) / PDT(GMT-7)<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> --Breno<br>
>>>>>>><br>
>>>>>>> +1 (650) 214-1007 desk<br>
>>>>>>> +1 (408) 212-0135 (Grand Central)<br>
>>>>>>> MTV-41-3 : 383-A<br>
>>>>>>> PST (GMT-8) / PDT(GMT-7)<br>
>>>>>><br>
>>>>><br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> specs mailing list<br>
>>> <a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
>>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
>><br>
>> _______________________________________________<br>
>> specs mailing list<br>
>> <a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> --Breno<br>
><br>
> +1 (650) 214-1007 desk<br>
> +1 (408) 212-0135 (Grand Central)<br>
> MTV-41-3 : 383-A<br>
> PST (GMT-8) / PDT(GMT-7)<br>
> _______________________________________________<br>
> specs mailing list<br>
> <a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
</div>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>
</div>