[Specs-cx] Discussion note on Contract eXchange Requirement

Nat Sakimura sakimura at gmail.com
Fri Aug 7 02:39:12 UTC 2009


Hi Tatsuki,

On Fri, Aug 7, 2009 at 1:42 AM, Tatsuki Sakushima <tatsuki at nri.com> wrote:

> Hi Nat,
>
> I read the document. Here is my comments:
>
> -This contract data may be out of scope but could be in the spec
> since this spec defines "Contract Exchange".


I can assure you that it is NOT out of scope.


>
> -Contract data could be big, therefore it should not be transmitted
> in a indirect communication channel. It should be always in a direct
> communication. The key to reference the data should be transmitted
> either direct or indirect communication. The key MUST be small enough
> for mobile phones to exchange in a protocol.


Agreed.


>
> -Contract data can be written in many forms(XML preferred?). It should be
> extensible
> (flexible) and detachable from a protocol.


Agreed. We can think of XML, XDI, JSON, etc., but from the point of view of
the library reuse, XML seems to be a logical choice. Also, XML has added
benefit of having defined long-term signature validation methodologies
established. Of course, this does not preclude other formats either. I am
just saying that XML as the default and leaving the separate profile to
define other format would be logical approach.


>
> (Replacing it has no effect on protocol part.)


Indeed.


>
> -The format of parameters in protocol is still "key-value" pairs.
> The reference key for contract data is one of parameters in a protocol.


Agreed.


>
> -Authentication in 4 legs model and Notification is tricky. The flow should
> be clearly defined.


The use case is valid and useful as well as real.
Only concern in including it in the spec is that it may get a bit
complicated for the readers.
>From a spec modularity point of view, we should write the 4 legs model first
and make the 3 legs one as a special case, though.


>
> -I am still not sure how AX can carry site(server) attributes seemed to
> be required in this spec. This could be a issue. However, reusing existing
> specs/protocols is a good thing.


Right. AX 2.0 WG not starting after over 8 months are a sad fact.
We have been waiting for Microsoft to give Dick the permission to join in,
but apparently he has not got it yet. It is probably the time that we should
start.


>
> I hope this would help. Should we start discussion about the spec based on
> this document? Please let us know how you like to proceed.


Yes. We should discuss and build consensus around it.
Then, we should implement to see if it really works.
Let's write spec after that. That's going to be more concrete.

Would that be OK?

Assuming that's ok, what we have to decide on are:
* Spell out the message flow more concretely.
* List the parameters that we need to send and receive in each flow
* Name the parameters
* Make XML schema


=nat


>
>
> Tatsuki
> Tatsuki Sakushima
> NRI Pacific - Nomura Research Institute America, Inc.
>
>
>
> (7/30/09 4:53 AM), Nat Sakimura wrote:
>
>> Hi All:
>>
>> To explain the concept of CX better, and by doing so, making my
>> understanding clearer, I wrote a discussion note to set a level ground on
>> the discussion.
>>
>> Please have a look.
>>
>> Hopefully, it is pretty clear.
>>
>> Caveat: It is the dump of my thinking as of today, and no proof reading
>> has been done.
>>
>> Cheers,
>>
>> =nat
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Specs-cx mailing list
>> Specs-cx at openid.net
>> http://openid.net/mailman/listinfo/specs-cx
>>
> _______________________________________________
> Specs-cx mailing list
> Specs-cx at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-cx
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-cx/attachments/20090807/8a1b73d9/attachment.htm>


More information about the Specs-cx mailing list