[Specs-cx] Discussion note on Contract eXchange Requirement

Thu Aug 20 00:19:29 UTC 2009

We have artifact binding discussion going on on specs list, and that would
impact us, but here is the draft that we had internally in Japan.
Discussion items are in yellow.

Note that if artifact goes in to the main authentication spec, then we can
drop artifact related things in CX. Also, John has indicated the desire of
being able to encrypt the payload on Authentication requests/responses. If
that happens, we can drop good portion of the section 4.8 as well. However,
as we do not know when the change in the Authentication protocol happens, it
is better for us to keep them here, IMHO.

Cheers,

=nat

On Sat, Aug 8, 2009 at 2:26 AM, Tatsuki Sakushima <tatsuki at nri.com> wrote:

> 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/
>>
>

-- 
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/20090820/089c3038/attachment.htm>