AX and Artifact Binding Charter Proposal

[Will Norris]

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 "bob at example.com" 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