AX and Artifact Binding Charter Proposal

[Nat Sakimura]

(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
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>