AX and Artifact Binding Charter Proposal

Nat Sakimura n-sakimura at nri.co.jp
Thu Nov 19 02:29:15 UTC 2009


Privacy URL is not only the pain point.
Adding fetch parameter requires minimal change in the library, and is 
worth doing, IMHO.
Once we do that, just defining privacy type url will do the job.

=nat


(2009/11/18 21:06), John Bradley wrote:
> I think we are getting into scope creep for AX 1.1
>
> I was hoping for something that could fix the major pain points now without requiring significant RP library changes.
>
> That is one of the reasons I liked adding the privacy and TOS policy to the RP XRDS.
>
> They require 0 changes to the library.
>
> Adding discoverable endpoints and clarifying what URI to use can be done without RP lib code changes, only config changes.
>
> I think anything requiring lib changes for the RP is going to take longer to deploy.
>
> I am OK with OP lib changes for AX 1.1 that is easier to manage.
>
> I prefer all of the RP changes to go into AX 2.0.
>
> John B.
> On 2009-11-18, at 3:04 AM, 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)
>>
>> 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
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>      
>    
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091119/a8e2b28b/attachment-0001.htm>


More information about the specs mailing list