(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
...
But you are right. It would be simpler to do openid.ax.policy_url.
I have done it in the "AX way" but it does not have to be like that.
That actually is true for all the mandatory fields that I have added in Section
7.1.
I wanted to know what would be the sentiment of this community wrt this
so I have kept it in "purist" form.
So you like the fixed urls for the basic set?
The attribute schema is extensible... there is nothing stopping someone from creating a
"name" attribute in their own namespace. Nor can we force OPs to release any
particular piece of data for users. So what does it mean for section 7 to say that this
particular set of attributes MUST be supported? supported in what sense? The OP must
understand the request? Well that's required anyway right, as long as it's a well-formed
AX request? I think the most we can do here is to *encourage* use of these attribute
names.
Supported in the sense that the OP must understand those attribute
schema urls.
In general, when OP encounters a type URL, they do not know what to do
with it
although they understand that it is a valid AX request.
I meant that the OP must understand these type URLs because it is baked
into the spec.
I am still using axschema.org but shorter ones in the spirit of bit.ly would
be preferable. Also, perhaps we should replace all example.com to this URI
(whether it be axschema or a short one) because that would drive people to a
standard set of uris.
keep in mind that whatever we use here is going to be somewhat permanent. Even
though AX 2.0 may be incompatible with 1.X (due to a richer message format, or
whatever), it's quite likely that we'll still want to use the same attribute
URIs.
Yes. So the question is whether we want to use axschema.org for the
permanent purpose, or something else.
From openid point of view, openid.net is good. However, this schema can
be used by other protocols, so perhaps non-openid url might be better.
Just curious, but why are we stressing too much on the attribute name length?
I understand we want to keep the message smaller if possible, but isn't that
what the artifact profile is going to be for? Won't this be a moot point then?
From the feedback that I am getting in iiw etc., shorter as it becomes,
the payload itself gets smaller, and that's a plus for those
mega-providers.
=nat
-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
