CX proposal update
Nat
sakimura at gmail.com
Fri Jan 23 01:52:26 UTC 2009
Whether it really is legally binding depends on what jurisdiction you
are in, but typically there are some minimal set of info that has to
be included to be considered to be a good one. Namely, sufficiently
unique identifiers for all the parties involved, term, date, expiry,
renewal privision, termination clause, jurisdiction, and signatures.
Signature sometimes is of not the subject but of a proxy agent.
CX is going to define how these should be represented.
These "contracts" typically lives long, and there are readability
requirement as well. (I.e. it should not require a special software to
read and understand what it means.) Cryptographically, it requires
provisioning against algorithm getting compromised such as time
stamping.
We also have to define the verification procedure for all the above.
Then, there is an issue of what entails the reasonable action and
workflow etc. as a proof of user consent.
So, in summary, while we intend to use AX (and/or OAuth hybrid) as the
undelying protocol, it is a little more than merely defining another
set of attributes.
=nat at TOKYO via iPhone
On 2009/01/23, at 5:43, Allen Tom <atom at yahoo-inc.com> wrote:
> Hi Nat,
>
> Can you define the term "contract"? Is it legally binding? It is
> just a signed set of attributes? Who are the parties involved with
> signing the contract? The RP, OP, and user? Instead of defining a
> new CX extension, would it just be sufficient to define new
> attributes using AX?
>
> Would it make more sense to use OAuth instead of defining a new
> OpenID extension? OAuth is designed to allow a user to authorize an
> RP (aka Consumer) to access protected resources hosted by the user's
> OP (aka Service Provider). It might make more sense to use the OpenID
> +OAuth hybrid protocol along with an OAuth protected web service to
> exchange contract information.
>
> Thanks
> Allen
>
>
>
>
> Nat Sakimura wrote:
>>
>> I have edited the Contract Exchange Proposal on the wiki.
>>
>> http://wiki.openid.net/Working_Groups%3AContract_Exchange_1
>>
>> It is substantially shorter and easier to parse, hopefully.
>>
>> Please discuss.
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090123/396331e2/attachment-0002.htm>
More information about the specs
mailing list