[OpenID] [OIDFSC] FW: Proposal to create the TX working group

[Peter Williams]

I'm not on the spec council and never will be; so my opinion is even less valuable than it usually is. But here are some notes:

Concerning http://wiki.openid.net/Working_Groups:Contract_Exchange_1

Can the value of one field be xml? Obviously: yes, is the answer. Inevitably, given its about contract terms aimed at binding users to agreements during websso session management, someone will put html variant of xml in one of the fields -- along with some javascript. Now, given we are specifically in an UCI environment, the IPS has to deploy deep packet inspection signatures addressing the risk of html/script hitting SPs-side critical systems in the server block. (The same is true for sreg/ax to be fair, at least in my paranoid world.) One has to assume, in a contracts problem domain where formatting is relevant to person-person legal protocols, someone will eventually deploy advanced formatting, then someone else will add DHMTL and SOAP client behaviors too or add a submit control to the HTML with auto-post javascript...all targeting the PC/phone).

The comparison with xmldsig is valid - but not because xml is the presentation syntax vs primitive character arrays. Its whether the web needs yet another standard addressing the publickey signing of tokens (SAML, ws-trust)...that specifically third parties can now verify. Its whether the web needs another ebXML style standard addressing the contract binding acknowledgment issues. Let's not  forget that this community cannot even bring itself to handle the SAML tokens that come with XRI adoption, which already bring public key and legal contracts terms (SAML advice field).

When I read the actual text,  the proposal doesn't actually say its contemplating now signing assertions with public key ciphers. I'm guessing it would want to restrict the use of public key signatures to fields communicated within a new extension. But everything about it smells like the problem set that PKI systems sought to address (discovery of keys, validation of keys, signing of blobs, canonicalization of blobs, formatting of contract blobs for mobile rendering, trusted storage of signed acknowledgements legally binding users to contracts in a legal repository... It just *sounds like* the NR/PKI problem domain.

I'd REALLY advise that folks just solve one problem at a time - one that is going to be really hard for this community all by itself: add public key crypto and asymmetric key management to assertion handling on private associations. Show public key methods can integrate with openid usefully, be limited to private associations as currently conceived, and can thus cooperate with openid without changing its character. Then, one might get the authority to address ebXML-style MEPs leveraging those highly constrained secure channels.

> -----Original Message-----
> From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Nat Sakimura
> Sent: Wednesday, December 24, 2008 12:38 AM
> To: Mike Jones
> Cc: David Recordon; specs-council at openid.net; general at openid.net
> Subject: Re: [OpenID] [OIDFSC] FW: Proposal to create the TX working
> group
>
> Hi Mike,
>
> At the same time, please revisit the comment that I have made.
>
> It is not XML that I am proposing to sign. It is a collection of tag-
> value pairs so XML DSig does not apply.
>
> If you have additional concerns, please let me know.
> The only one that I am aware of is whether to split it into two.
>
> =nat
>