[Specs-cx] Exact meaning of /Contract/Party/URL

nara hideki hdknr at ic-tact.co.jp
Mon Apr 19 04:12:19 UTC 2010


Hi, David,

Thank you for your words. I think you're very welcome.
I'm not quite sure right now what other contributors say.

XML Signature's security matters should not be discussed too much
in this spec. But I think that  the relation of  an identity and the
certificate' subject
should be stated precisely.

2010/4/16 David García <david.garcia at tractis.com>:
> Hi Nara,
>
> we can define certificate requirements whenever you want :) .
>
> We can also check how qcStatement from http://www.ietf.org/rfc/rfc3739.txt
> on qualified certificates can help us on determining Contract Price .  This
> extension is widely used and defines the monetary boundary where those types
> certificates could be used) .
>
> Maybe we could create a topic about the certificates used by parties to sign
> contracts. I'll be very pleased If I could help.
>
> Best regards
>
> Dave
>
> 2010/4/16 nara hideki <hdknr at ic-tact.co.jp>
>>
>> Hello, David,
>>
>> Thank you very much for your right information.
>> We should describe this kind of verification for certificate and keys
>> in some way in the spec.
>>
>> Thank you.
>> ----
>> hdknr
>>
>> 2010/4/15 David García <david.garcia at tractis.com>:
>> > Hi Nara,
>> >
>> > when signing a contract maybe it would be good to check the keyusage
>> > extension from the signing certificate in order to know is issuer
>> > determined
>> > that this certificate could be used on digital signature procedures.
>> >
>> > In this context maybe an certificate used to create SSL channels may not
>> > include those usages.  Using those certificates with wrong key usage on
>> > agreements could not be semantically correct regarding to the definition
>> > of
>> > this extension.
>> >
>> > Best regards
>> >
>> > Dave
>> >
>> >
>> >
>> > 2010/4/15 nara hideki <hdknr at ic-tact.co.jp>
>> >>
>> >> Hi,all
>> >>
>> >> I think we should define the meaning of /Contract/Party/URL element
>> >> more precisely.
>> >>
>> >> 1. for OP
>> >>
>> >> This may be easy to define.  If someone discovery this URL,  the OP
>> >> should return a XRDS/XDS
>> >> which include the CX service endpoint used for this Contract as far as
>> >> the contract is
>> >> effective and in the term of validity.
>> >>
>> >> The certificate used for HTTPS connection seems to be equal to the one
>> >> used for singing
>> >> the Contract XML.
>> >>
>> >> 2. for RP
>> >>
>> >> The RP also should  return the XRDS/XRD describe himself.
>> >> The certificate used for HTTPS connection also seems to be equal to
>> >> the one used for singing
>> >> the Contract(Proposal) XML.
>> >>
>> >> 3. for End User(s)
>> >>
>> >> I think this is URL(XRI) of the End User who accepted the contract. So
>> >> this should be the
>> >> OP local identifier which could be a PPID ( pairwise pseudo
>> >> identifier).
>> >> This should return the XRDS/XRD describing the End User.
>> >> If he is the signer,  the public key should be while-listed or
>> >> registered at the proposing party.
>> >>
>> >> Any suggestions  please.
>> >> ----
>> >> hdknr
>> >> _______________________________________________
>> >> Specs-cx mailing list
>> >> Specs-cx at lists.openid.net
>> >> http://lists.openid.net/mailman/listinfo/openid-specs-cx
>> >
>> >
>> >
>> > --
>> > David Garcia
>> > CTO
>> > Tractis - Online contracts you can enforce
>> > http://www.tractis.com
>> > --
>> > Email: david.garcia at tractis.com
>> > Skype: deiffbcn
>> > Blog: http://blog.negonation.com
>> > Linkedin: http://www.linkedin.com/in/davebcn
>> >
>> >
>> >
>
>
>
> --
> David Garcia
> CTO
> Tractis - Online contracts you can enforce
> http://www.tractis.com
> --
> Email: david.garcia at tractis.com
> Skype: deiffbcn
> Blog: http://blog.negonation.com
> Linkedin: http://www.linkedin.com/in/davebcn
>
>
>


More information about the Specs-cx mailing list