[Specs-cx] Discussion note on Contract eXchange Requirement

[Tatsuki Sakushima]

Hi Nat,

Thanks for replying.

> 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

IMHO, to discuss this, it would be easier if we have a draft distributed
to this WG.

Tatsuki

Tatsuki Sakushima
NRI Pacific - Nomura Research Institute America, Inc.

(8/6/09 7:39 PM), Nat Sakimura wrote:
> Hi Tatsuki,
> 
> On Fri, Aug 7, 2009 at 1:42 AM, Tatsuki Sakushima <tatsuki at nri.com 
> <mailto: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 <mailto:Specs-cx at openid.net>
>         http://openid.net/mailman/listinfo/specs-cx
> 
>     _______________________________________________
>     Specs-cx mailing list
>     Specs-cx at lists.openid.net <mailto:Specs-cx at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-cx
> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/