No subject
Sat Jan 3 03:12:47 UTC 2009
acceptance. My idea is to use OpenID protocols to make an offer including 1
to 10 and 11 of the offering party, and if the offered party accepts it,
returns the acceptance with his portion of 11. This is just my idea, and the
details is needed to be discussed inside the WG.
Cheers,
=nat
On Sat, Jan 31, 2009 at 3:26 AM, Brad Fitzpatrick <brad at danga.com> wrote:
> Can I vote neutral? While I'm very much +1 on the previously discussed
> OpenID/OAuth hybrid proposal, this one's more "meh" to me. I'm not against
> it, though. Its charter page doesn't even explain use cases or what a
> "contact" is (though I was amused to see it put in quotes and then later
> never explained.)
> On Wed, Jan 28, 2009 at 11:09 AM, David Recordon <recordond at gmail.com>wrote:
>
>> Since we've had so many different threads on this proposal, I'd like
>> to have one final thread where there is a clear vote held on the
>> latest revision of the proposal. The proposal can be found at
>> http://wiki.openid.net/Working_Groups%3AContract_Exchange_1 and in the
>> email below. If you're a member of the Specs Council, please respond
>> ASAP.
>>
>> Thanks,
>> --David
>>
>> (i) WG name
>> Contract Exchange Extension Working Group
>>
>> (ii) Purpose
>> The purpose of this WG is to produce a standard OpenID extension to
>> the OpenID Authentication protocol that enables arbitrary parties to
>> create and exchange a mutually-digitally-signed "contract". This
>> contract can be both broadband and mobile friendly through appropriate
>> bindings that will be defined for each use case.
>>
>> (iii) Scope
>> Development of a specification that allows parties to exchange a
>> mutually-digitally-signed contract leveraging on OpenID Authentication
>> 2.0 and OpenID Attribute Exchange 2.0 via the appropriate bindings
>> defined in the specification.
>>
>> Out of scope
>>
>> * UI and user experience: The Working Group will develop the wire
>> protocol and and any related processing mechanisms required to support
>> it but user interface and experience is out of scope.
>> * Public Key Discovery method: This functionality will be either
>> defined in the XRD 1.0 specification currently in progress at the
>> OASIS XRI TC or a mechanism that works with OpenID Authentication
>> 2.0/2.1 discovery will be defined independently.
>> * Terms negotiation: Actual negotiation of the terms of a contract
>> should be dealt with out-of-band or by other specifications.
>> * Assurance: These will be handled by third-party assurance
>> programs or other identity governance frameworks.
>> * Trust hierarchies. It is the intent that this specification be
>> usable by any trust community, whether it uses conventional PKI
>> hierarchies, peer-to-peer trust mechanisms, reputation systems, or
>> other forms of trust assurance. The specification of any particular
>> trust root, trust hierarchy, or trust policy is explicitly out of
>> scope.
>>
>> (iv) Proposed List of Specifications
>> * Contract Exchange 1.0 - Expected completion of the first
>> iteration is in Q1 2009.
>>
>> (v) Anticipated audience or users of the work
>> Implementers of OpenID Providers and Relying Parties, especially those
>> who require security and accountability features to exchange sensitive
>> customer information (e.g. personally identifiable information and
>> credit card numbers) responsibly among trusted parties.
>>
>> (vi) Language in which the WG will conduct business
>> English.
>>
>> (vii) Method of work
>> E-mail discussions on the working group mailing list, working group
>> conference calls, and possibly face-to-face meetings at conferences.
>>
>> (viii) Basis for determining when the work of the WG is completed
>> Drafts will be evaluated on the basis of whether they increase or
>> decrease consensus within the working group. The work will be
>> completed once it is apparent that maximal consensus on the drafts has
>> been achieved, consistent with the purpose and scope.
>>
>> (b) Background Information.
>> (i) Related work being done by other WGs or organizations
>> * OpenID Authentication 2.1 [AN]
>> * OpenID Attribute Exchange Extension 2.0 [AX]
>> * LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft
>> * XML Advanced Electronic Signatures [XAdES]
>> * WS-Trust 1.3 [WS-trust]
>> * XRI 2.0 and XRI 3.0 [XRI]
>> * XRD 1.0 [XRI]
>> * XDI 1.0 [XDI]
>> * Vendor Relationship Management [VRM]
>>
>> (ii) Proposers
>> * Drummond Reed, =drummond, drummond.reed at parity.com,
>> Cordance/Parity/OASIS (U.S.A)
>> * Henrik Biering, hb at netamia.com, Netamia (Denmark)
>> * Hideki Nara, hdknr at ic-tact.co.jp, Tact Communications (Japan)
>> * John Bradeley, jbradley at mac.com, OASIS IDTrust Member Section
>> (Canada)
>> * Mike Graves, mgraves at janrain.com, JanRain, Inc. (U.S.A.)
>> * Nat Sakimura, n-sakimura at nri.co.jp, Nomura Research Institute,
>> Ltd.(Japan)
>> * Robert Ott, robert.ott at clavid.com, Clavid (Switzerland)
>> * Tatsuki Sakushima, tatsuki at nri.com, NRI America, Inc. (U.S.A.)
>> * Toru Yamaguchi, trymch at gmail.com, DeNA Co. Ltd. (Japan)
>>
>> Editors:
>> Nat Sakimura, n-sakimura at nri.co.jp, Nomura Research Institute, Ltd.
>>
>> (iii) Anticipated Contributions
>> * Sakimura, N., et. al "OpenID Trusted data eXchange Extention
>> Specification (draft)", Oct. 2008. [TX2008].
>>
>
>
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
--0016e64aeb4405c4bb0461c0a5f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Wow, Brad, it has been such a long time since I have seen you on the =
list!<br><br>By the way, it is "contract" and not "contact&q=
uot;. <br><br>"contract" by the way, usually is mutual agreement =
between parties. In many jurisdictions it does not have to be written down =
at all to be a valid contract. However, we usually write down the contract =
"just in case" when we have to bring it to the court. To prepare =
for such circumstances, we usually have the following items in a contract. =
(Note: not all contact have all the items below, but I consider it is gener=
ally a good practice to have them. At least, my legal department would not =
accept one if any of them is missing.) <br>
<br>1. Identifier of the parties involved. (Usually, registered name and ad=
dress.)<br>2. General purpose of the agreement. ("Preemable"). <b=
r>3. Business Term that the parties agreed to. <br>4. Expiration Date and R=
enewal method (if relevant). <br>
5. Termination Clause. <br>6. <span class=3D"wordlink">Non disclosure<br>7.=
</span><span class=3D"wordlink">Indemnity liability</span>, Remedies to da=
mage<br>8. Jurisdiction<br>9. Dispute resolution point<br>10. Date<br>11. C=
redential<br>
<br>Credential, in case of paper contract, usually is signature in the West=
ern world. In Asia, it usually is a registered seal. What makes them a vali=
d credential depends on the relevant laws and <span class=3D"wordlink">judi=
cial</span> <span class=3D"wordlink">precedents. </span><br>
<br>From the point of the workflow, as it is depicted in <a href=3D"http://=
en.wikipedia.org/wiki/Contract">http://en.wikipedia.org/wiki/Contract</a>, =
it is composed of offer and acceptance. My idea is to use OpenID protocols =
to make an offer including 1 to 10 and 11 of the offering party, and if the=
offered party accepts it, returns the acceptance with his portion of 11. T=
his is just my idea, and the details is needed to be discussed inside the W=
G. <br>
<br>Cheers, <br><br>=3Dnat<br><br><br><div class=3D"gmail_quote">On Sat, Ja=
n 31, 2009 at 3:26 AM, Brad Fitzpatrick <span dir=3D"ltr"><<a href=3D"ma=
ilto:brad at danga.com">brad at danga.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); mar=
gin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Can I vote neutral? While I'm very much +1 on the previously disc=
ussed OpenID/OAuth hybrid proposal, this one's more "meh" to =
me. I'm not against it, though. Its charter page doesn'=
t even explain use cases or what a "contact" is (though I was amu=
sed to see it put in quotes and then later never explained.)<div>
<br></div><div><div><div><div class=3D"gmail_quote"><div class=3D"Ih2E3d">O=
n Wed, Jan 28, 2009 at 11:09 AM, David Recordon <span dir=3D"ltr"><<a hr=
ef=3D"mailto:recordond at gmail.com" target=3D"_blank">recordond at gmail.com</a>=
></span> wrote:<br>
</div><div><div></div><div class=3D"Wj3C7c"><blockquote class=3D"gmail_quot=
e" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt =
0.8ex; padding-left: 1ex;">
Since we've had so many different threads on this proposal, I'd lik=
e<br>
to have one final thread where there is a clear vote held on the<br>
latest revision of the proposal. The proposal can be found at<br>
<a href=3D"http://wiki.openid.net/Working_Groups%3AContract_Exchange_1" tar=
get=3D"_blank">http://wiki.openid.net/Working_Groups%3AContract_Exchange_1<=
/a> and in the<br>
email below. If you're a member of the Specs Council, please resp=
ond<br>
ASAP.<br>
<br>
Thanks,<br>
--David<br>
<br>
(i) WG name<br>
Contract Exchange Extension Working Group<br>
<br>
(ii) Purpose<br>
The purpose of this WG is to produce a standard OpenID extension to<br>
the OpenID Authentication protocol that enables arbitrary parties to<br>
create and exchange a mutually-digitally-signed "contract". This<=
br>
contract can be both broadband and mobile friendly through appropriate<br>
bindings that will be defined for each use case.<br>
<br>
(iii) Scope<br>
Development of a specification that allows parties to exchange a<br>
mutually-digitally-signed contract leveraging on OpenID Authentication<br>
2.0 and OpenID Attribute Exchange 2.0 via the appropriate bindings<br>
defined in the specification.<br>
<br>
Out of scope<br>
<br>
* UI and user experience: The Working Group will develop the =
wire<br>
protocol and and any related processing mechanisms required to support<br>
it but user interface and experience is out of scope.<br>
* Public Key Discovery method: This functionality will be eit=
her<br>
defined in the XRD 1.0 specification currently in progress at the<br>
OASIS XRI TC or a mechanism that works with OpenID Authentication<br>
2.0/2.1 discovery will be defined independently.<br>
* Terms negotiation: Actual negotiation of the terms of a con=
tract<br>
should be dealt with out-of-band or by other specifications.<br>
* Assurance: These will be handled by third-party assurance<b=
r>
programs or other identity governance frameworks.<br>
* Trust hierarchies. It is the intent that this specification=
be<br>
usable by any trust community, whether it uses conventional PKI<br>
hierarchies, peer-to-peer trust mechanisms, reputation systems, or<br>
other forms of trust assurance. The specification of any particular<br>
trust root, trust hierarchy, or trust policy is explicitly out of<br>
scope.<br>
<br>
(iv) Proposed List of Specifications<br>
* Contract Exchange 1.0 - Expected completion of the first<br=
>
iteration is in Q1 2009.<br>
<br>
(v) Anticipated audience or users of the work<br>
Implementers of OpenID Providers and Relying Parties, especially those<br>
who require security and accountability features to exchange sensitive<br>
customer information (e.g. personally identifiable information and<br>
credit card numbers) responsibly among trusted parties.<br>
<br>
(vi) Language in which the WG will conduct business<br>
English.<br>
<br>
(vii) Method of work<br>
E-mail discussions on the working group mailing list, working group<br>
conference calls, and possibly face-to-face meetings at conferences.<br>
<br>
(viii) Basis for determining when the work of the WG is completed<br>
Drafts will be evaluated on the basis of whether they increase or<br>
decrease consensus within the working group. The work will be<br>
completed once it is apparent that maximal consensus on the drafts has<br>
been achieved, consistent with the purpose and scope.<br>
<br>
(b) Background Information.<br>
(i) Related work being done by other WGs or organizations<br>
* OpenID Authentication 2.1 [AN]<br>
* OpenID Attribute Exchange Extension 2.0 [AX]<br>
* LIberty Alliance Identity Governance Framework [IGF] 1.0 Dr=
aft<br>
* XML Advanced Electronic Signatures [XAdES]<br>
* WS-Trust 1.3 [WS-trust]<br>
* XRI 2.0 and XRI 3.0 [XRI]<br>
* XRD 1.0 [XRI]<br>
* XDI 1.0 [XDI]<br>
* Vendor Relationship Management [VRM]<br>
<br>
(ii) Proposers<br>
* Drummond Reed, =3Ddrummond, <a href=3D"mailto:drummond.reed=
@parity.com" target=3D"_blank">drummond.reed at parity.com</a>,<br>
Cordance/Parity/OASIS (U.S.A)<br>
* Henrik Biering, <a href=3D"mailto:hb at netamia.com" target=3D=
"_blank">hb at netamia.com</a>, Netamia (Denmark)<br>
* Hideki Nara, <a href=3D"mailto:hdknr at ic-tact.co.jp" target=
=3D"_blank">hdknr at ic-tact.co.jp</a>, Tact Communications (Japan)<br>
* John Bradeley, <a href=3D"mailto:jbradley at mac.com" target=
=3D"_blank">jbradley at mac.com</a>, OASIS IDTrust Member Section (Canada)<br>
* Mike Graves, <a href=3D"mailto:mgraves at janrain.com" target=
=3D"_blank">mgraves at janrain.com</a>, JanRain, Inc. (U.S.A.)<br>
* Nat Sakimura, <a href=3D"mailto:n-sakimura at nri.co.jp" targe=
t=3D"_blank">n-sakimura at nri.co.jp</a>, Nomura Research Institute, Ltd.(Japa=
n)<br>
* Robert Ott, <a href=3D"mailto:robert.ott at clavid.com" target=
=3D"_blank">robert.ott at clavid.com</a>, Clavid (Switzerland)<br>
* Tatsuki Sakushima, <a href=3D"mailto:tatsuki at nri.com" targe=
t=3D"_blank">tatsuki at nri.com</a>, NRI America, Inc. (U.S.A.)<br>
* Toru Yamaguchi, <a href=3D"mailto:trymch at gmail.com" target=
=3D"_blank">trymch at gmail.com</a>, DeNA Co. Ltd. (Japan)<br>
<br>
Editors:<br>
Nat Sakimura, <a href=3D"mailto:n-sakimura at nri.co.jp" target=3D"_blank">n-s=
akimura at nri.co.jp</a>, Nomura Research Institute, Ltd.<br>
<br>
(iii) Anticipated Contributions<br>
* Sakimura, N., et. al "OpenID Trusted data eXchange Ext=
ention<br>
Specification (draft)", Oct. 2008. [TX2008].<br>
</blockquote></div></div></div><br></div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Nat Sakimura (=3Dnat)<b=
r><a href=3D"http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><b=
r>
--0016e64aeb4405c4bb0461c0a5f3--
More information about the specs-council
mailing list