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].

Search Discussions

  • David Recordon at Jan 28, 2009 at 11:11 am
    +1 to recommending this working group proposal.
    On Wed, Jan 28, 2009 at 11:09 AM, David Recordon 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].
  • Mike Jones at Jan 29, 2009 at 5:39 pm
    With these changes, +1.

    -- Mike

    -----Original Message-----
    From: David Recordon [mailto:recordond at gmail.com]
    Sent: Wednesday, January 28, 2009 11:12 AM
    To: Brad Fitzpatrick; Dick Hardt; Mike Jones; Johnny Bufu; Josh Hoyt; Allen Tom
    Cc: specs-council at openid.net
    Subject: Re: [VOTE] Contract Exchange Working Group Proposal

    +1 to recommending this working group proposal.
    On Wed, Jan 28, 2009 at 11:09 AM, David Recordon 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].
  • Allen Tom at Jan 29, 2009 at 6:20 pm
    +1

    Definitely would like to be supportive of all the very advanced use
    cases for OpenID in Japan. Hopefully CX wan be used as a reference for
    the rest of the world when we catch up.

    Allen

    Mike Jones wrote:
    With these changes, +1.

    -- Mike

    -----Original Message-----
    From: David Recordon [mailto:recordond at gmail.com]
    Sent: Wednesday, January 28, 2009 11:12 AM
    To: Brad Fitzpatrick; Dick Hardt; Mike Jones; Johnny Bufu; Josh Hoyt; Allen Tom
    Cc: specs-council at openid.net
    Subject: Re: [VOTE] Contract Exchange Working Group Proposal

    +1 to recommending this working group proposal.
    On Wed, Jan 28, 2009 at 11:09 AM, David Recordon 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].
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://openid.net/pipermail/specs-council/attachments/20090129/7922f9b8/attachment.htm>
  • Josh Hoyt at Jan 30, 2009 at 12:58 am
    +1

    Josh
  • Dick Hardt at Feb 2, 2009 at 9:17 pm
    +1
    On 29-Jan-09, at 6:20 PM, Allen Tom wrote:

    +1

    Definitely would like to be supportive of all the very advanced use
    cases for OpenID in Japan. Hopefully CX wan be used as a reference
    for the rest of the world when we catch up.

    Allen

    Mike Jones wrote:
    With these changes, +1.

    -- Mike

    -----Original Message-----
    From: David Recordon [mailto:recordond at gmail.com]
    Sent: Wednesday, January 28, 2009 11:12 AM
    To: Brad Fitzpatrick; Dick Hardt; Mike Jones; Johnny Bufu; Josh
    Hoyt; Allen Tom
    Cc: specs-council at openid.net
    Subject: Re: [VOTE] Contract Exchange Working Group Proposal

    +1 to recommending this working group proposal.

    On Wed, Jan 28, 2009 at 11:09 AM, David Recordon
    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].
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://openid.net/pipermail/specs-council/attachments/20090202/69fa7b63/attachment.htm>
  • Brad Fitzpatrick at Jan 30, 2009 at 10:26 am
    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 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].
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://openid.net/pipermail/specs-council/attachments/20090130/8d4874f8/attachment-0001.htm>
  • Mike Jones at Jan 30, 2009 at 3:14 pm
    I believe that abstaining is acceptable.

    -- Mike

    From: specs-council-bounces at openid.net [mailto:specs-council-bounces at openid.net] On Behalf Of Brad Fitzpatrick
    Sent: Friday, January 30, 2009 10:26 AM
    To: David Recordon
    Cc: Johnny Bufu; Allen Tom; Mike Jones; specs-council at openid.net; Josh Hoyt; Dick Hardt
    Subject: Re: [OIDFSC] [VOTE] Contract Exchange Working Group Proposal

    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.comwrote:
    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<mailto:drummond.reed at parity.com>,
    Cordance/Parity/OASIS (U.S.A)
    * Henrik Biering, hb at netamia.com<mailto:hb at netamia.com>, Netamia (Denmark)
    * Hideki Nara, hdknr at ic-tact.co.jp<mailto:hdknr at ic-tact.co.jp>, Tact Communications (Japan)
    * John Bradeley, jbradley at mac.com<mailto:jbradley at mac.com>, OASIS IDTrust Member Section (Canada)
    * Mike Graves, mgraves at janrain.com<mailto:mgraves at janrain.com>, JanRain, Inc. (U.S.A.)
    * Nat Sakimura, n-sakimura at nri.co.jp<mailto:n-sakimura at nri.co.jp>, Nomura Research Institute, Ltd.(Japan)
    * Robert Ott, robert.ott at clavid.com<mailto:robert.ott at clavid.com>, Clavid (Switzerland)
    * Tatsuki Sakushima, tatsuki at nri.com<mailto:tatsuki at nri.com>, NRI America, Inc. (U.S.A.)
    * Toru Yamaguchi, trymch at gmail.com<mailto:trymch at gmail.com>, DeNA Co. Ltd. (Japan)

    Editors:
    Nat Sakimura, n-sakimura at nri.co.jp<mailto: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].

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://openid.net/pipermail/specs-council/attachments/20090130/3f3b5b7e/attachment.htm>
  • Nat Sakimura at Jan 30, 2009 at 9:32 pm
    Wow, Brad, it has been such a long time since I have seen you on the list!

    By the way, it is "contract" and not "contact".

    "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 generally a good practice to have them. At
    least, my legal department would not accept one if any of them is missing.)

    1. Identifier of the parties involved. (Usually, registered name and
    address.)
    2. General purpose of the agreement. ("Preemable").
    3. Business Term that the parties agreed to.
    4. Expiration Date and Renewal method (if relevant).
    5. Termination Clause.
    6. Non disclosure
    7. Indemnity liability, Remedies to damage
    8. Jurisdiction
    9. Dispute resolution point
    10. Date
    11. Credential

    Credential, in case of paper contract, usually is signature in the Western
    world. In Asia, it usually is a registered seal. What makes them a valid
    credential depends on the relevant laws and judicial precedents.


    From bogus@does.not.exist.com Fri Jan 2 19:12:47 2009
    From: bogus@does.not.exist.com ()
    Date: Sat, 03 Jan 2009 03:12:47 -0000
    Subject: No subject
    Message-ID: <mailman.2.1233379944.22450.specs-council@openid.net>

    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 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 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,&nbsp; it has been such a long time since I have seen you on the list!<br><br>By the way, it is &quot;contract&quot; and not &quot;contact&quot;. <br><br>&quot;contract&quot; 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 &quot;just in case&quot; 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 generally 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 address.)<br>2. General purpose of the agreement. (&quot;Preemable&quot;). <br>3. Business Term that the parties agreed to. <br>4. Expiration Date and Renewal method (if relevant). <br>
    5. Termination Clause. <br>6. <span class="wordlink">Non disclosure<br>7. </span><span class="wordlink">Indemnity liability</span>, Remedies to damage<br>8. Jurisdiction<br>9. Dispute resolution point<br>10. Date<br>11. Credential<br>
    <br>Credential, in case of paper contract, usually is signature in the Western world. In Asia, it usually is a registered seal. What makes them a valid credential depends on the relevant laws and <span class="wordlink">judicial</span> <span class="wordlink">precedents. </span><br>
    <br>From the point of the workflow, as it is depicted in <a href="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. This is just my idea, and the details is needed to be discussed inside the WG. <br>
    <br>Cheers, <br><br>=nat<br><br><br><div class="gmail_quote">On Sat, Jan 31, 2009 at 3:26 AM, Brad Fitzpatrick <span dir="ltr">&lt;<a href="mailto:brad at danga.com">brad at danga.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    Can I vote neutral? &nbsp;While I&#39;m very much +1 on the previously discussed OpenID/OAuth hybrid proposal, this one&#39;s more &quot;meh&quot; to me. &nbsp;I&#39;m not against it, though. &nbsp;Its charter page doesn&#39;t even explain use cases or what a &quot;contact&quot; is (though I was amused to see it put in quotes and then later never explained.)<div>

    <br></div><div><div><div><div class="gmail_quote"><div class="Ih2E3d">On Wed, Jan 28, 2009 at 11:09 AM, David Recordon <span dir="ltr">&lt;<a href="mailto:recordond at gmail.com" target="_blank">recordond at gmail.com</a>&gt;</span> wrote:<br>
    </div><div><div></div><div class="Wj3C7c"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    Since we&#39;ve had so many different threads on this proposal, I&#39;d like<br>
    to have one final thread where there is a clear vote held on the<br>
    latest revision of the proposal. &nbsp;The proposal can be found at<br>
    <a href="http://wiki.openid.net/Working_Groups%3AContract_Exchange_1" target="_blank">http://wiki.openid.net/Working_Groups%3AContract_Exchange_1</a> and in the<br>
    email below. &nbsp;If you&#39;re a member of the Specs Council, please respond<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 &quot;contract&quot;. 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>
    &nbsp; &nbsp;* 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>
    &nbsp; &nbsp;* Public Key Discovery method: This functionality will be either<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>
    &nbsp; &nbsp;* Terms negotiation: Actual negotiation of the terms of a contract<br>
    should be dealt with out-of-band or by other specifications.<br>
    &nbsp; &nbsp;* Assurance: These will be handled by third-party assurance<br>
    programs or other identity governance frameworks.<br>
    &nbsp; &nbsp;* 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>
    &nbsp; &nbsp;* 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>
    &nbsp; &nbsp;* OpenID Authentication 2.1 [AN]<br>
    &nbsp; &nbsp;* OpenID Attribute Exchange Extension 2.0 [AX]<br>
    &nbsp; &nbsp;* LIberty Alliance Identity Governance Framework [IGF] 1.0 Draft<br>
    &nbsp; &nbsp;* XML Advanced Electronic Signatures [XAdES]<br>
    &nbsp; &nbsp;* WS-Trust 1.3 [WS-trust]<br>
    &nbsp; &nbsp;* XRI 2.0 and XRI 3.0 [XRI]<br>
    &nbsp; &nbsp;* XRD 1.0 [XRI]<br>
    &nbsp; &nbsp;* XDI 1.0 [XDI]<br>
    &nbsp; &nbsp;* Vendor Relationship Management [VRM]<br>
    <br>
    (ii) Proposers<br>
    &nbsp; &nbsp;* Drummond Reed, =drummond, <a href="mailto:drummond.reed@parity.com" target="_blank">drummond.reed at parity.com</a>,<br>
    Cordance/Parity/OASIS (U.S.A)<br>
    &nbsp; &nbsp;* Henrik Biering, <a href="mailto:hb at netamia.com" target="_blank">hb at netamia.com</a>, Netamia (Denmark)<br>
    &nbsp; &nbsp;* Hideki Nara, <a href="mailto:hdknr at ic-tact.co.jp" target="_blank">hdknr at ic-tact.co.jp</a>, Tact Communications (Japan)<br>
    &nbsp; &nbsp;* John Bradeley, <a href="mailto:jbradley at mac.com" target="_blank">jbradley at mac.com</a>, OASIS IDTrust Member Section (Canada)<br>
    &nbsp; &nbsp;* Mike Graves, <a href="mailto:mgraves at janrain.com" target="_blank">mgraves at janrain.com</a>, JanRain, Inc. (U.S.A.)<br>
    &nbsp; &nbsp;* Nat Sakimura, <a href="mailto:n-sakimura at nri.co.jp" target="_blank">n-sakimura at nri.co.jp</a>, Nomura Research Institute, Ltd.(Japan)<br>
    &nbsp; &nbsp;* Robert Ott, <a href="mailto:robert.ott at clavid.com" target="_blank">robert.ott at clavid.com</a>, Clavid (Switzerland)<br>
    &nbsp; &nbsp;* Tatsuki Sakushima, <a href="mailto:tatsuki at nri.com" target="_blank">tatsuki at nri.com</a>, NRI America, Inc. (U.S.A.)<br>
    &nbsp; &nbsp;* Toru Yamaguchi, <a href="mailto:trymch at gmail.com" target="_blank">trymch at gmail.com</a>, DeNA Co. Ltd. &nbsp;(Japan)<br>
    <br>
    Editors:<br>
    Nat Sakimura, <a href="mailto:n-sakimura at nri.co.jp" target="_blank">n-sakimura at nri.co.jp</a>, Nomura Research Institute, Ltd.<br>
    <br>
    (iii) Anticipated Contributions<br>
    &nbsp; &nbsp;* Sakimura, N., et. al &quot;OpenID Trusted data eXchange Extention<br>
    Specification (draft)&quot;, Oct. 2008. [TX2008].<br>
    </blockquote></div></div></div><br></div></div></div>
    </blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>

    --0016e64aeb4405c4bb0461c0a5f3--
  • Brad Fitzpatrick at Jan 31, 2009 at 12:16 pm
    Oh, a legal contract. I was assuming this was some interface exchange
    thing. (programming contract)
    So what does this enable? Can you add a few motivational sentences to the
    Working Group proposal URL so people can get more excited about it?
    (perhaps you're all very excited, but it didn't do much for me as
    written...)

    On Fri, Jan 30, 2009 at 9:32 PM, Nat Sakimura wrote:

    Wow, Brad, it has been such a long time since I have seen you on the list!

    By the way, it is "contract" and not "contact".

    "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 generally a good practice to have them. At
    least, my legal department would not accept one if any of them is missing.)

    1. Identifier of the parties involved. (Usually, registered name and
    address.)
    2. General purpose of the agreement. ("Preemable").
    3. Business Term that the parties agreed to.
    4. Expiration Date and Renewal method (if relevant).
    5. Termination Clause.
    6. Non disclosure
    7. Indemnity liability, Remedies to damage
    8. Jurisdiction
    9. Dispute resolution point
    10. Date
    11. Credential

    Credential, in case of paper contract, usually is signature in the Western
    world. In Asia, it usually is a registered seal. What makes them a valid
    credential depends on the relevant laws and judicial precedents.

    From the point of the workflow, as it is depicted in
    http://en.wikipedia.org/wiki/Contract, 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. 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 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 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/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://openid.net/pipermail/specs-council/attachments/20090131/4fb5fe1f/attachment.htm>
  • Allen Tom at Feb 1, 2009 at 9:42 am
    Hi Nat,

    Please be sure to clearly define the term "Contract" in the spec, and it
    would be good to describe some usecases either in the appendix or have
    the spec link to a separate document with some usecases. One of the
    reasons why the specs committee took so long to vote on the CX proposal
    is because of a general lack of understanding as to what CX is supposed
    to do.

    Allen


    Nat Sakimura wrote:
    Wow, Brad, it has been such a long time since I have seen you on the
    list!

    By the way, it is "contract" and not "contact".

    "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
    generally a good practice to have them. At least, my legal department
    would not accept one if any of them is missing.)

    1. Identifier of the parties involved. (Usually, registered name and
    address.)
    2. General purpose of the agreement. ("Preemable").
    3. Business Term that the parties agreed to.
    4. Expiration Date and Renewal method (if relevant).
    5. Termination Clause.
    6. Non disclosure
    7. Indemnity liability, Remedies to damage
    8. Jurisdiction
    9. Dispute resolution point
    10. Date
    11. Credential

    Credential, in case of paper contract, usually is signature in the
    Western world. In Asia, it usually is a registered seal. What makes
    them a valid credential depends on the relevant laws and judicial
    precedents.

    From the point of the workflow, as it is depicted in
    http://en.wikipedia.org/wiki/Contract, 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. 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
    <mailto:drummond.reed at parity.com>,
    Cordance/Parity/OASIS (U.S.A)
    * Henrik Biering, hb at netamia.com <mailto:hb at netamia.com>,
    Netamia (Denmark)
    * Hideki Nara, hdknr at ic-tact.co.jp
    <mailto:hdknr at ic-tact.co.jp>, Tact Communications (Japan)
    * John Bradeley, jbradley at mac.com
    <mailto:jbradley at mac.com>, OASIS IDTrust Member Section (Canada)
    * Mike Graves, mgraves at janrain.com
    <mailto:mgraves at janrain.com>, JanRain, Inc. (U.S.A.)
    * Nat Sakimura, n-sakimura at nri.co.jp
    <mailto:n-sakimura at nri.co.jp>, Nomura Research Institute,
    Ltd.(Japan)
    * Robert Ott, robert.ott at clavid.com
    <mailto:robert.ott at clavid.com>, Clavid (Switzerland)
    * Tatsuki Sakushima, tatsuki at nri.com
    <mailto:tatsuki at nri.com>, NRI America, Inc. (U.S.A.)
    * Toru Yamaguchi, trymch at gmail.com
    <mailto:trymch at gmail.com>, DeNA Co. Ltd. (Japan)

    Editors:
    Nat Sakimura, n-sakimura at nri.co.jp
    <mailto: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/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://openid.net/pipermail/specs-council/attachments/20090201/1c420885/attachment-0001.htm>
  • Nat at Feb 2, 2009 at 6:52 am
    Yes. After all, it is all about contract. The spec will be very clear
    on it. Also, I think the WG will produce a usecase and requirement
    document a la OASIS Style.

    =nat at TOKYO via iPhone
    On 2009/02/02, at 2:42, Allen Tom wrote:

    Hi Nat,

    Please be sure to clearly define the term "Contract" in the spec,
    and it would be good to describe some usecases either in the
    appendix or have the spec link to a separate document with some
    usecases. One of the reasons why the specs committee took so long
    to vote on the CX proposal is because of a general lack of
    understanding as to what CX is supposed to do.

    Allen


    Nat Sakimura wrote:
    Wow, Brad, it has been such a long time since I have seen you on
    the list!

    By the way, it is "contract" and not "contact".

    "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 generally a good practice to have them. At least, my
    legal department would not accept one if any of them is missing.)

    1. Identifier of the parties involved. (Usually, registered name
    and address.)
    2. General purpose of the agreement. ("Preemable").
    3. Business Term that the parties agreed to.
    4. Expiration Date and Renewal method (if relevant).
    5. Termination Clause.
    6. Non disclosure
    7. Indemnity liability, Remedies to damage
    8. Jurisdiction
    9. Dispute resolution point
    10. Date
    11. Credential

    Credential, in case of paper contract, usually is signature in the
    Western world. In Asia, it usually is a registered seal. What makes
    them a valid credential depends on the relevant laws and judicial
    precedents.

    From the point of the workflow, as it is depicted in http://en.wikipedia.org/wiki/Contract
    , 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. 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
    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/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://openid.net/pipermail/specs-council/attachments/20090202/5b841b5c/attachment.htm>
  • David Recordon at Jan 31, 2009 at 2:00 pm
    Thanks, with the following votes I will consider this proposal as recommended.

    +1:
    - David
    - Mike
    - Josh
    - Allen

    +0:
    - Brad

    Absent:
    - Dick
    - Johnny
    On Wed, Jan 28, 2009 at 11:09 AM, David Recordon 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].

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupopenid-specs-council @
categoriesopenid
postedJan 28, '09 at 11:09a
activeFeb 2, '09 at 9:17p
posts13
users7
websiteopenid.net
irc#openid

People

Translate

site design / logo © 2021 Grokbase