Privacy URL is not only the pain point.
Adding fetch parameter requires minimal change in the library, and is
worth doing, IMHO.
Once we do that, just defining privacy type url will do the job.
=nat
(2009/11/18 21:06), John Bradley wrote:
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:
On Nov 16, 2009, at 6:42 PM, Nat Sakimura wrote:
(2009/11/17 10:58), Will Norris wrote:
On Nov 16, 2009, at 3:49 PM, Nat Sakimura wrote:
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.
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?
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=http://openid.net/srv/ax/1.1
openid.ax.mode=fetch_request
openid.ax.type.policy_url=http://axschema.org/policy_url
openid.ax.value.policy_url=http://examplerp.com/data_usage_policy.html
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 "[email protected]" 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
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
