<br><br><div class="gmail_quote">On Thu, Dec 25, 2008 at 12:58 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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:</blockquote><div><br></div><div>The voice of the community is very important, though. As far as I understood, the spec committee's role is the process management and risk control. It is more of the role of TC admins in the OASIS Open. This is evident from the rather restrictive causes for rejecting a proposal. It states only four possible reasons: </div>
<div><br></div><div><span class="Apple-style-span" style="border-collapse: collapse; "><div dir="ltr"><font face="Arial" size="2">(a) an incomplete Proposal (i.e., failure to comply with §4.1);<br>(b) a determination that the proposal contravenes the OpenID community's purpose;<br>
(c) a determination that the proposed WG does not have sufficient support to succeed</font></div><div dir="ltr"><font face="Arial" size="2"><font face="arial"> </font>or to deliver proposed deliverables within projected completion dates; or<br>
(d) a determination that the proposal is likely to cause legal liability for the OIDF or others. <br></font></div><div dir="ltr"><br></div><div dir="ltr">Clearly, (a) is a process formality. (b), (c) and (d) states that "a determination" so it needs to demonstrate that it was concluded so deterministically, i.e., the committee needs to produce an objective proof. </div>
<div dir="ltr"><br></div><div dir="ltr">To see what would (b) means, we probably should look at the OpenID Foundation Charter. According to the charter, "<span class="Apple-style-span" style="border-collapse: separate; color: rgb(68, 68, 68); font-family: 'Segoe UI'; line-height: 19px; ">The Foundation shall facilitate the development of the open public specifications defining the OpenID framework for user-centric identity. " </span><span class="Apple-style-span" style="border-collapse: separate; color: rgb(68, 68, 68); line-height: 19px; "><span class="Apple-style-span" style="font-family: arial, helvetica, sans-serif;">So, "contravenes" probably means it is either "not open" or "not public (e.g., not royalty free)" or "not user-centric identity framework." </span></span></div>
<div dir="ltr"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(68, 68, 68); line-height: 19px;"><br></span></div><div dir="ltr"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(68, 68, 68); line-height: 19px; "><span class="Apple-style-span" style="font-family: arial, helvetica, sans-serif;">Half of (c) is a project management criteria. It means that the proposed WG has not enough work resource available. The other half is the deployment criteria. If nobody is going to deploy it, there is no point in making the spec. </span></span></div>
<div dir="ltr"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(68, 68, 68); line-height: 19px;"><br></span></div><div dir="ltr"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(68, 68, 68); line-height: 19px; "><span class="Apple-style-span" style="font-family: arial, helvetica, sans-serif;">(d) is a risk management criteria. <span class="Apple-style-span" style="border-collapse: collapse; color: rgb(0, 0, 0); line-height: normal; "> Actually, it probably is better handled by a legal advisory (IP lawyers) than the spec committee.</span></span></span></div>
</span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Concerning <a href="http://wiki.openid.net/Working_Groups:Contract_Exchange_1" target="_blank">http://wiki.openid.net/Working_Groups:Contract_Exchange_1</a><br>
<br>
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 </blockquote>
<div><br></div><div>Yes. From an implementation point of view, proper sanitization is a must but that is true for anything else as you have correctly pointed out. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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).<br>
<br>
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 </blockquote>
<div><br></div><div>Think of it as a tag-value representation / profile of some of them, paraphrased. </div><div>This community has a lot of liking towards tag-value and dislike against XML, as I observe. </div><div>If it liked the elegance and complexity of SAML, then it could have used SAML instead of creating tag-value based assertion. It could essentially achieve the same thing by defining URI based identifier and discovery but we did not go that way. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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).</blockquote>
<div><br></div><div>And XRI TC is feeling the pain acutely. When we have first developed SAML Trusted Resolution, we anticipated that the libraries would be much more readily available in various platforms. Unfortunately, it was a false assumption. Thus, the TC is now considering simpler form of signing with minimal (if any) amount of canonicalization. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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. </blockquote>
<div><br></div><div>It is a PK(I) based system. It is leveraging on the existing PK(I) systems. "I" being in a bracket signifies that it is optional, though. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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 </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">openid usefully, be limited to private associations as currently conceived, and can thus </blockquote><div><br></div><div>
It is definitely coming. I actually expect it to be a part of forthcoming OpenID AuthN 2.1. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">cooperate with openid without changing its character. Then, one might get the authority to address ebXML-style MEPs leveraging those highly constrained secure channels.</blockquote>
<div><br></div><div>It is just my opinion, but OpenID community is more practical than systemic/abstract/logical. Implementations goes first, and I like that pattern. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<div class="Ih2E3d"><br>
> -----Original Message-----<br>
> From: <a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a> [mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>] On<br>
> Behalf Of Nat Sakimura<br>
</div><div class="Ih2E3d">> Sent: Wednesday, December 24, 2008 12:38 AM<br>
> To: Mike Jones<br>
> Cc: David Recordon; <a href="mailto:specs-council@openid.net">specs-council@openid.net</a>; <a href="mailto:general@openid.net">general@openid.net</a><br>
> Subject: Re: [OpenID] [OIDFSC] FW: Proposal to create the TX working<br>
> group<br>
><br>
</div><div class="Ih2E3d">> Hi Mike,<br>
><br>
> At the same time, please revisit the comment that I have made.<br>
><br>
> It is not XML that I am proposing to sign. It is a collection of tag-<br>
> value pairs so XML DSig does not apply.<br>
><br>
> If you have additional concerns, please let me know.<br>
> The only one that I am aware of is whether to split it into two.<br>
><br>
> =nat<br>
><br>
<br>
</div><div><div></div><div class="Wj3C7c">_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</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>