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

Wed Dec 24 19:07:52 UTC 2008

On Thu, Dec 25, 2008 at 12:58 AM, Peter Williams <pwilliams at rapattoni.com>wrote:

> 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:

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:

(a)    an incomplete Proposal (i.e., failure to comply with §4.1);
(b)    a determination that the proposal contravenes the OpenID community's
purpose;
(c)    a determination that the proposed WG does not have sufficient support
to succeed
         or to deliver proposed deliverables within projected completion
dates; or
(d)    a  determination that the proposal is likely to cause legal liability
for the OIDF or others.

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.

To see what would (b) means, we probably should look at the OpenID
Foundation Charter. According to the charter, "The Foundation shall
facilitate the development of the open public specifications defining the
OpenID framework for user-centric identity. " So, "contravenes" probably
means it is either "not open" or "not public (e.g., not royalty free)" or
"not user-centric identity framework."

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.

(d) is a risk management criteria.  Actually, it probably is better handled
by a legal advisory (IP lawyers) than the spec committee.

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

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.

> 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

Think of it as a tag-value representation / profile of some of them,
paraphrased.
This community has a lot of liking towards tag-value and dislike against
XML, as I observe.
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.

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

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.

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

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.

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

It is definitely coming. I actually expect it to be a part of forthcoming
OpenID AuthN 2.1.

> cooperate with openid without changing its character. Then, one might get
> the authority to address ebXML-style MEPs leveraging those highly
> constrained secure channels.

It is just my opinion, but OpenID community is more practical than
systemic/abstract/logical. Implementations goes first, and I like that
pattern.

>
>
> > -----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
> >
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081225/25163a24/attachment-0002.htm>