AX and Artifact Binding Charter Proposal

John Bradley john.bradley at wingaa.com
Thu Nov 19 17:46:16 UTC 2009 

I can live with Nat's latest edit based on Dick's input.

Let's call the scope done.

John B.
On 2009-11-19, at 2:39 PM, Breno de Medeiros wrote:

> Agree, let's define the scope, create the WG and then we can have
> discussions there.
> 
> On Thu, Nov 19, 2009 at 7:33 AM, Nat Sakimura <sakimura at gmail.com> wrote:
>> Will,
>> You are right, but that will be incompatible with AX 1.0, and the
>> prerequisite of the scope is that it should be backward compatible. I feel
>> that keeping aliases is a small compromise for keeping the compatibility and
>> flexibility.
>> =nat
>> 
>> On Thu, Nov 19, 2009 at 12:37 PM, Will Norris <will at willnorris.com> wrote:
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>> 
>> 
>> 
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> 
>> 
> 
> 
> 
> -- 
> --Breno
> 
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20091119/2c8b3d91/attachment.bin>

More information about the specs mailing list