(2009/11/18 15:04), 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)
I understand this concern, but on the other hand, I have got the feeling
that it will not change too much either.
I have got the feeling that it ends up as
ax.type.<alias>=http://openid.net/spec/ax/2.0/json
ax.type.value.<alias>=[json file]
which is the same as we have now. Only the difference is that we are not
any more using any other <alias>,
and we will not need <alias>.count.
Of course, we have to agree on how to express attributes in json format,
agree on signature, etc. and these are the main things that we should be
dealing with in AX 2.0. Then, the finer semantics / data format /
etc.needs to be addressed in other WGs specifically for that purpose. CX
WG is one example of such thing.
Needless to say, if you wanted to use SAML assertion in it, you could do
something like
ax.type.<alias>=http://openid.net/spec/ax/2.0/saml/2.0
ax.type.value.<alias>=[saml assertion]
etc. as well.
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?
That's a typo. I did not copy the other paragraph. It should not require
it. In the next rev, I will make sure that it gets in.
- 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.
I will look into it.
-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
