Please refer to the other mail of mine sent a few minutes ago, but here
is my proposal to the scope:
AX 1.1
------
- Add fetch parameter
- Using the above, bake privacy type url into the spec.
- Bake SREG compatible type urls into the spec.
AX 2.0
------
- Anything else.
Perhaps I should create a separate charter for AX 1.1 and 2.0.
Also, PLEASE VOTE! on the currently going IPR Process change poll.
https://openid.net/foundation/members/polls/21
We badly need your vote. Otherwise, we will not be able to spin up a WG!
=nat
(2009/11/19 12:23), Will Norris wrote:
So first of all, it's obvious that there is not consensus on the scope of work
for AX 1.1. We definitely need to figure that out.
Regarding a policy URL for the RP, the more I think about it I'm not sure that the proposed
solution makes the most sense, even if we were to include attribute values in the request. All of
the other use cases I've seen surrounding richer data in the request have to do with adding
additional metadata to a requested attribute. Things like "I only want verified values for
this attribute", or "Give me a value within these parameters". But it's still
metadata surrounding a requested attribute. Policy URL is not a requested attribute. The RP does
not wish for the OP to return any kind of value for this. It's an entirely different animal. The
policy URL is really metadata about *all* of the attributes, or metadata about the request,
depending on how you want to look at it. I think it's relatively unique in that, and justifies a
separate AX parameter. I think it becomes very confusing when some attributes are being requested,
but others are being asserted, (and some maybe
b
oth?) all in the same message with no real way to differentiate them.
-will
On Nov 18, 2009, at 6:29 PM, Nat Sakimura wrote:
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
