[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Very rough algorithm outline
Will,
You make a compelling case that the problem is a practical one of insuring
that XRD libraries exist everywhere they are needed, and not that there are
any flaws in XML dSig or that it is fundamentally too hard to implement.
I have read the whole recent "Signing method for XRD" thread on the OpenID
list and it doesn't sway me one way or the other, i.e., even those who would
appear to favor a super-simple solution appeared to understand the value of
a super-standard solution.
Since I have no other bias, I personally am tempted to agree with you that
the fastest way from here to there is to adopt a single XRD signing method
that will represent the least TOTAL EFFORT in achieving ubiquitous adoption
of secure XRD libraries, spec it, and then concentrate our adoption efforts
on delivering those libraries everywhere they are needed.
That's my proposed strawman for discussion going into tomorrow's telecon.
I'll send the agenda next.
=Drummond
> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Wednesday, June 17, 2009 12:52 PM
> To: XRI TC
> Subject: Re: [xri] Very rough algorithm outline
>
> Believe me, I agree that for this (or any) spec to get any real
> adoption, it must have real world implementations. And where
> implementations don't already exist, it should be possible to write
> new libraries without an unreasonable amount of effort. But just
> because one implementation in one language doesn't work, that is no
> reason to throw the baby out with the bath water (American phrase).
> Of course, I fully expect that we're going to see this at least a few
> more times... where we don't have existing implementations in some
> languages, or the ones we have are broken. But seriously, this is a
> really straightforward problem with a really straightforward solution
> -- let's write some code!
>
> If people were arguing against the security or efficacy of the DSig
> spec, I might be able to understand that. But the only thing that
> appears to be holding people back is lack of language support. How
> many XRD libraries do we have in the world today? As far as I know,
> none. I have a PHP implementation that needs some updating, and I'm
> currently working on the Java implementation, but we have no complete
> libraries (which makes perfect sense). So who is going to write the
> XRD library in Ruby, Python, Objective C, etc? Well, if this plays
> out like everything else has for the last 20 years, it'll be the
> people who actually need it. Maybe that's a big corporation like
> Google or Yahoo!, maybe it's a small startup like JanRain. But new
> libraries are going to *have* to be written, and someone is going to
> have to write them. So for languages that lack good DSig support,
> let's just factor it into the scope of work for writing the XRD library.
>
> Take a look at the corporate board members of the OpenID foundation.
> Those seven companies each paid $50,000 for their seat on the board.
> But they're not willing to pay one developer a couple of weeks pay to
> write or fix an XML DSig implementation. If each company picked just
> one language, we'd be set. I was working on the PHP XRD library on
> Vidoop's dime. Now I'm doing the Java implementation as part of a
> contract paid for by Internet2 (and other sponsors, I believe).
> What's holding others back? We've still got at least a couple of
> weeks until we'll have a committee draft of the XRD spec that people
> can start writing code against. So imagine if some of the companies
> paying to participate in this TC were to take those two weeks and have
> someone work on writing or fixing necessary DSig implementations.
> Tatsuki said himself that there is a ruby implementation that has a
> clean gem install path, but it's just not quite finished. Well how
> much is lacking? Whoever needs a ruby implementation of this stuff,
> how bout getting in touch with the developer and helping him polish up
> his library?
>
> At a purely philosophical level, XML DSig seems to be the Right Way of
> signing XRD. It's a well-established standard, it's transport
> agnostic, it is consistent with other XML signing practices in the
> identity space (SAML), it does actually have decent language support
> (Java, C++, c14n in PHP5, others?). At a practical level, it's not
> terribly difficult to do -- see Scott's post at the beginning of this
> thread. So what if we don't have excl-c14n support in a couple of
> scripting languages? We don't have XRD support in ANY languages!!
>
> I promise I'll stop my ranting if someone has an argument against DSig
> that can't be solved by simply writing code. I don't have any special
> affinity for XML DSig, other than the fact that it seems to be the
> right tool for the job. My frustration is with the incredible amount
> of time spent rehashing the same set of theoretical problems that
> could have long-since been solved if companies would just buck-up and
> assign a developer to writing some code.
>
> -will
>
>
> On Jun 17, 2009, at 11:41 AM, Tatsuki Sakushima wrote:
>
> > Hello,
> >
> > David Garcia helped us to find candidates xmlsig(xmlsec)
> > implementations for scripting languages in theOpenID list. He showed
> > us an example, so I tried myself with Ruby that I am familiar with.
> >
> > There are two ways to make xmlsig(xmlsec) run:
> >
> > 1. Install the xmlsec library and make a wrapper with swig
> > 2. Install Hans's xmlsig
> >
> > Both methods are technically the same and use a swig wrapper. The
> > difference is how to install it.
> > 1. is using "rubygems" which is a package manger in Ruby and most
> > ruby users use to install ruby libraries they need to develop apps.
> > There is a swig wrapper implemented in github(the repository you can
> > run "gem install" directly against it.). I could install it with no
> > errors; however, I got en error when I include(require) it in a
> > code. I contacted who is developing it. He told me that it was
> > incomplete and wait for a stable release.
> >
> > 2. is developed by Hans of Verisign. This is the only way to run
> > xmlsig in Ruby for most people without developing a sig wrapper
> > themselves. I did three tests. The unit test comes with this
> > implementation worked. But against the SAML assertion generated by
> > the IDP(Java-based) I have here didn't work. It may be caused by
> > another reason. I need further inspections. But this implementation
> > does not return useful values when I call methods through the swig
> > wrapper. It is very hard to troubleshoot.
> >
> > I have learned two points from this little experiment. First, the
> > installation for xmlsig can be a issue. There aren't many choices
> > either. If I think of how to install the OpenID library in ruby(just
> > type "gem install ruby-openid"), it is way more difficult. This
> > could be a barrier for adoption. Probably we should assume that
> > people expects the same level of ease to install. Second, the cost
> > to impose c14n to developers is too high. I have found one
> > canonicalizer written purely in Ruby, but it didn't work. And the
> > way describe above doesn't guarantee if it interoperates other
> > canonicalizers but Hans's. If we assume that most of web developers
> > do c14n only for XRD signing and doesn't use it for any other
> > purposes(but likely do digital signatures), I think we are asking
> > and expecting too much to them. It is obviously that c14n is the
> > only issue. I still believe that eliminating it is sound choice to
> > drive adoption of XRD with signing.
> > Tatsuki
> >
> > (6/12/09 12:39 PM), Drummond Reed wrote:
> >> Scott, I don't know about anyone else, but this is tremendously
> >> helpful for
> >> me to get a sense of exactly what is involved.
> >> I would love to see this become part of one of the series of blog
> >> posts or
> >> web guides that are published on XRD and XRD signatures once the
> >> spec is
> >> ready.
> >> =Drummond
> >>> -----Original Message-----
> >>> From: Scott Cantor [mailto:cantor.2@osu.edu]
> >>> Sent: Friday, June 12, 2009 10:30 AM
> >>> To: 'XRI TC'
> >>> Subject: [xri] Very rough algorithm outline
> >>>
> >>> Since signing is less frequent, I'll try and sketch out a brute
> >>> force
> >>> verification. Obviously the c14n bits are the same for signing.
> >>> This is
> >>> just
> >>> a guess about what the rough outline would be if I was trying this
> >>> from
> >>> scratch.
> >>>
> >>> It's a DOM-based algorithm, and I don't use SAX so I don't know
> >>> enough
> >>> about
> >>> it to comment. I know the profile can be streamed, though.
> >>>
> >>> 1. Parse the XRD into a DOM tree in the usual fashion. Check it
> >>> over as
> >>> much
> >>> as you can before bothering with the signature. E.g. If there's
> >>> some kind
> >>> of
> >>> "claimed" identity for the signer, you can see if that identity is
> >>> even
> >>> trustable before you bother with any other work.
> >>>
> >>> 2. Find the ds:Signature and examine it to be sure it conforms to
> >>> the
> >>> profile, such as:
> >>>
> >>> - ensure the CanonicalizationAlgorithm and signature algorithm are
> >>> acceptable
> >>> - ensure it has only one Reference and that URI is an ID reference
> >>> to the
> >>> xml:id in the root element of the XRD.
> >>> - ensure the digest algorithm is acceptable
> >>> - check for Transforms and make sure it has only two, an Enveloped
> >>> transform
> >>> followed by an acceptable c14n transform
> >>>
> >>> Personally I wouldn't even bother with supporting inclusive c14n.
> >>> Will
> >>> could
> >>> adjust the profile to mandate exclusive.
> >>>
> >>> 3. Compute the Reference Digest
> >>>
> >>> - Canonicalize the subtree starting at the XRD root element,
> >>> knowing to
> >>> skip
> >>> the ds:Signature (see below)
> >>> - Digest the result and verify it against the ds:DigestValue
> >>>
> >>> 4. Obtain the signing key
> >>>
> >>> - Either rely on known keys or resolve a signing key from the
> >>> ds:KeyInfo
> >>> and
> >>> validate that it's acceptable.
> >>>
> >>> 5. Compute the Signature
> >>>
> >>> - Canonicalize the subtree starting at the ds:SignedInfo element
> >>> (see
> >>> below)
> >>> - Digest the result and compute the signature with the trusted
> >>> verification
> >>> key, and verify it against the ds:SignatureValue.
> >>>
> >>>
> >>> That's it minus the canonicalization step, which is roughly the
> >>> outline I
> >>> pointed to here: http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation
> >>>
> >>> In slightly less technical and more verbose language:
> >>>
> >>> 1. Check for an InclusiveNamespaces element parameter to the
> >>> algorithm
> >>> with
> >>> a PrefixList, and tokenize the list.
> >>>
> >>> 2. Establish a stack of elements and the namespace declarations
> >>> that are
> >>> "in
> >>> scope" at each processing stage as a result of processing the
> >>> elements.
> >>> It's
> >>> a mapping from element to namespaces in scope that you pop once
> >>> you return
> >>> from processing the element's children.
> >>>
> >>> 3. Recurse over the subtree operating on each element as follows:
> >>>
> >>> a. Is this a signature Reference and is this the ds:Signature
> >>> element? If
> >>> so, skip it and return.
> >>>
> >>> b. Output the element node by following the Inclusive C14N spec,
> >>> which
> >>> tells
> >>> you how to format it, how to order its attributes properly, what
> >>> to do
> >>> with
> >>> text nodes, processing instructions, etc. I'm not going to repeat
> >>> that
> >>> here,
> >>> but that part can easily be copied from existing libraries, it's
> >>> not the
> >>> complex part. The *exception* to the normal rules is the handling
> >>> of XML
> >>> namespace attributes.
> >>>
> >>> c. For non-default namespace declarations, you check that both of
> >>> these
> >>> conditions are true before you include it in the element:
> >>> - the element or its attributes contain the prefix OR it's in the
> >>> InclusiveNamespaces PrefixList
> >>> - the current stack of in-scope namespaces doesn't include it
> >>> already
> >>> That applies to both namespaces the element itself declares and
> >>> any that
> >>> are
> >>> explicitly used by the element or attribute names themselves.
> >>>
> >>> d. For xmlns="" (clearing the default namespace), there are a
> >>> couple of
> >>> simple checks to determine if it needs to be output, which you can
> >>> see in
> >>> step 3.3 of http://www.w3.org/TR/xml-exc-c14n/#sec-Implementation.
> >>> It
> >>> doesn't come up much since specs like this don't rely on unqualified
> >>> elements very often.
> >>>
> >>> e. Push all of the newly output namespace declarations onto the
> >>> stack with
> >>> the element and process each of its child elements recursively.
> >>>
> >>> f. After you come back, pop the namespace stack.
> >>>
> >>> -- Scott
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe from this mail list, you must leave the OASIS TC that
> >>> generates this mail. Follow this link to all your TCs in OASIS at:
> >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this mail list, you must leave the OASIS TC that
> >> generates this mail. Follow this link to all your TCs in OASIS at:
> >> https://www.oasis-open.org/apps/org/workgroup/portal/
> >> my_workgroups.php
> >
> > From: David Garcia <david.garcia@tractis.com>
> > Date: June 13, 2009 5:35:01 AM PDT
> > To: Nat Sakimura <sakimura@gmail.com>
> > Cc: Tatsuki Sakushima <tatsuki@nri.com>, OpenID Specs Mailing List
> <specs@openid.net
> > >
> > Subject: Re: [OpenID] Signing method for XRD
> >
> >
> > Hi Nat,
> >
> > yes you're right most of those impls are wrappers over aleksey's
> > xmlsec library.
> > Using wrappers requires systems running those services to have
> > xmlsec lib installed.
> >
> > Most unix like distros are shipped with this xmlsec and if not it
> > could be downloaded from the aleksey site
> (http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.9.tar.gz
> > ).
> >
> > Processing on xmlsignature is not very complex, but transforms like
> > c14n are.
> >
> > So most complex processes are to perform those transformation
> > processes that are complicated to implement and very aggressive on
> > computation requirements.
> >
> > As I said yesterday this morning I made a comparative of some
> > available options and what I've liked most is
> http://xmlsig.sourceforge.net/
> >
> > This lib provides a set of wrappers over xmlsec made available using
> > swig. Those bindings that are suposed to work in php, python and
> > ruby. I tested the ruby version.
> >
> > Installation requires libxml, libsxlt, swig and libxmlsec including
> > their -dev packages. I have to fix some include paths on building
> > because make didn't find header files from those libs.
> >
> > I started the process from the scratch and took me less than 1 hour
> > to have ruby code performing enveloped/enveloping signature creation
> > and validation (only crypto validation no certificate validation
> > process is included).
> >
> > I submit the code I created to have a message signer/validator. The
> > examples available on the test directory from the lib are awesome to
> > know how to perform signing and verification primitives calls.
> >
> > So my point of view about using pure dynamic libs or libs creating a
> > bridge over C libs is depend. Pure dynamic libs are easier to deploy
> > but in some cases like openssl, xml processing or in this case xml
> > signature (core tasks) bridging could be a good alternative.
> >
> > I post here my sample code on ruby. I got it working on Ubuntu
> > running on amd64 and debian running on power g4 but the doc claims
> > the lib working on most UNIX like systems including MacOSX and
> > Windows.
> >
> > Hope this helps :)
> >
> > Best regards
> >
> > Dave
> >
> > require 'xmlsig'
> > class MessageSigner
> >
> > def self.sign_message(message , xpath = nil)
> > x = Xmlsig::XmlDoc.new
> > x.loadFromString(message)
> >
> > private_key = Xmlsig::Key.new
> > private_key.loadFromFile('rsakey.pem','pem','')
> >
> > signing_certificate = Xmlsig::Signer.new(x,private_key)
> > signing_certificate.addCertFromFile('rsacert.pem', 'pem')
> >
> > if (xpath.nil?)
> > signed_signature = signing_certificate.sign
> > return signed_signature.toString
> > else
> > xp = Xmlsig::XPath.new
> > xp.setXPath(xpath)
> > signing_certificate.signInPlace(xp)
> > return x.toString
> > end
> > end
> >
> > def self.verify_message(signed_message)
> > to_be_verified = Xmlsig::XmlDoc.new
> > to_be_verified.loadFromString(signed_message)
> >
> > #Assuming a single signature per message
> > xp = Xmlsig::XPath.new()
> > xp.addNamespace('ds', 'http://www.w3.org/2000/09/xmldsig#')
> > xp.setXPath('/descendant::ds:Signature[position()=1]')
> > v = Xmlsig::Verifier.new(to_be_verified,xp)
> > valid = v.verify
> >
> > return valid == 1
> > end
> >
> > message = "<Message>message content </Message>"
> >
> >
> > #Second param is xpath.
> > #If not provided signature will be enveloping, this is signed
> > message will be embeded inside ds:Object node
> > #Providing Xpath will result in the signature being embeded inside
> > the message to be signed, that is an enveloped signature
> > signed_message = sign_message(message, "/Message")
> >
> >
> > valid = verify_message(signed_message)
> >
> > puts "Signature #{valid ? "is" : "isn't"} valid!"
> >
> > #Trying to cheat the signature validator
> > signed_message = signed_message.gsub(/content/, "other content")
> > valid = verify_message(signed_message)
> >
> > puts "Signature #{valid ? "is" : "isn't"} valid!"
> >
> > end
> >
> > 2009/6/13 Nat Sakimura <sakimura@gmail.com>
> > Thanks David,
> >
> > One of the issue that has been raised was that much of those
> > scripting languages implementation actually calls C++ library to do
> > the task. This makes it difficult to deploy it in some hosting and
> > PaaS environment, so libs written in that scripting language is
> > sought.
> >
> > If it is not there, then we need to evaluate how easy is it to do
> > that, and perhaps create a project to make them.
> >
> > Cheers,
> >
> > =nat
> >
> >
> > On Sat, Jun 13, 2009 at 3:01 AM, David Garcia <davebcn@gmail.com>
> > wrote:
> > Hi,
> >
> > Sure I'll do it, but let me make an in-depth analisis of
> > alternatives before pointing to a concrete implementation.
> >
> > I'll rebrowse sources to make those checks this weekend.
> >
> > Best regards
> >
> > David Garcia
> >
> > El 12/06/2009, a las 19:19, Tatsuki Sakushima <tatsuki@nri.com>
> > escribió:
> >
> >
> > Hi David,
> >
> > I completely agree with you, a single technology for those closely
> > related protocols would be better than forking. The main advantage
> > using XMLdSIG is that there are a huge amount of services currently
> > working with this technology. As far as I know there are mature libs
> > for C, C++, Java, .net, python, ruby, php .
> >
> > Can you navigate us to some libraries you have seen especially for
> > those scripting languages, python, ruby, and php? So some of us
> > including me can test them and see how they works. Some forks
> > expertizing XML says XML DSig with exclusive c14n is "easy enough",
> > but many of us haven't seen the real example in scripting languages.
> > And if it is easy or not is somewhat subjective. I think showing
> > examples will facilitate this discussion.
> >
> > Best,
> > Tatsuki
> >
> > Tatsuki Sakushima
> > NRI Pacific - Nomura Research Institute America, Inc.
> >
> > (6/12/09 1:48 AM), David Garcia wrote:
> > Hi Nat,
> > I completely agree with you, a single technology for those closely
> > related protocols would be better than forking. The main advantage
> > using XMLdSIG is that there are a huge amount of services currently
> > working with this technology. As far as I know there are mature libs
> > for C, C++, Java, .net, python, ruby, php .
> > Those libs are compliant with xmldsig interopt tests so this give us
> > warranties about their intertoperability. Message sign and verify
> > primitives are very simple from the point of view of the developer
> > and the only problem arises when trying to verify the signer
> > certificate (path building, validation, status validation vs CRL and
> > OCSP...) but several "tricks" could be made here to keep the process
> > simple.
> > I'll feel very comfortable about using XMLdSIG because from the
> > point of view of the increase of complexity it won't be as easy as
> > raw data processing, but it won't be very painful if we use those
> > sets of libs.
> > If you want maybe we can create a little project for a proof of
> > concept and make an interop between 2 different technologies signing
> > and verifying messages. If so please let me know :).
> > Best regards
> > Dave
> > 2009/6/12 =nat <sakimura@gmail.com <mailto:sakimura@gmail.com>>
> > Hi.
> > Thanks for your great feedback.
> > It is kind of interesting that OpenID side wants the simplest form
> > while
> > in the OAuth list, XML DSig is liked better somehow.
> > >From the spec point of view, it is better to not to fork as much
> > as
> > possible,
> > so if we can stick to XML DSig, that's great.
> > Now, here is another question then.
> > If libraries with decent API becomes available to each language,
> > written in that language, and is tested for compatibility to each
> > other,
> > would you be amiable to this constrained form of XML DSig?
> > =nat
> > On Thu, 11 Jun 2009 16:14:56 +0200, David Garcia
> > <david.garcia@tractis.com <mailto:david.garcia@tractis.com>>
> > wrote:
> > > Hi Hans,
> > >
> > > this project offers a set of wrappers over xmlsec library used on
> > many
> > c++
> > > envs. I used it a lot and their equivalent in Java for some
> > years on
> > > critical production envs and they're very mature.
> > >
> > > Dealing with xml data as opaque bits (a simplified xml version
> > of CMS
> > > signature containers) instead of interpreting the infoset as
> > proposed
> > will
> > > be a much simpler approach because it eliminates the need of
> > using c14n
> > > and
> > > transform algorithms (not mandatory but recommended on some
> > scenarios).
> > >
> > > Maybe this simpler approach will fit for message exchange.
> > >
> > > Best regards
> > >
> > > Dave Garcia
> > >
> > >
> > > 2009/6/11 Hans Granqvist <hans@granqvist.com
> > <mailto:hans@granqvist.com>>
> > >
> > >> Perhaps someone from VeriSign (Barry? Gary?) can comment on the
> > > viability
> > >> of
> > >> http://xmlsig.sourceforge.net/
> > >>
> > >> Hans
> > >>
> > >>
> > >>
> > >> On Wed, Jun 10, 2009 at 11:54 PM, John Panzer<jpanzer@acm.org
> > <mailto:jpanzer@acm.org>> wrote:
> > >> > My general impression is that something that requires two
> > pieces of
> > >> software
> > >> > to agree on an exact, bit for bit infoset representation of
> > an XML
> > >> document
> > >> > in order to get security to work is a poor idea. I have seen
> > no wide
> > >> > deployments/usage of DSig in Atom feeds -- despite it being
> > part of
> > > the
> > >> spec
> > >> > -- and many complaints about how it's not possible to get it
> > to work
> > >> > reliably given the software stacks currently in use. The
> > difficulties
> > >> with
> > >> > canonicalization-for-signing in OAuth implementations have
> > also
> > >> reinforced
> > >> > my belief that it's much better to err on the side of the
> > robust and
> > >> simple.
> > >> >
> > >> > Signing a stream of uninterpreted bytes cuts out a whole
> > slew of
> > > failure
> > >> > modes, and the ones that remain are debuggable -- the bytes
> > match or
> > > they
> > >> > don't, and standard tools can tell you which. It means it's
> > possible
> > > to
> > >> > verify a signature with curl + a command line utility These
> > are all
> > >> very
> > >> > good things.
> > >> >
> > >> > (As a side note, it would also make the content type
> > orthogonal to the
> > >> > signature code -- this is a good thing.)
> > >> >
> > >> > So, +1 for the simplest form of signing that could possibly
> > work.
> > >> >
> > >> > -John
> > >> >
> > >> >
> > >> > Johannes Ernst wrote:
> > >> >
> > >> > I proposed something I called XML-RSig for similar reasons a
> > few years
> > >> ago:
> > >> >
> > >>
> > http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
> > >> >
> > >> > "RSig" for "Really simple Signature".
> > >> >
> > >> > The trouble for OpenID and XRD and so forth is that it is not
> > our core
> > >> > competency -- and shouldn't be -- to innovate around things
> > that
> > > really
> > >> > aren't our business. Signing XML documents isn't our business.
> > >> >
> > >> > On the other hand, the people whose business it should be
> > somehow seem
> > > to
> > >> be
> > >> > asleep at the wheel, as the problems are well-known and
> > somehow aren't
> > >> being
> > >> > addressed, and haven't for years.
> > >> >
> > >> > It seems to me that the best way out of this conundrum is:
> > >> > 1. to foresee, architecturally, the use of several different
> > ways of
> > >> > constructing signatures, as the matter clearly isn't settled
> > >> > 2. to make sure that high-end approaches (like XML-DSIG) work
> > well,
> > > but
> > >> > low-end approaches (like XML-RSIG) work just as well
> > >> > 3. to maintain a best practices document that says "today,
> > choice X is
> > >> your
> > >> > best bet, and we say that because based on our market
> > research, X has
> > > the
> > >> > highest market share in terms of implementors today."
> > >> >
> > >> > As we all know, any problem in computer science can be
> > solved by
> > > adding a
> > >> > level of indirection. This may well be one of those cases.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Johannes Ernst
> > >> > NetMesh Inc.
> > >> >
> > >> >
> > >> > ________________________________
> > >> >
> > >> >
> > >> >
> > >> > ________________________________
> > >> >
> > >> > http://netmesh.info/jernst
> > >> >
> > >> >
> > >> >
> > >> > ________________________________
> > >> > _______________________________________________
> > >> > specs mailing list
> > >> > specs@openid.net <mailto:specs@openid.net>
> > >> > http://openid.net/mailman/listinfo/specs
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > specs mailing list
> > >> > specs@openid.net <mailto:specs@openid.net>
> > >> > http://openid.net/mailman/listinfo/specs
> > >> >
> > >> >
> > >> _______________________________________________
> > >> specs mailing list
> > >> specs@openid.net <mailto:specs@openid.net>
> > >> http://openid.net/mailman/listinfo/specs
> > >>
> > >
> > >
> > >
> > > --
> > > David Garcia
> > > CTO
> > >
> > > Tractis - Online contracts you can enforce
> > > http://www.tractis.com
> > > --
> > > Tel: (34) 93 551 96 60 (ext. 260)
> > >
> > > Email: david.garcia@tractis.com <mailto:david.garcia@tractis.com>
> > > Blog: http://blog.negonation.com
> > > Twitter: http://twitter.com/tractis
> > --
> > David Garcia
> > CTO
> > Tractis - Online contracts you can enforce
> > http://www.tractis.com
> > --
> > Tel: (34) 93 551 96 60 (ext. 260)
> > Email: david.garcia@tractis.com <mailto:david.garcia@tractis.com>
> > Blog: http://blog.negonation.com
> > Twitter: http://twitter.com/tractis
> > ------------------------------------------------------------------------
> > _______________________________________________
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> >
> >
> >
> > --
> > Nat Sakimura (=nat)
> > http://www.sakimura.org/en/
> >
> >
> >
> > --
> > David Garcia
> > CTO
> >
> > Tractis - Online contracts you can enforce
> > http://www.tractis.com
> > --
> > Tel: (34) 93 551 96 60 (ext. 260)
> >
> > Email: david.garcia@tractiscom
> > Blog: http://blog.negonation.com
> > Twitter: http://twitter.com/tractis
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]