openid / contract-exchange-extension Goto Github PK

JSON vars cannot have new lines in the values.

Perhaps base64url encoded DER instead of PEM for certs?

Put an XML example in the Appendix.

Perhaps one for the Proposal and one for the returned contract.

Perhaps Drummond et al. may want to create an XDI example for the contract document.

The same applies to JSON.

Should we try one?

Posted ML as http://bit.ly/9OSzNQ

• What this URL means.
• Relation between , Party entity, what URL returns , and the certificate for the signature
• some considerations for Issue 14
• others.

Submitted as http://lists.openid.net/pipermail/openid-specs-cx/2010-April/000076.html

• Drop Service/Party/TemplateURI
• The URI must be specified in a XRD/Service/Type element value.

• /Contract/Party/id seems to be equal to /Contrat/Party/URL. "id" is better ?
• id or @id ?
• id is OpenID ? or X.509 Subject?

As David García write in http://bit.ly/cPS93H, the key usage extension should be checked for X.509 certifcate.

There could be more items for certificate verification and may be noted somewhere in the spec.

In the case of payment:

1. End User buys somehting at RP
2. RP proposes CX contract to OP
3. End User visits OP with the artifact of the contract.
4. End User authenticates and browses the detail of the contract before he/she pays.

If the contract binds all there party, the consideration between RP and OP SHOULD be shown to the End User. For example, because 7 $ ,7% commission of total amount of 100$ payment from the End User to RP thought OP MUST be dedicated by OP, RP will be paid 93$ by OP.

Is it right ? For usual credit card payment in Internet, we usually don't know about commission between the net shop and the payment agency.

This seems to be important to define of the OP and CX Template for the contract.

I clicked the wrong button...

In the examples such as the one in 3.2.4, a variable "identifier" appears, but it is not defined. Perhaps "identity"?

For example, 3.2.2. Request just states the data format and variables without stating what it is for. Unless it states what it is for, it would be very difficult to understand.

Right now, it is stated as

http://example.com/template.txt#sha256:template_hash

but is it not better to be like

http://example.com/template.txt?sha256=template_hash ?

Add Cardinality to the elements and attributes of XML.

If the CX Service URI must be CX Template URI, /Contract/Service/Type and /Contract/TemplateURI are verbose.

We can drop /Contract/TemplateURI and mote /Contract/Template to /Contract/Service/Template.

The attribute exchange namespace “http://openid.net/srv/cx/1.0/#” MUST 
be listed as /xrds/xrd/Service/Type element in the XRDS discovery 
document or /xrd/Link/rel element in the XRD 1.0 discovery document.

• attribute exchange => contract exchange
• Number sign seems unnecessary

Create XML Schema for CX XML Binding.

Described in a message submitted to SPEC-CX.
( http://lists.openid.net/pipermail/openid-specs-cx/2010-April/000079.html )

SHA-256 digest is not for the ownership for the template.

• Realm for CX Service URI. If the URI is of OP, there seems to be no problem for the OP to accept the proposal.
• Digital signature to the template. We must provide some structured format including digital signature like CX Contract XML.
• OP can use CX service whitelist /blacklist for accepting a proposal. But this is a development matter and should not be a protocol part.

Scott's document had one. We are missing it now.

I'm not quite sure what "AX Request" means.

AX Request

* description: Used to convey the data that the requester requests.
* type URL: http://opneid.net/srv/cx/1.0#axreq
* value: Attribute Exchange 1.1 string in tag=value&tag=value format as in X1.1
* Conformance: MUST support.

I think that because a RP has already known the contract to be completed is about for a "attribute exchange" thing, a CX Proposal for AX fetch request looks like this :

<Party>
    <URL>http://yoursocial.com</URL>
    <Rel>http://openid.net/srv/cx/1.0/#proposer</Rel>
    <obligations>
    <!-- querying OpenID AX fetch parameter -->
        <param type="http://axschema.org/namePerson/first" id="first_name"></param>
        <param type="http://axschema.org/namePerson/last"  id="last_name"></param>
        <param type="http://axschema.org/contact/email" id="email"></param>
    </obligations>
</Party>

And the OP will return the CX Contract including value for each claimed paramters in obligation/param elements.

Am I missing anything important ?

Described in a message submitted to SPEC-CX.

• another party type of /Contract/Party/Rel
• "proxy signature" like information holding End User's identifier.