<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Privacy URL is not only the pain point. <br>
Adding fetch parameter requires minimal change in the library, and is
worth doing, IMHO. <br>
Once we do that, just defining privacy type url will do the job. <br>
<br>
=nat<br>
<br>
<br>
(2009/11/18 21:06), John Bradley wrote:
<blockquote cite="mid:63A5F9D4-D74F-452E-8E89-79C9A428EAE6@wingaa.com"
type="cite">
<pre wrap="">I think we are getting into scope creep for AX 1.1
I was hoping for something that could fix the major pain points now without requiring significant RP library changes.
That is one of the reasons I liked adding the privacy and TOS policy to the RP XRDS.
They require 0 changes to the library.
Adding discoverable endpoints and clarifying what URI to use can be done without RP lib code changes, only config changes.
I think anything requiring lib changes for the RP is going to take longer to deploy.
I am OK with OP lib changes for AX 1.1 that is easier to manage.
I prefer all of the RP changes to go into AX 2.0.
John B.
On 2009-11-18, at 3:04 AM, Will Norris wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On Nov 16, 2009, at 6:42 PM, Nat Sakimura wrote:
</pre>
<blockquote type="cite">
<pre wrap="">(2009/11/17 10:58), Will Norris wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Nov 16, 2009, at 3:49 PM, Nat Sakimura wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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=<a class="moz-txt-link-freetext" href="http://openid.net/srv/ax/1.1">http://openid.net/srv/ax/1.1</a>
openid.ax.mode=fetch_request
openid.ax.type.policy_url=<a class="moz-txt-link-freetext" href="http://axschema.org/policy_url">http://axschema.org/policy_url</a>
openid.ax.value.policy_url=<a class="moz-txt-link-freetext" href="http://examplerp.com/data_usage_policy.html">http://examplerp.com/data_usage_policy.html</a>
</pre>
</blockquote>
<pre wrap="">
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 <a class="moz-txt-link-rfc2396E" href="mailto:bob@example.com">"bob@example.com"</a> 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)
Addressing some of the specific changes in the 1.1 message format...
- why not also support single attributes values in the request using the form "ax.value.<alias>"? Why always require the count?
- it seems the ax.count.<alias> parameter on the request is serving double duty. It is defined as specifying the max number of attribute values the OP should include in the response. But then it is also used for the max number of values that can be in the request. That seems a bit weird.
-will
_______________________________________________
specs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
specs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<br>
</body>
</html>