AX and Artifact Binding Charter Proposal

Will Norris will at willnorris.com
Thu Nov 19 03:37:23 UTC 2009


On Nov 18, 2009, at 7:27 PM, Nat Sakimura wrote:

> (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 "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)
>>   
> 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.

If you're going to do that, then why even keep the aliases around?  Why not just have

ns.ax = http://openid.net/specs/ax/2.0
ax = [json/xml file]

That would be perfectly valid and avoid the overhead.  Now I'm not actually suggesting we do this, because I don't think we have a clear understanding of the requirements for AX 2.0.  But my point is, we may end up with something drastically different from AX 1.0.  I'm actually okay with that prospect, and kind of like the idea that we have the freedom to make such a complete departure if we thinking it's warranted.  I'd hate to make a hasty decision now, expecting that it will *probably* be compatible with what we come up with in AX 2.0, only to find that it is actually a hindrance.  I don't know that this is going to be a problem, but that's exactly my point... we don't know.  So the fewer changes we make in AX 1.1, the better, I think.

-will



More information about the specs mailing list